Une application web sert du contenu statique à partir d'un compartiment S3 derrière CloudFront et du contenu dynamique via un ALB acheminant vers des groupes Auto Scaling EC2. Le domaine est dans Route 53. Pendant les périodes de pointe, certains utilisateurs reçoivent des erreurs HTTP 503 Service Unavailable de la part de l'ALB. L'entreprise souhaite afficher une page d'erreur personnalisée immédiatement lorsque cette erreur se produit, avec un minimum de frais opérationnels. Quelle solution répond à cette exigence ?

L'option correcte est de créer un groupe d'origines CloudFront avec l'ALB comme origine principale et un site web statique S3 hébergeant la page d'erreur personnalisée comme origine secondaire. En activant le basculement d'origine, CloudFront basculera automatiquement vers l'origine S3 et affichera la page d'erreur personnalisée si l'ALB renvoie une erreur HTTP 503, ce qui répond à l'exigence d'afficher la page immédiatement avec un minimum de frais opérationnels. Les autres options sont moins optimales : Le routage de basculement Route 53 avec une vérification de l'état de santé surveillant l'ALB est trop lent pour une réponse immédiate car la propagation DNS et la détection de l'état de santé prennent du temps. Créer une deuxième distribution CloudFront et un site web statique S3 avec routage de basculement Route 53 est également trop lent et ajoute de la complexité inutile. Une fonction CloudFront inspectant chaque code de réponse HTTP de l'ALB ajoute des frais opérationnels et de la latence, et n'est pas la méthode la plus efficace pour gérer le basculement d'origine.