Un'azienda desidera un'architettura più affidabile per la propria applicazione. L'applicazione attualmente utilizza un'istanza di database Amazon RDS e due server web Amazon EC2 con provisioning manuale in una singola zona di disponibilità. Un dipendente ha recentemente eliminato l'istanza di database e l'applicazione non è stata disponibile per 24 ore. Cosa dovrebbe fare un architetto di soluzioni per massimizzare l'affidabilità dell'infrastruttura dell'applicazione?

L'opzione corretta massimizza l'affidabilità affrontando sia il livello del database che quello dell'applicazione. L'aggiornamento del database RDS a Multi-AZ fornisce la ridondanza automatica e il failover in un'altra Zona di Disponibilità in caso di interruzione, mentre la protezione dall'eliminazione impedisce la cancellazione accidentale. L'utilizzo di un Application Load Balancer (ALB) distribuisce il traffico tra le istanze EC2, e un gruppo EC2 Auto Scaling su più Zone di Disponibilità garantisce che l'applicazione rimanga disponibile e possa scalare automaticamente, sostituendo le istanze non integre o terminate. L'opzione "Eliminare un'istanza EC2..." riduce la ridondanza a livello di applicazione e non migliora l'affidabilità. L'opzione "Creare un'istanza di database aggiuntiva..." introduce complessità non necessarie con API Gateway e Lambda per un problema che RDS Multi-AZ risolve in modo più efficiente. L'opzione "Posizionare le istanze EC2 in un gruppo EC2 Auto Scaling... Utilizzare istanze Spot..." introduce un rischio di interruzione con le istanze Spot, che non è l'ideale per massimizzare l'affidabilità.