The idea is to have a pattern that can be deployed which would result in a highly available, scalable, yet efficient WordPress solution.
It follows, roughly, the AWS WordPress architecture with some minor tweaks. Namely the adition of using S3 for static files and media that will be served up via CloudFront.
Another small change is that instead of being two (2) availability zones (AZs) and having two instances (one in each) being load balanced between. It can span N number of AZs but only have one running instance by default.
The autoscaling group however will ensure that atleast one is running at all times in any AZ that is available, but can spin up more instances as needed.
Currently this is planned to use EC2 instances, but a case could be made for Fargate Containers.
AWS CLI could be used a well to determine a few things. 1. How many AZs are in the target region? 2. What AZs have a given resource type available (not all AZs will have all of the same instqnce type availibility and/or capacity). Using the AWS-CLI we should be able deploy to N number of AZs where our requires instance type is available
Amazon Virtual Private Cloud (Amazon VPC), Amazon Elastic Compute Cloud (Amazon EC2), Auto Scaling, Elastic Load Balancing (Application Load Balancer), Amazon Relational Database Service (Amazon RDS), Amazon ElastiCache, Amazon Elastic File System (Amazon EFS), Amazon CloudFront, Amazon Route 53, Amazon Certificate Manager (Amazon ACM) with AWS CloudFormation via AWS CDK.
- AWS for Wordpress (hasn't been updated in a while but is directly from AWS)
- W3 Total Cache
- WP Offload Media (optional)
This is a project for CDK development with TypeScript.
The cdk.json file tells the CDK Toolkit how to execute your app.
npm run buildcompile typescript to jsnpm run watchwatch for changes and compilenpm run testperform the jest unit testscdk deploydeploy this stack to your default AWS account/regioncdk diffcompare deployed stack with current statecdk synthemits the synthesized CloudFormation template