Eine Anwendung ist sowohl über eine CloudFront-Distribution als auch direkt über einen Internet-facing Application Load Balancer (ALB) erreichbar. Der Administrator muss sicherstellen, dass die Anwendung nur über CloudFront und nicht direkt über den ALB zugänglich ist, ohne den Anwendungscode zu ändern. Welche Konfiguration erreicht dies?

Die korrekte Lösung besteht darin, einen benutzerdefinierten HTTP-Header in der CloudFront-Origin-Konfiguration hinzuzufügen und eine ALB-Listener-Regel zu erstellen, die nur Anfragen mit diesem spezifischen Header und Wert weiterleitet. Alle anderen Anfragen, die direkt an den ALB gesendet werden und diesen Header nicht enthalten, werden mit einem 403-Fehler (Forbidden) abgewiesen. Dies stellt sicher, dass der Zugriff nur über CloudFront erfolgt, ohne den Anwendungscode zu ändern. Die Option, den ALB in einen internen Typ zu konvertieren, ist nicht praktikabel, da CloudFront keinen internen ALB als Origin verwenden kann, da dieser nicht über das Internet erreichbar ist. Eine Lambda@Edge-Funktion könnte zwar verwendet werden, ist aber komplexer als die Header-basierte Lösung und erfordert die Verwaltung von Lambda-Code. Die Option, den öffentlichen ALB durch einen neuen internen ALB zu ersetzen, hat das gleiche Problem wie die erste Option bezüglich der Erreichbarkeit für CloudFront.