Une application est accessible à la fois via une distribution CloudFront et directement via un Application Load Balancer (ALB) exposé sur Internet. L'administrateur doit s'assurer que l'application n'est accessible que via CloudFront et non directement via l'ALB, sans modifier le code de l'application. Quelle configuration permet d'y parvenir ?

L'ajout d'un en-tête HTTP personnalisé dans la configuration d'origine de CloudFront permet à CloudFront d'inclure cet en-tête unique dans toutes les requêtes envoyées à l'ALB. En configurant une règle d'écouteur ALB pour autoriser uniquement les requêtes contenant cet en-tête et cette valeur spécifiques, et en configurant l'action par défaut de l'écouteur pour renvoyer un code 403 (Interdit), vous vous assurez que seules les requêtes provenant de CloudFront atteignent l'application. Les requêtes directes à l'ALB sans cet en-tête seront bloquées. Convertir l'ALB en interne ne fonctionnerait pas car CloudFront ne peut pas accéder directement aux ALB internes sans configuration réseau supplémentaire (par exemple, un VPC Peering ou Transit Gateway), ce qui n'est pas mentionné comme une option ou une exigence. Lambda@Edge est une solution plus complexe et coûteuse pour ce cas d'utilisation simple. Remplacer l'ALB public par un nouvel ALB interne est également une solution trop complexe et potentiellement perturbatrice, avec les mêmes problèmes d'accessibilité pour CloudFront qu'évoqués précédemment.