I’m not talking about launching an EC2 instance, uploading the zip with WordPress and going through the installer. I’m talking about immutable infrastructure, scalable, self-healing setup of WordPress within AWS.

1. Make it reusable

First things first, the base for anything scalable and self-healing in AWS is having an AMI which you can use to launch an instance at will. Something that will boot and work out of the box, without touching. With WordPress and the click-through installer, that may not be obvious. How? Use composer. Please, please do. For background and details, checkout https://roots.io/using-composer-with-wordpress/.
Example composer.json:

    "name": "mycompany/my-wordpress-blog",
    "type": "project",
    "config": {
        "preferred-install": "dist"
    "repositories": [
            "type": "composer",
            "url": "https://wpackagist.org"
    "require": {
        "php": ">=5.5",
        "composer/installers": "~1.0.12",
        "johnpbloch/wordpress": "4.6.1",
        "wpackagist-plugin/amazon-s3-and-cloudfront": "*",
        "wpackagist-plugin/amazon-web-services": "*"
    "extra": {
        "installer-paths": {
            "web/app/mu-plugins/{$name}/": [ "type:wordpress-muplugin" ],
            "web/app/plugins/{$name}/": [ "type:wordpress-plugin" ],
            "web/app/themes/{$name}/": [ "type:wordpress-theme" ]
        "wordpress-install-dir": "web/system"

1.1 Use AWS plugin for S3

After sorting out the actual WordPress files (as above), your images and uploaded content will be a second issue – by detail WordPress stores all this stuff on disk. That’s no going to work if you want to replace instances at will. The WP Offload S3 plugin (formerly known as Amazon S3 and CloudFront plugin) is the solution – uploads all your images to S3 and integrates with WordPress’s media browser, so you don’t even know it’s there.

2. Make an AMI

Use composer and whatever tools you use to build AMIs (Packer, like everyone? 😉 ) and get that AMI! The idea: install all required software (webserver, php, etc.) and enable all of it to start on boot (you can use cloud-init if you need to).

Remember to create wp-config with all your config values!. If you don’t know them, you can always install WordPress manually first and checkout the config file created by the installer.

2.1 Useful config

For the Offload plugin, the most useful setting ever:

define('AWS_USE_EC2_IAM_ROLE', true);

If you’re not using it, you’re probably doing something wrong.

3. Setup a stack with CloudFormation…

…or Terraform or whatever you like and use your AMI. There’s nothing special needed here, a basic stack with AutoScaling and RDS within a VPC will work perfectly. You can use ElastiCache for session storage (simply configure it in php.ini), to make sure users stay logged in when a new instance is launched (or when the load balancer switches the user to another instance). No special setup is required to make it work with multiple instances – as long as you use the Offload plugin, so your images are available everywhere.

4. Recommendations

Extra plugins that I would use?

  • roots/wp-password-bcrypt
  • wpackagist-plugin/wp-super-cache – you can go from needing 2x t2.medium instances, to 1x t2.small

Big thank you to John Bloch for creating https://github.com/johnpbloch/wordpress

I’ve skipped a lot of details in this post, so if you have any specific questions, feel free to leave them in the comments.

1 person found this post helpful
Was this post helpful to you? Yes!

Leave a comment