Un'applicazione critica è in esecuzione su una singola istanza EC2 e utilizza un cluster ElastiCache for Redis a nodo singolo più un'istanza DB RDS for MariaDB. Ogni componente deve essere integro e attivo affinché l'applicazione funzioni. È necessario riprogettare l'infrastruttura in modo che possa ripristinarsi automaticamente dai guasti con tempi di inattività minimi. Quale combinazione di modifiche dovresti implementare? (Scegliere tre.)

Per garantire l'alta disponibilità dell'applicazione, è fondamentale eliminare i singoli punti di errore. 1. Istanze EC2: Posizionare le istanze dell'applicazione dietro un Elastic Load Balancer (ELB) e utilizzare un gruppo Auto Scaling con una capacità minima di due istanze distribuisce il traffico e garantisce che l'applicazione rimanga disponibile anche se un'istanza fallisce. L'Auto Scaling sostituirà automaticamente le istanze non integre. 2. RDS for MariaDB: Modificare l'istanza DB RDS per utilizzare una distribuzione Multi-AZ su due Availability Zone fornisce un failover automatico a un'istanza standby in un'altra AZ in caso di guasto dell'istanza primaria, riducendo al minimo i tempi di inattività. 3. ElastiCache for Redis: Creare un gruppo di replica per ElastiCache for Redis e abilitare Multi-AZ garantisce che i dati siano replicati su più nodi in diverse AZ. In caso di guasto del nodo primario, un nodo di replica viene promosso automaticamente a primario, mantenendo la disponibilità della cache. L'opzione "configurare il gruppo EC2 Auto Scaling in modalità illimitata" non esiste. L'opzione di creare una replica di lettura RDS e promuoverla manualmente non offre il ripristino automatico desiderato. L'opzione di gestire ElastiCache con Auto Scaling non è il meccanismo corretto per la sua alta disponibilità; i gruppi di replica e Multi-AZ sono le soluzioni native.