Een applicatie gebruikt een Amazon CloudFront-distributie met een openbare Application Load Balancer (ALB) in een regio als de standaard origin. De app is geïmplementeerd in een secundaire regio in een warm-standby-opstelling en het bedrijf vereist een RTO van nul seconden voor HTTP GET-verzoeken. Hoe kan failover naar de secundaire regio worden geautomatiseerd, zodat HTTP GET's aan die RTO voldoen?

Deze optie is correct omdat CloudFront Origin Groups zijn ontworpen voor automatische failover tussen origins, wat voldoet aan de RTO van nul seconden voor HTTP GET-verzoeken. Door de secundaire ALB als een tweede origin toe te voegen en een origingroep te configureren om te failoveren bij 5xx-fouten, handelt CloudFront de failover transparant af voor de eindgebruiker. De eerste optie is incorrect omdat het gebruik van Route 53 voor failover van CloudFront-distributies mogelijk niet voldoet aan een RTO van nul seconden vanwege DNS-caching en de tijd die nodig is voor DNS-wijzigingen om te propageren. De derde optie is incorrect omdat het wijzigen van de CloudFront-origin naar een Route 53-recordset met failoverbeleid nog steeds afhankelijk is van DNS-propagatie en de TTL van 0 heeft geen invloed op de caching van CloudFront zelf. De vierde optie is incorrect omdat een CloudFront-functie die 307-omleidingen retourneert, extra latentie introduceert en de RTO van nul seconden voor HTTP GET-verzoeken niet garandeert.