What’s Not Covered

Purchase a pre-installed image of this tutorial and check out our new knowledge base WordPress Now.

What We’re Not Addressing

• BitNami Cloud: I’m not using the BitNami Cloud to launch an AWS AMI with WordPress. If you’re interested in AWS but don’t want to do all the work of running your own instance, this may be a good middle step for you. However, they aren’t integrating Varnish and W3 Total Cache as I do in this tutorial. Furthermore, I am not familiar with the model they use to organize their directories and components and prefer to have more expertise over my environment. If you are interested, this tutorial may interest you: Using BitNami to Set Up WordPress on Amazon EC2. I do think BitNami is promising and useful.
• BitNami AMI: Similarly, I’m not using the BitNami AMIs and pre-built WordPress stack directly because I’m not as familiar with them and they use their own custom directory format which was unfamiliar to me. If I want to add other applications to my instance, I don’t want to be hindered by a non-standard install.
• The Ubuntu WordPress package: The standard Ubuntu WordPress package defaults to multi-site mode and has its own style of configuration which I’m not familiar with. Because multisite is inherently slower without additional configuration, I chose not to use the package.
• Multisite: I specifically do not use WordPress in multisite mode because I found that it is slower. It’s specifically more difficult to optimize the delivery of images with multisite because every request is routed through PHP. I also found that plugin compatibility is weaker and problematic. I actually went through the trouble of migrating this blog off of a multisite installation. Once you activate Multisite, it can be difficult to return to single site mode – in some circumstances.
• Amazon’s Elastic Beanstalk: I’m not using Amazon’s Elastic Beanstalk to deploy WordPress. I may do this in the future. Here’s a tutorial on using elastic beanstalk with wordpress.
• Amazon’s RDS: I’m not using Amazon’s Relational Database Service (RDS) in place of MySQL. The primary reason is that the point of this guide is to minimize cost for small to medium-sized WordPress sites. RDS is more appropriate for larger, scalable, fault-tolerant sites where cost is secondary. Here’s a tutorial of using RDS with WordPress; it reports $82 monthly as a minimal cost RDS installation.
• CloudFlare: I’m currently not using CloudFlare as it’s not clearly that it would provide significant value add over Amazon S3’s CDN with W3 Total Cache. However, I’m eager to give it a try.
• NGINX: I know a lot of people swear by NGINX over Varnish but I did not have as much luck configuring NGINX. I found Varnish worked well with Apache and Apache works well with PHP more straightforwardly.
• Dynamic multi-server scaling with AWS: Again, this isn’t the goal of this guide. Check out Architecting a Highly Scalable WordPress Site in AWS

Please feel free to post corrections, questions or comments below. You can also follow me on Twitter @reifman or email me directly.

Continue to Related Links