Which solution will meet these requirements?
Create an Amazon Elastic File System (Amazon EFS) file system. Deploy the CMS to AWS Elastic Beanstalk with an Application Load Balancer and an Auto Scaling group. Use .ebextensions to mount the EFS file system to the EC2 instances. Create an Amazon Aurora MySQL database that is separate from the Elastic Beanstalk environment.
Create an Amazon Elastic Block Store (Amazon EBS) Multi-Attach volume. Deploy the CMS to AWS Elastic Beanstalk with a Network Load Balancer and an Auto Scaling group. Use .ebextensions to mount the EBS volume to the EC2 instances. Create an Amazon RDS for MySQL database in the Elastic Beanstalk environment.
Create an Amazon Elastic File System (Amazon EFS) file system. Create a launch template and an Auto Scaling group to launch EC2 instances to support the CMS. Create a Network Load Balancer to distribute traffic. Create an Amazon Aurora MySQL database. Use an EC2 Auto Scaling scale-in lifecycle hook to mount the EFS file system to the EC2 instances.
Create an Amazon Elastic Block Store (Amazon EBS) Multi-Attach volume. Create a launch template and an Auto Scaling group to launch EC2 instances to support the CMS. Create an Application Load Balancer to distribute traffic. Create an Amazon ElastiCache for Redis cluster to support the MySQL database. Use EC2 user data to attach the EBS volume to the EC2 instances.
Explanations:
This option uses Amazon Elastic File System (EFS), which provides NFS-compatible persistent storage required by the CMS. Deploying the CMS on AWS Elastic Beanstalk with an Application Load Balancer and an Auto Scaling group allows for easy scaling from 2 to 30 EC2 instances. The use of.ebextensionsto mount EFS ensures that no changes are needed to the existing website configuration. Additionally, creating an Amazon Aurora MySQL database separately ensures data persistence and reliability.
While this option uses Elastic Beanstalk and allows for scaling, it incorrectly suggests using an Amazon EBS Multi-Attach volume, which is not suitable for CMS that requires persistent NFS-compatible storage. EBS volumes cannot be concurrently attached to multiple EC2 instances in the way required by the CMS. Moreover, using a Network Load Balancer instead of an Application Load Balancer is not necessary in this context.
Although this option correctly employs Amazon EFS for persistent storage and mentions an Amazon Aurora MySQL database, it uses an EC2 Auto Scaling scale-in lifecycle hook to mount the EFS file system, which is unnecessary and complicates the deployment. EFS can be mounted at instance startup without needing lifecycle hooks, which could potentially introduce risks for data accessibility and application downtime during scaling operations.
This option utilizes an Amazon EBS Multi-Attach volume, which is not suitable for the CMS as it does not meet the requirement for NFS-compatible persistent storage. Additionally, the option mentions creating an ElastiCache for Redis cluster, which does not relate directly to the requirements of the MySQL database and may complicate the architecture without a clear benefit. An Application Load Balancer is suitable, but the overall solution does not meet the core requirements.
I design that the answer is:
Create an Amazon Elastic File System (Amazon EFS) file system. Deploy the CMS to AWS Elastic Beanstalk with an Application Load Balancer and an Auto Scaling group. Use .ebextensions to mount the EFS file system to the EC2 instances. Create an Amazon Aurora MySQL database that is separate from the Elastic Beanstalk environment.