So, the question then arises as to how one is supposed to run a site on AWS? Not only does it require a use of quite a bit of AWS’s services, it also requires extensive knowledge of the AWS systems and configuration.
As I said in the previous article, AWS is a set of services. No production site on AWS should be running on a single instance. They all require at least two. That way, in case one fails, the other one can handle the load until a new one is automatically launched to take the failed one’s place. This is done through a set of autoscaling policies and load balancing on something called an Elastic Load Balancer. The Elastic Load Balancer can be setup to monitor the instances, and the autoscaling rules monitor that to create new instances when old ones fail.
But what goes on the new instances that are created, how do they automatically have the new app? This can be done through a system called CodeDeploy. Its an automated deployment system to deploy code to newly created instances. Another possibility is a more “managed” service from AWS called ElasticBeanstalk. That handles the ELB/Deployment/Instances for you. However, it is less customizable.
Since they can come and go at will, the database backing the website cannot reside on either of these two servers. Instead, you create another server under the RDS (Relational Database) service. This should probably be a Multi-Availability Zone deployment with automated failover, which is sort of like a hot-spare. This is a great, fully managed database as service. However, it adds additional costs.
Making matters even more complicated, normal apps like WordPress are not designed to work in this sort of environment. WordPress stores assets on the filesystem of the machine it is running on. This cannot be done with AWS. You now have at least two machines that aren’t aware of each other. The database is OK as that is on its own system, but all uploaded assets now need to be stored somewhere else. S3 is the ideal place to put these assets, but that requires modification of the WordPress setup. There are plugins to assist with this, but they may not be perfect. It is not part of the WordPress core. AWS has announced a new alternative called an Elastic Filesystem. This does allow multiple machines to share one area on the file system. This is not as good as S3, but would require no application modification. The other downside is it is significantly more expensive than S3. We haven’t used it yet, so it may have its own peculiarities.
As you can see, a true AWS recommended setup is extremely complicated. It requires both application level changes as well as an extensive knowledge of AWS services. For smaller sites, it is not anywhere near worth the effort. For larger sites that need fault-tolerance as well as scalability, it is. Once the initial setup costs are amortized, it can actually be cheaper.
Just for a recap, assuming someone has all the knowledge to setup this system, as well as change the application to operate in this environment, let’s look at the projected costs for an AWS deployment:
- Elastic Load Balancer (Free Tier Eligible for one year): ~$14.50/month
- 2 EC2 Micro instances with EBS storage of around 10 gigs each (One is Free Tier Eligible for one year): ~$20.00/month
- 1 RDS Multi-AZ Micro instance with 10 gigs of storage: ~22.00/month
- 50 gigabytes of bandwidth (15 gigabytes is Free Tier Eligible for one year): ~$4.5/month
- Miscellaneous costs (S3, Snapshot storage, AMI storage, Route 53, most Free Tier Eligible for one year): ~$2-$5.00/month
That’s not all that expensive, but is significantly more than $10 a month.
