Se puede acceder a una aplicación tanto a través de una distribución de CloudFront como directamente a través de un Application Load Balancer (ALB) con acceso a internet. El administrador debe asegurarse de que la aplicación solo sea accesible a través de CloudFront y no directamente a través del ALB, sin modificar el código de la aplicación. ¿Qué configuración logra esto?

La opción correcta garantiza que las solicitudes solo lleguen al ALB a través de CloudFront. Al configurar un encabezado HTTP personalizado en el origen de CloudFront, CloudFront lo añade a las solicitudes. Luego, una regla de oyente del ALB puede verificar este encabezado. Si el encabezado y su valor coinciden, la solicitud se reenvía a los destinos. Si el encabezado no está presente (lo que indica una solicitud directa al ALB), el ALB devuelve un 403, bloqueando el acceso directo. Esto no requiere cambios en el código de la aplicación. Las otras opciones son incorrectas porque: Convertir el ALB a interno no es suficiente; CloudFront no puede acceder a un ALB interno sin una configuración de red compleja (VPC peering, Transit Gateway, etc.), lo cual no es el caso de uso común para un origen de CloudFront. Lambda@Edge es una solución más compleja y costosa para este requisito específico, y la verificación de un secreto no es el método más directo para restringir el acceso del ALB. Reemplazar el ALB público por uno interno y agregar un encabezado personalizado es redundante y complica la arquitectura sin ofrecer una ventaja clara sobre la solución directa del encabezado.