Een legacy workload heeft de stateless applicatielaag op één grote EC2-instantie die is gestart vanuit een AMI, en de MySQL-database op één EC2-instantie. De CPU op de app-server bereikt vaak 100%, wat storingen veroorzaakt. Patches worden handmatig toegepast en hebben downtime veroorzaakt. Het bedrijf moet de applicatie zeer beschikbaar maken met de minste ontwikkelingsinspanning. Welke oplossing voldoet aan deze vereiste?

De correcte optie pakt de beschikbaarheidsproblemen aan met minimale ontwikkelingsinspanning. Het creëren van een nieuwe AMI met de SSM Agent maakt geautomatiseerd patchen mogelijk, wat downtime vermindert. Het gebruik van een Auto Scaling Group met een Application Load Balancer verdeelt de belasting, voorkomt CPU-pieken en verhoogt de beschikbaarheid. Het migreren naar Amazon Aurora MySQL biedt een zeer beschikbare, schaalbare en compatibele databaseoplossing met minimale wijzigingen aan de applicatie. De andere opties vereisen aanzienlijke herstructurering (Lambda, ECS) of introduceren incompatibele databases (DocumentDB, DynamoDB, Neptune), wat indruist tegen de eis van minimale ontwikkelingsinspanning. Het wijzigen naar een kleinere Graviton-instantie zonder Auto Scaling lost het schaalbaarheidsprobleem niet op.