WordPress is arguably the most popular content management system available today. It is a popular choice for a wide range of websites, ranging from small personal blogs to large high traffic websites. As per a report, it has a market share of more than 37%. Looking at the recent trends, this number is only going to increase in the days to come.
In this blog, I will share with you how to deploy a highly scalable WordPress website using AWS Fargate and Terraform. AWS already has a reference architecture for deploying WordPress on AWS which proposes to use EC2 and Aurora. However, since AWS launched EFS integration with Fargate, I wanted to design a solution using Fargate so that I do not have to configure and manage EC2 instances. Hence, in this solution, Fargate is used for computing and Aurora Serverless for the database. Additionally, I wanted to prepare a Terraform recipe for this (my favourite IaC tool) so I can bring up this architecture very quickly in any AWS account.
Design Considerations:
Some of the key design choices made in this approach were selecting Fargate over EC2 and Aurora Serverless over Provisioned Aurora.
Fargate is the serverless compute engine for containers provided by AWS. Being a serverless platform, developers are not responsible for building and maintaining host servers and scaling them. All they have to do is build their Docker image and push the image to a Docker image repository like Docker Hub or AWS ECR. AWS takes care of running and managing the underlying host servers. Scaling in Fargate is achieved using Application Auto Scaling and the actual tasks are scaled based on CPU utilization. If the CPU rises above a certain threshold, then new tasks are created which are attached to a target group. Similarly, if the CPU utilization falls below a certain threshold, existing tasks are killed and removed from the target group. ALB (Application Load Balancer) automatically distributes traffic to these targets.
Fargate tasks are designed to be stateless in nature. However, WordPress applications need to maintain certain assets in filesystem e.g. plugins and media contents. To store and share the assets among the Fargate tasks, we use EFS (Elastic File System). EFS are AWS managed petabyte-scale NFS (Network File System) which can grow and shrink automatically.
Aurora Serverless is the serverless version of Aurora, where scaling and failover are not developer responsibilities and are managed by AWS. All the developer has to do is just mention the min and max capacity. If desired, AWS would shut down the database when not in use for a specific duration. This can be very handy for websites which have very low traffic. Obviously, on the downside, there is a cold start when the database is starting from a complete shutdown and the same during up-scaling. Aurora Serverless is ideal for databases with variable and unpredictable workloads. A provisioned Aurora cluster would make more sense for a very predictable workload. However, in this solution, I wanted to experiment with only serverless solutions.
Cost:
Given that most of the key components used in the architecture i.e. Cloudfront, Application Load Balancer, Fargate, Aurora Serverless and EFS are serverless in nature, the pricing is completely dependent on the usage. However, I have attempted below to estimate the total cost of the solution described above. I have used eu-west-1 (Ireland) region for the estimation.
Cloudfront pricing is mostly dependent on the amount of data transfer and the total number of HTTP/HTTPS requests. For a small site with around 100 GB of outbound data transfer and average object size of 30KB, the CloudFront cost will be less than 15 USD per month.
ALB has a fixed cost of 18.4 USD per month. On top of that, the pricing is determined based on the LCU (Load Balancer Capacity Units) which is a factor of new connections, active connections, bytes processed and listener rules evaluated. For a small to medium size website, the total ALB cost will be around 25 USD per month.
Fargate cost is dependent on the total vCPU and memory used. Taking into account 2 Fargate tasks, each with 1 vCPU and 2 GB of memory, running for 24 hrs a day, the total cost for 30 days is approximately 71 USD.
Aurora Serverless cost is dependent on the total ACUs (Aurora Computing Units) consumed, storage and number of I/O requests. The cost is calculated considering that there is peak traffic on the database for 2 hours per day where the database scales to 4 ACUs and there is no traffic on the site for 4 hours during the day where the database shuts down. For the remaining part of the day, the site has minimal traffic and consumes just 2 ACUs. In this scenario, the total cost of usage would be around 3.08 USD per day or 92.4 USD per 30 days. 20 GB of storage would cost 2.2 USD (0.11 * 20) per month and considering 1 million I/O requests per days would cost 6.6 USD (0.22 * 30) per month. This brings the total cost of Aurora Serverless database to be slightly over 100 USD per month.
EFS which is used to store assets for the site has a very minimal cost of around 3.3 USD per month taking into account 10 GB of standard storage user per month.
Apart from that, there would be additional cost towards NAT Gateways. Cost of a NAT Gateway in eu.west-1 region is 0.048 USD per hour which is 34.56 USD for 30 days. Since, the solution is designed to be highly available and have a NAT Gateway per Availability Zone, it would cost 103.68 USD per month towards fixed cost. Apart from this fixed cost, there is a cost for data processing which is 0.048 per GB.
Hence, the total cost of a very light to medium used WordPress site should be around 325 USD per month. Please note that the aforementioned costs are rough estimates and based on certain assumptions. Also to be noted is that the above cost does not take into consideration AWS Data Transfer cost which are ambiguous, super difficult to calculate and would need a huge blog in itself to explain. Given that the solution is serverless and has been designed to scale, the total cost has very less fixed cost and is greatly dependent on the actual usage.
The complete source code including the steps to create the infra setup is open-sourced on Futurice’s Terraform example repository under an MIT license. I hope that this configuration will save you a lot of time setting up your own self hosted WordPress installation.
EDIT: Added cost for NAT Gateways
Sunil Kumar MohantyCloud Architect
