Si esegue una web app multi-tier su istanze EC2 dietro un ALB in una Regione primaria. L'ALB e il gruppo Auto Scaling sono replicati in una Regione di backup, ma i valori min e max del gruppo Auto Scaling sono entrambi impostati a zero. Un'istanza RDS Multi-AZ archivia i dati e ha una replica di lettura nella Regione di backup. Route 53 fornisce l'endpoint utente. È necessario ridurre l'RTO a meno di 15 minuti e abilitare il failover automatico alla Regione di backup senza una strategia attivo-attivo. Cosa si dovrebbe raccomandare?

L'opzione corretta abilita un failover automatico attivo-passivo con un RTO inferiore a 15 minuti. Il routing di failover di Route 53 reindirizza il traffico alla regione di backup quando il controllo di integrità primario fallisce. La funzione Lambda nella regione di backup promuove la replica di lettura RDS a istanza primaria e scala il gruppo Auto Scaling, garantendo la disponibilità del database e dell'applicazione. Le opzioni errate: Il routing basato sulla latenza non è adatto per un failover automatico attivo-passivo, poiché bilancia il traffico tra le regioni attive. Un allarme CloudWatch su HTTPCodeTarget5XXCount potrebbe non rilevare tutti i problemi di disponibilità e potrebbe avere un RTO più elevato. Configurare il gruppo Auto Scaling di backup con gli stessi valori min/max e il routing basato sulla latenza creerebbe un'architettura attivo-attivo, che non è richiesta. Rimuovere la replica di lettura e usare snapshot non è una strategia di failover efficiente per un RTO basso. AWS Global Accelerator con pesi uguali creerebbe un'architettura attivo-attivo. Un allarme CloudWatch potrebbe non essere abbastanza rapido o completo per un failover automatico.