Un'azienda ospita un sito web con un servizio di backend distribuito in una regione AWS primaria e in una regione di disaster recovery (DR). Una singola distribuzione Amazon CloudFront si trova di fronte al sito. L'azienda ha creato un record di failover Route 53 con controlli di integrità che puntano al backend della regione primaria e ha configurato tale record come origine per la distribuzione CloudFront. Un record Route 53 di failover secondario punta al backend della regione DR. Entrambi i record Route 53 hanno un TTL di 60 secondi, ma il failover attualmente richiede più di un minuto. Quale design offre il tempo di failover più rapido?

L'opzione corretta è creare un gruppo di origine CloudFront con failover dell'origine. Questa configurazione consente a CloudFront di passare automaticamente e rapidamente all'origine secondaria (DR) se l'origine primaria non è disponibile, senza dipendere dal DNS di Route 53 per il failover. Il failover dell'origine di CloudFront è progettato per essere molto più veloce del failover DNS, che è soggetto ai TTL e alla propagazione della cache DNS. Le altre opzioni sono meno efficaci per un failover rapido: Implementare una seconda distribuzione CloudFront e un nuovo set di record di failover Route 53 per le distribuzioni CloudFront introdurrebbe complessità e non risolverebbe il problema del tempo di failover lento di Route 53. Modificare il TTL a 4 secondi per i record Route 53 esistenti migliorerebbe la velocità di failover DNS, ma il failover dell'origine di CloudFront è intrinsecamente più rapido e gestito a livello di CDN, non a livello DNS. Creare nuovi set di record Route 53 con una policy di routing di latenza non è l'obiettivo qui; l'obiettivo è il failover, non il routing basato sulla latenza, e dipenderebbe comunque dal DNS.