Una migrazione lift-and-shift ha lasciato un singolo gruppo Auto Scaling in cui ogni istanza EC2 esegue componenti web, di database e di cache Redis, causando tempi di risposta variabili e istanze sovraccariche. L'azienda desidera separare i componenti per migliorare la disponibilità e le prestazioni. Quale modifica architetturale soddisferà questo requisito?

L'opzione corretta separa i componenti in servizi AWS gestiti e scalabili, migliorando disponibilità e prestazioni. Un Application Load Balancer (ALB) e un gruppo Auto Scaling per l'applicazione web gestiscono il traffico HTTP/S e scalano dinamicamente. Amazon Aurora con Multi-AZ offre un database relazionale altamente disponibile e scalabile. Un cluster Amazon ElastiCache (Redis OSS) fornisce una soluzione di caching in-memory ad alte prestazioni e gestita, eliminando la necessità di Redis sulle istanze EC2. Le opzioni errate presentano diverse problematiche: La prima opzione suggerisce un Network Load Balancer (NLB) per l'applicazione web, che è più adatto per il traffico a livello di rete (TCP/UDP) piuttosto che HTTP/S, e un ALB per Redis, che non è il servizio appropriato per una cache. La seconda opzione propone un NLB e un gruppo Auto Scaling in una singola Availability Zone per Redis, compromettendo la disponibilità. La terza opzione suggerisce un NLB per l'applicazione web e un target group con target DNS che puntano all'hostname di ElastiCache, il che non è il modo standard per integrare ElastiCache con un ALB/NLB, e un NLB non è ideale per l'applicazione web.