Wordpress on AWS: smooth and pain free

Unless you pay for a larger instance where the cost turns out to more like 50 bucks a month you get very limited bandwidth out of AWS, which is why I stopped using it. I suppose if you are running a corporate blog and cost isn't an issue then AWS probably works fine but for smaller sites and individual users there are vastly cheaper very good hosting options out there. I don't want to seem like a shill so I won't mention them by name. It was the super crappy bandwidth on AWS where basically my site would die regularly with just one or two visitors that made me abandon the platform.

> Before you hop on board with this "pain free" solution, you should accept the fact that you may end up maintaining this [...]

True, although ongoing maintenance of a CloudFormation template isn't significant. It's essentially a specification of the state of the infrastructure, which AWS is then responsible for making come true. It's also their stuff from CloudFormation back, so they're on the hook for making sure nothing changes that would break it (relative to Terraform or other alternatives).

Also keep in mind that AWS services are usually encapsulated from each other, which is a good thing. The result, though, is that defining something like this involves a lot of parts. You need to define its private network, its subnet masks, its EC2 instance types, its database type and configuration, etc. The author also took it a step further to define CloudWatch alarms and scaling policies, which is great.

It is something that requires understanding if changes are necessary, but it's not something that you would expect to need tweaks over time.

> There should be easier way

There is--he could have started Wordpress by just launching an instance with userdata that installs it and sets it up. This isn't really comparable to that because it involves multiple servers behind a load balancer, a CDN, a hosted DNS zone, a separate relational database service instance, and autoscaling.

> I’m not a fan of Wordpress, as it is neither cloud-ready nor serverless.

Well that's a funny opener.

TL;DR: rather than configure your uploads to go to S3, one of AWS's most battle hardened and time tested offerings, use a service that was launched 10 months ago and can definitely scale perfectly and will never have any issues. Then you can even keep on managing your htaccess files using a WordPress plugin and skip that pesky version control!

Yes, you can do this. But, what about a staging environment? How do you keep data and code in sync between environments? My company runs a lot of wordpress instances, and we've wound up shipping most of them to Pantheon. (pantheon.io) Not only does it take care of environment issues, but it gives you redis and implements caching as a service. As the post says, wordpress fights AWS a bit. We leave it to the people who are experts at winning that fight.

(I know this reads like an ad. I'm not affiliated with pantheon except as a user. Pantheon comes close to making wordpress not suck.)

I work at Human Made (owner of the above repo, and an enterprise WordPress agency), and we run all our sites on an all-AWS stack. We have a few other plugins for related AWS pieces, including email via SES [1] and a dynamic image thumbnail generator that runs on Lambda [2] that might also be relevant.

Using S3 for the uploads solves our problems without needing EFS, as we disable file system changes through other methods. Plugin installs or upgrades are great, but aren't tracked in the git repo, so we do those via local upgrades and deploy out to AWS instead.

The article also mentions installing WordPress as being a pain, but you can easily automate this using wp-cli [3] if you want to. Your RDS containing the WP data is going to be shared though, so there's no real need to install more than once.

[1]: https://github.com/humanmade/aws-ses-wp-mail [2]: https://github.com/humanmade/node-tachyon [3]: http://wp-cli.org/