Zespół programistów startupu wdraża nową wielowarstwową aplikację w AWS. Aplikacja będzie działać na instancjach Amazon EC2 w grupie Auto Scaling za publicznym Network Load Balancer (NLB) i musi obsługiwać zarówno ruch UDP, jak i TCP. Początkowo będzie obsługiwać użytkowników w jednym obszarze geograficznym, ale zespół planuje rozszerzyć działalność na wiele regionów AWS, aby wdrożenia mogły być umieszczone bliżej użytkowników końcowych. Chcą kontrolować, ile ruchu otrzymuje każdy region podczas fazowych wdrożeń nowych wersji, a także muszą zminimalizować opóźnienie pierwszego bajtu i jitter dla użytkowników. Jak zespół powinien zaprojektować architekturę sieciową, aby spełnić te wymagania?

Prawidłowa odpowiedź to AWS Global Accelerator, ponieważ jest to usługa zaprojektowana do poprawy dostępności i wydajności aplikacji dla użytkowników globalnych poprzez kierowanie ruchu przez globalną sieć AWS. Obsługuje zarówno ruch TCP, jak i UDP, co jest kluczowe dla wymagań aplikacji. Funkcja "traffic dial" w Global Accelerator pozwala na kontrolowanie procentu ruchu kierowanego do poszczególnych regionów, co jest idealne do fazowanych wdrożeń. Minimalizuje również opóźnienia i jitter, kierując użytkowników do najbliższego punktu wejścia do sieci AWS. Pozostałe opcje są nieprawidłowe: Amazon CloudFront jest siecią dostarczania treści (CDN) i jest przeznaczony głównie do buforowania treści statycznych i dynamicznych, a nie do przyspieszania ruchu UDP lub zarządzania ruchem między regionami w sposób, który Global Accelerator oferuje dla aplikacji. Amazon S3 Transfer Acceleration służy do przyspieszania przesyłania plików do i z S3, a nie do przyspieszania ruchu aplikacji działających na instancjach EC2. Użycie Route 53 z polityką routingu opartą na opóźnieniach może kierować użytkowników do najbliższego regionu, ale nie oferuje precyzyjnej kontroli nad procentem ruchu kierowanego do każdego regionu, jak "traffic dial" w Global Accelerator, ani nie przyspiesza ruchu w taki sam sposób.