Ритейлер запускает свое приложение электронной коммерции на инстансах EC2 за Application Load Balancer (ALB) с бэкендом Amazon RDS. CloudFront настроен с ALB в качестве источника для кэширования статического контента. Route 53 размещает публичные DNS. После обновления приложения ALB иногда возвращает HTTP 502 (Bad Gateway) из-за некорректных HTTP-заголовков, возвращаемых в ALB. Немедленная перезагрузка страницы обычно проходит успешно. Пока компания устраняет первопричину, архитектору решений необходимо показать пользовательскую страницу ошибки вместо стандартной страницы ALB с минимальными операционными издержками. Какая комбинация шагов позволит этого добиться? (Выберите два.)

Создайте бакет Amazon S3, настроенный для хостинга статических веб-сайтов. Загрузите пользовательские страницы ошибок в бакет S3. Настройте пользовательские ответы на ошибки CloudFront и укажите пользовательскую страницу ошибки. Обновите записи DNS, чтобы они указывали на общедоступную веб-страницу дистрибутива CloudFront. Объяснение: Проблема возникает из-за ошибок HTTP 502, возвращаемых ALB. Пользовательские ответы на ошибки CloudFront позволяют перехватывать эти ошибки и отображать вместо них статическую страницу, хранящуюся в S3. CloudFront находится перед ALB, поэтому он может перехватывать ошибки до того, как они достигнут конечного пользователя. S3 является идеальным решением для хостинга статических веб-сайтов благодаря своей высокой доступности и низкой стоимости. Неправильные варианты: Создание оповещений CloudWatch и функций Lambda для изменения правил пересылки ALB или Route 53 является избыточным и сложным для данной задачи. Это увеличивает операционные издержки и не является самым простым решением для отображения пользовательской страницы ошибки. Добавление проверок работоспособности Route 53 и резервного целевого объекта не решит проблему, так как ALB возвращает ошибку 502, а не полностью выходит из строя. Route 53 не будет переключаться на резерв, если ALB все еще отвечает, пусть и с ошибкой.