Eine auf AWS Elastic Beanstalk bereitgestellte Anwendung verwendet Amazon Aurora und wird von einer CloudFront-Distribution vorgeschaltet, die die Elastic Beanstalk-Domain als Ursprung verwendet. CloudFront ist mit einem alternativen Domainnamen konfiguriert, auf den Benutzer zugreifen. Jede Woche wird die Anwendung zur Wartung offline genommen; während dieser Zeit möchte das Unternehmen, dass Besucher eine Informationsseite sehen (keinen CloudFront-Fehler). Der erste Schritt – das Erstellen eines S3-Buckets – ist bereits erledigt. Welche drei Maßnahmen sollte der Solutions Architect als Nächstes ergreifen, um dieses Verhalten zu implementieren?

Zuerst muss der statische Inhalt der Wartungsseite in den S3-Bucket hochgeladen werden, da dieser als Quelle für die Informationsseite dient. Anschließend muss der S3-Bucket als zweiter Ursprung zur bestehenden CloudFront-Distribution hinzugefügt werden, nicht zu einer neuen. Eine Origin Access Identity (OAI) ist erforderlich, um den Zugriff auf den S3-Bucket nur über CloudFront zu ermöglichen und direkten Zugriff zu verhindern. Schließlich muss während der Wartung das Standard-Cache-Verhalten der CloudFront-Distribution so geändert werden, dass es auf den S3-Ursprung verweist. Nach der Wartung wird diese Änderung rückgängig gemacht, um den Datenverkehr wieder zur Elastic Beanstalk-Anwendung zu leiten. Eine neue CloudFront-Distribution wäre unnötig komplex und würde zusätzliche Konfigurationen erfordern. Das Hinzufügen eines Cache-Verhaltens mit Pfadmuster und Präzedenz wäre eine Option, aber das Ändern des Standard-Cache-Verhaltens ist für eine temporäre Umleitung des gesamten Datenverkehrs einfacher und direkter. Elastic Beanstalk kann den Datenverkehr nicht direkt vom S3-Bucket bereitstellen; dies muss über CloudFront erfolgen.