← Projects

Architecture Evolution of a Sample WordPress Site Hosted on EC2

A five-stage AWS architecture case study: starting from a single EC2 instance running WordPress, MySQL, and blog content together, and evolving it — one AWS service at a time — into a highly available, auto-scaled deployment behind a load balancer.

Stage 1 of 5

Baseline: single EC2 instance

  • + Amazon VPC
  • + Amazon EC2

Everything on one box — WordPress, MySQL, and the blog content all live on a single EC2 instance inside a public subnet.

  • 3-AZ VPC laid out with a public compute subnet and two private subnets (application, database) per AZ, sized for future growth.
  • A single EC2 instance in AZ-A's public subnet runs the full stack: WordPress, MySQL, and the blog's media files on local disk.
  • Simple to stand up, but the instance is a single point of failure and every layer scales — or fails — together.
Stage 1: Baseline: single EC2 instance
EC2 Launch Template
Stage 2 of 5

Repeatable provisioning

  • + EC2 Launch Template

The instance is now provisioned from an EC2 Launch Template instead of being hand-configured, making the setup reproducible.

  • A Launch Template captures the AMI, instance type, and bootstrap configuration needed to stand the server back up.
  • No architectural change yet — same single instance, same local MySQL and blog content — but the deployment is now version-controlled and repeatable, which sets up every later stage.
Stage 2: Repeatable provisioning
Amazon RDS
Stage 3 of 5

Decoupling the database

  • + Amazon RDS

MySQL moves off the EC2 instance and onto a managed Amazon RDS instance in the database subnet.

  • RDS is deployed into AZ-A's private database subnet, isolated from public traffic.
  • The application tier now talks to RDS over the network instead of to a local MySQL process, so the data layer can be backed up, patched, and scaled independently of compute.
  • Blog content still lives on the EC2 instance's local disk at this stage.
Stage 3: Decoupling the database
Amazon EFS
Stage 4 of 5

Shared, durable storage

  • + Amazon EFS

Blog content moves off local EC2 storage and onto Amazon EFS, mounted from every AZ's application subnet.

  • EFS mount targets are placed in the application subnet of each of the three AZs, not just AZ-A.
  • Media and uploads are now durable and shared storage rather than tied to one instance's disk — a prerequisite for running more than one web server.
  • With both the database and the file system externalized, the EC2 instance itself becomes stateless.
Stage 4: Shared, durable storage
Application Load Balancer + Auto Scaling Group
Stage 5 of 5

High availability and scale

  • + Application Load Balancer
  • + Auto Scaling Group

EC2 instances are added across all three public subnets, fronted by an Application Load Balancer, and grouped into an Auto Scaling Group.

  • An Application Load Balancer sits in front of the fleet; traffic now reaches the application via the ALB's DNS name instead of a single instance's address.
  • WordPress instances run in PUB-A, PUB-B, and PUB-C, all built from the same Launch Template, all stateless, all reading/writing the same RDS database and EFS file system.
  • The three instances are managed as an Auto Scaling Group, so capacity can grow or shrink with demand and a failed instance is automatically replaced.
Stage 5: High availability and scale