Use an Application Load Balancer (ALB) in front of an Auto Scaling group of WordPress Amazon EC2 instances in one AWS Region and three Availability Zones. Configure an Amazon ElastiCache cluster in front of a Multi-AZ Amazon Aurora MySQL DB cluster. Move the WordPress shared files to Amazon EFS. Configure Amazon CloudFront with the ALB as the origin, and select a price class that includes the US and Europe.
Use an Application Load Balancer (ALB) in front of an Auto Scaling group of WordPress Amazon EC2 instances in two AWS Regions and two Availability Zones in each Region. Configure an Amazon ElastiCache cluster in front of a global Amazon Aurora MySQL database. Move the WordPress shared files to Amazon EFS. Configure Amazon CloudFront with the ALB as the origin, and select a price class that includes the US and Europe. Configure EFS cross- Region replication.
Use an Application Load Balancer (ALB) in front of an Auto Scaling group of WordPress Amazon EC2 instances in one AWS Region and three Availability Zones. Configure an Amazon DocumentDB table in front of a Multi-AZ Amazon Aurora MySQL DB cluster. Move the WordPress shared files to Amazon EFS. Configure Amazon CloudFront with the ALB as the origin, and select a price class that includes all global locations.
Use an Application Load Balancer (ALB) in front of an Auto Scaling group of WordPress Amazon EC2 instances in two AWS Regions and three Availability Zones in each Region. Configure an Amazon ElastiCache cluster in front of a global Amazon Aurora MySQL database. Move the WordPress shared files to Amazon FSx with cross-Region synchronization. Configure Amazon CloudFront with the ALB as the origin and a price class that includes the US and Europe.
Explanations:
This solution provides a scalable and stateless setup using an ALB and Auto Scaling group for WordPress instances, an ElastiCache cluster for improved read performance, and an Aurora MySQL DB cluster for high availability. Amazon EFS supports shared file storage, and CloudFront optimizes latency for users across Europe and the US with the appropriate price class. Meets all requirements for scalability, performance, low latency, and 99.9% availability.
This solution has some unnecessary complexity and cost by deploying across two AWS Regions. The cross-Region setup and additional EFS replication aren’t necessary to meet the requirements of low latency across Europe and the US. A single region with multiple AZs is sufficient for 99.9% availability.
Amazon DocumentDB is not compatible with WordPress, which requires MySQL-compatible databases. Using DocumentDB would not meet the requirement for improved read-heavy performance since WordPress cannot leverage this database natively.
FSx is not ideal for WordPress shared file storage; EFS is more appropriate for scalable shared storage. Additionally, setting up in two AWS Regions with cross-Region synchronization is overly complex for the availability target and latency requirements.
As I see it, the answer is:
Use an Application Load Balancer (ALB) in front of an Auto Scaling group of WordPress Amazon EC2 instances in one AWS Region and three Availability Zones. Configure an Amazon ElastiCache cluster in front of a Multi-AZ Amazon Aurora MySQL DB cluster. Move the WordPress shared files to Amazon EFS. Configure Amazon CloudFront with the ALB as the origin, and select a price class that includes the US and Europe.
I appraise that the answer is:
Use an Application Load Balancer (ALB) in front of an Auto Scaling group of WordPress Amazon EC2 instances in one AWS Region and three Availability Zones. Configure an Amazon ElastiCache cluster in front of a Multi-AZ Amazon Aurora MySQL DB cluster. Move the WordPress shared files to Amazon EFS. Configure Amazon CloudFront with the ALB as the origin, and select a price class that includes the US and Europe.