Ein Unternehmen migriert eine Website, die aus einem Load Balancer, einem Linux-basierten CMS, das NFS-kompatiblen persistenten Speicher benötigt, und einer MySQL-Datenbank besteht. Die Lösung muss von 2 EC2-Instances auf 30 Instances für unvorhersehbaren Datenverkehr skalierbar sein, darf keine Änderungen am CMS erfordern und Datenverlust verhindern. Welches Design erfüllt diese Anforderungen?

Die korrekte Option erfüllt alle Anforderungen. Amazon EFS bietet NFS-kompatiblen, skalierbaren Speicher, der von mehreren EC2-Instanzen gleichzeitig genutzt werden kann, was für das CMS entscheidend ist. AWS Elastic Beanstalk mit einem Application Load Balancer und einer Auto Scaling-Gruppe ermöglicht die einfache Bereitstellung und Skalierung von 2 auf 30 Instanzen ohne manuelle Konfiguration. Die Verwendung von .ebextensions ist der standardmäßige und effiziente Weg, um EFS auf Elastic Beanstalk-Instanzen zu mounten. Amazon Aurora MySQL ist eine hochverfügbare, skalierbare und performante Datenbanklösung, die Datenverlust verhindert und die Trennung von der Elastic Beanstalk-Umgebung ist eine Best Practice für die Datenbankverwaltung. Die anderen Optionen sind ungeeignet: Amazon EBS Multi-Attach ist nicht NFS-kompatibel und kann nicht von 30 Instanzen gleichzeitig genutzt werden. Ein Network Load Balancer ist für HTTP/HTTPS-Verkehr weniger geeignet als ein Application Load Balancer. Ein Network Load Balancer ist für HTTP/HTTPS-Verkehr weniger geeignet. Ein Scale-in Lifecycle Hook ist nicht der richtige Mechanismus zum Mounten von Dateisystemen. Amazon EBS Multi-Attach ist nicht NFS-kompatibel. ElastiCache for Redis ersetzt keine MySQL-Datenbank, sondern dient als Cache.