Приложение доступно как через дистрибутив CloudFront, так и напрямую через Application Load Balancer (ALB), обращенный к интернету. Администратор должен убедиться, что приложение доступно только через CloudFront, а не напрямую через ALB, без изменения кода приложения. Какая конфигурация это обеспечивает?

Правильный ответ заключается в добавлении пользовательского HTTP-заголовка в конфигурацию источника CloudFront и создании правила прослушивателя ALB, которое разрешает только запросы с этим заголовком и значением, отклоняя остальные. CloudFront будет отправлять этот заголовок при каждом запросе к ALB. ALB, в свою очередь, будет проверять наличие этого заголовка. Если заголовок присутствует и соответствует ожидаемому значению, запрос будет обработан. В противном случае, если запрос поступает напрямую к ALB без этого заголовка (или с неправильным значением), ALB отклонит его с ошибкой 403 Forbidden. Это гарантирует, что доступ к приложению возможен только через CloudFront, без изменения кода приложения. Остальные варианты не подходят: Преобразование ALB во внутренний тип сделает его недоступным из интернета, но CloudFront не сможет к нему подключиться, так как CloudFront требует публичный источник. Использование Lambda@Edge для проверки секрета и перенаправления запроса к источнику является избыточным и более сложным решением, когда более простое правило ALB может выполнить ту же задачу. Замена публичного ALB на внутренний и установка источника CloudFront на него не сработает, так как CloudFront не может напрямую обращаться к внутренним ALB без дополнительных сетевых настроек, что не является частью стандартной конфигурации источника.