Wordpress in AWS

(not my website - I don't use Wordpress)

This is a post to show how we can deploy Wordpress website in AWS Cloud using serverless services.

The idea is that we deploy Wordpress using MySQL database in RDS as a way to persist our Posts and Pages, we use SecretManager to store our database credentials, Parameter Store to store some configuration for our application, and we use ECS with Fargate to manage our container.

For us to be able to create a container in ECS, we need to push images into ECR.
We need to authenticate into ECR and pull Wordpress image and tag it and push it to our ECR private repository. After this, we can create a task defintion that will use this image for our container with specific configuration details which is used by ECS to create and manage our containers. - I'm jumping the details of configurations here to just try to break things into smaller pieces so we can grasp the overall vision.

The way that ECS works is that we need to have a service running in a cluster, but let me show you the dependencies for that to be possible.

Basically we can start from the Task definition and then the cluster and service. Once they are setup and running they need to be publicly accessible.
The way we do this is using a ELB which will have a public IP/DNS and then that will have a listener listening on port 80 (because wordpress is a webapp) and then itwill redirect traffic to a Target Group (where you register many targets "another way to say something that will receive your requests", i.e, a EC2 machine).

This is in general what is needed just to put the application running in ECS and scalable/redudant.
But for this to work, we need to setup our VPC and the subnets in a way that allows us to have redundancy and ECS shine.
For that the VPC could be designed as follows:

Image 1.

4 Route tables - 1 public route table and 3 private route tables.

In the public RT, we have a route to the internet meaning that any instance running there have access to the internet.

In the privates route tables we don't - so that we have more security and no way to access to our private network. However our privates subnets needs access to the internet for things like updates, and for this reason it needs a route to a NAT gateway that we require to privision first.
Each subnet then needs to be associated to the proper RouteTable to know how to route requests.

This related to the Image 1 (image above)


The architecture in Image 2, shows the setup of Wordpress running in AWS with required provisioned infrastructure (Image 1) - VPC, Subnets, Security Groups, Internet Gateway, NAT Gateway, RouteTables, ECR and RDS database subnet group (which is a collection of subnets within a VPC that you define when launching an Amazon RDS instance in a Multi-AZ or Single-AZ deployment. It ensures that your RDS instance has network connectivity within your chosen Availability Zones (AZs)).

Once provision is done for all of the above, we can finally think about creating SecretsManager secrets, Parameter Store parameters, RDS database, ELB load balancer and ECS Task definitions and service. Image 2 shows what we require for the architecture to be deliver as complete.


Image 2.

Secrets Manager secrets are pretty straightforward, you just persist your secrets, like connection strings, passwords, etc.
In SSM Parameter store is mostly the same, you can persist plain data and encrypted, something like user names.
Once the wordpress image is uploaded to ECR private registry, we can setup our task definition as I have shown previosly above and then finally create the service.
Once we have this running and steady, we can think about the ELB, Target Groups and listener, this is obviosly to have a way to point a public user http request for our Elastic IP in the Load Balancer, so that the load balancer sends the request to a group of EC2 machines contained in our Private Subnets. Only the load balancer is situated in the public subnet so that can receive requests from the internet.
I know it seems very simplistic, and it isn't, but the idea is to simplify as much possible how something like this can be achieved in AWS. I also didn't cover the need for the Task definition to use a volume to persist some content that Wordpress might need, but in fact it will require a persistent volume data so that all images and content will be stored there.

We also have another simplistic way to deliver this,

and is simply using a EC2 machine with a Launch Template without requiring so much infrastructure and keep it basic in a single availability zone.
Depending on your use case, sometimes simplicity is the best, so that we don't need to worry about too many things: as redundancy, high availability and scalibility. This are however required more in cases like a enterprise application that can't be down almost never.