We planned to create a stateless AMI for the WordPress Servers. As WordPress stores data locally, we made changes in WordPress code to store all the data to S3 instead of storing locally. Similarly, the code that did local reads in WordPress was changed to do reading from S3 instead. This code was then deployed to an EC2 instance. As WordPress depends on sessions, the sessions were stored in ElastiCache. This ElastiCache machine was used by all the EC2 instances to store and retrieve session information.
A golden AMI created out of the EC2 instance running this software. This AMI was used to launch more such EC2 instances with WordPress code and to setup auto-scaling.
The database was migrated to RDS with Multi-AZ setup for high availability. We also created a Read-Replica in another region for Disaster Recovery perspective (DR).
We created a VPC and public and private subnets. ELB was in public subnet and all the Web EC2 instances were in private Subnet. DB was in a separate private subnet. We had a NAT instance for the Web EC2 instance to talk to the internet. A bastion host was deployed to be able to ssh into the EC2 instances. CloudFront CDN was deployed to server the WordPress images, CSS, and java script files.