A company is migrating a website consisting of a load balancer, a Linux-based CMS that requires NFS-compatible persistent storage, and a MySQL database. The solution must scale from 2 EC2 instances to 30 instances for unpredictable traffic, require no changes to the CMS, and prevent data loss. Which design meets these requirements?

The correct design uses Amazon EFS for NFS-compatible persistent storage, which is scalable and accessible by multiple EC2 instances, meeting the CMS requirement without changes. Elastic Beanstalk simplifies deployment and management of the CMS, automatically configuring an Application Load Balancer and Auto Scaling group for scaling from 2 to 30 instances. Using .ebextensions ensures EFS is mounted consistently across all instances. An Amazon Aurora MySQL database provides a highly scalable, available, and durable solution for the database, preventing data loss. Incorrect options: EBS Multi-Attach is limited to 16 instances and specific instance types, not suitable for scaling to 30 instances or general CMS use. NLB is layer 4, while ALB is better for HTTP/HTTPS traffic. RDS inside Elastic Beanstalk is not a best practice for production. Using a Network Load Balancer is less suitable for HTTP/HTTPS traffic than an ALB. An EC2 Auto Scaling scale-in lifecycle hook for mounting EFS is incorrect; EFS should be mounted during instance launch, not scale-in. EBS Multi-Attach has scaling limitations. ElastiCache for Redis is an in-memory cache, not a replacement for a persistent MySQL database.