Un'azienda sta migrando un sito web composto da un load balancer, un CMS basato su Linux che richiede storage persistente compatibile con NFS e un database MySQL. La soluzione deve scalare da 2 istanze EC2 a 30 istanze per traffico imprevedibile, non richiedere modifiche al CMS e prevenire la perdita di dati. Quale design soddisfa questi requisiti?

La soluzione corretta utilizza Amazon EFS per lo storage persistente compatibile con NFS, essenziale per il CMS e la scalabilità. AWS Elastic Beanstalk con Application Load Balancer e Auto Scaling gestisce la scalabilità da 2 a 30 istanze senza modifiche al CMS. L'uso di .ebextensions permette di montare EFS automaticamente sulle istanze EC2. Amazon Aurora MySQL, separato da Elastic Beanstalk, garantisce alta disponibilità e prevenzione della perdita di dati per il database. Le opzioni errate presentano i seguenti problemi: Amazon EBS Multi-Attach non è compatibile con NFS e ha limitazioni sul numero di istanze che possono accedervi contemporaneamente, rendendolo inadatto per la scalabilità a 30 istanze. Un Network Load Balancer non è l'ideale per il traffico HTTP/HTTPS di un sito web. L'opzione con il launch template e il Network Load Balancer ha problemi simili. Inoltre, montare EFS tramite un hook del ciclo di vita di scale-in non è il metodo corretto per garantire che sia disponibile al momento dell'avvio dell'istanza. L'opzione con EBS Multi-Attach e ElastiCache for Redis non soddisfa il requisito di un database MySQL e ha le stesse limitazioni di EBS Multi-Attach.