Aplikacja wdrożona na AWS Elastic Beanstalk korzysta z Amazon Aurora i jest obsługiwana przez dystrybucję CloudFront, która używa domeny Elastic Beanstalk jako swojego źródła. CloudFront jest skonfigurowany z alternatywną nazwą domeny, do której użytkownicy mają dostęp. Co tydzień aplikacja jest wyłączana w celu konserwacji; w tym czasie firma chce, aby odwiedzający widzieli stronę informacyjną (a nie błąd CloudFront). Pierwszy krok — utworzenie bucketu S3 — został już wykonany. Jakie trzy działania powinien podjąć architekt rozwiązań, aby zaimplementować to zachowanie?

Przesłanie statycznej zawartości informacyjnej do bucketu S3 jest pierwszym logicznym krokiem, ponieważ to właśnie ta strona ma być wyświetlana podczas konserwacji. Konfiguracja istniejącej dystrybucji CloudFront w celu dodania bucketu S3 jako drugiego źródła jest kluczowa, ponieważ pozwala CloudFront na przełączanie się między źródłami. Użycie OAI zapewnia, że tylko CloudFront może uzyskać dostęp do bucketu S3, zwiększając bezpieczeństwo. Edytowanie domyślnego zachowania pamięci podręcznej istniejącej dystrybucji CloudFront, aby wskazywało na źródło S3 podczas konserwacji, a następnie cofnięcie tej zmiany, jest efektywnym sposobem na dynamiczne przełączanie ruchu bez tworzenia nowej dystrybucji. Tworzenie zupełnie nowej dystrybucji CloudFront jest niepotrzebne i bardziej złożone. Konfigurowanie Elastic Beanstalk do obsługi ruchu z S3 jest niewłaściwe, ponieważ CloudFront powinien zarządzać przekierowaniem. Dodawanie i usuwanie zachowania pamięci podręcznej w nowej dystrybucji jest niepotrzebne, gdy można użyć istniejącej.