Una catena di agenzie di viaggio esegue un'applicazione su due istanze Amazon EC2 fisse dietro un record multivalore di Route 53 che restituisce gli Elastic IP delle istanze. L'applicazione utilizza DynamoDB per lo storage primario e una cache Redis self-hosted. Il contenuto delle destinazioni viene aggiornato trimestralmente; gli aggiornamenti provocano picchi di carico e hanno causato tempi di inattività. È necessario rendere l'applicazione altamente disponibile e in grado di gestire il carico di aggiornamento. Quale soluzione soddisfa queste esigenze?

La soluzione corretta affronta tutti i requisiti. L'implementazione di DAX migliora le prestazioni di DynamoDB, riducendo la latenza e alleviando il carico sul database, essenziale durante i picchi. Un gruppo Auto Scaling con un ALB garantisce alta disponibilità e scalabilità automatica delle istanze EC2 per gestire il traffico variabile. L'aggiornamento del record Route 53 per puntare all'ALB semplifica il routing e migliora la resilienza. Lo scaling pianificato delle istanze EC2 prima degli aggiornamenti trimestrali previene i tempi di inattività causati dai picchi di carico. Le opzioni errate presentano diverse carenze: L'uso di ElastiCache per Redis (invece di DAX per DynamoDB) non risolve direttamente i problemi di performance di DynamoDB. CloudFront con un gruppo Auto Scaling come origine non è l'approccio più diretto per bilanciare il carico delle istanze EC2 in questo scenario, e lo scaling manuale non è ideale per l'alta disponibilità. L'uso di ElastiCache per Memcached è una cache valida, ma DAX è specificamente ottimizzato per DynamoDB. L'ultima opzione include CloudFront e scaling manuale, che non sono ottimali per la scalabilità e l'alta disponibilità delle istanze EC2.