Una aplicación implementada en AWS Elastic Beanstalk utiliza Amazon Aurora y está precedida por una distribución de CloudFront que usa el dominio de Elastic Beanstalk como su origen. CloudFront está configurado con un nombre de dominio alternativo al que acceden los usuarios. Cada semana, la aplicación se desconecta para mantenimiento; durante ese tiempo, la empresa quiere que los visitantes vean una página informativa (no un error de CloudFront). El primer paso, crear un bucket de S3, ya está hecho. ¿Qué tres acciones debe realizar a continuación el arquitecto de soluciones para implementar este comportamiento?

Para mostrar una página de mantenimiento, primero se debe cargar el contenido estático en el bucket de S3. Luego, la distribución de CloudFront existente debe configurarse para añadir este bucket de S3 como un segundo origen, utilizando una Identidad de Acceso de Origen (OAI) para restringir el acceso directo al bucket y asegurar que solo CloudFront pueda acceder a él. Durante el mantenimiento, se edita el comportamiento de caché predeterminado de la distribución de CloudFront para que apunte al origen de S3, redirigiendo todo el tráfico a la página de mantenimiento. Una vez finalizado el mantenimiento, se revierte este cambio para que el tráfico vuelva a la aplicación de Elastic Beanstalk. Las opciones incorrectas no son viables porque: Crear una nueva distribución de CloudFront es innecesario y más complejo que modificar la existente. Añadir un comportamiento de caché con un patrón de ruta específico en una nueva distribución no es el enfoque correcto para redirigir todo el tráfico de la distribución principal. Configurar Elastic Beanstalk para servir desde S3 no es una función de Elastic Beanstalk y no utiliza la distribución de CloudFront existente para el mantenimiento.