API Gateway API wywołuje funkcję Lambda za pośrednictwem aliasu Lambda. Deweloper zaktualizował kod i chce umożliwić innym deweloperom testowanie nowej wersji bez wpływu na klientów korzystających z API. Które podejście zapewnia to przy najmniejszym nakładzie operacyjnym?

Poprawna odpowiedź to opublikowanie nowej wersji funkcji Lambda, utworzenie nowego etapu (stage) API Gateway zintegrowanego z tą nową wersją i użycie tego nowego etapu do testowania. To podejście jest najprostsze operacyjnie, ponieważ etapy API Gateway są zaprojektowane do izolowania środowisk (np. dev, test, prod). Nowy etap API Gateway może wskazywać na nową wersję funkcji Lambda, co pozwala na testowanie bez wpływu na istniejących klientów korzystających z produkcyjnego etapu API Gateway i jego powiązanej wersji funkcji Lambda. Zmiana istniejącego aliasu Lambda z routingiem ważonym jest bardziej złożona i może przypadkowo skierować ruch produkcyjny do nowej wersji, jeśli wagi nie zostaną prawidłowo skonfigurowane lub jeśli testujący użyją produkcyjnego punktu końcowego. Wdrożenie filtrującej funkcji Lambda wprowadza niepotrzebną złożoność i dodatkowy punkt awarii. Tworzenie oddzielnego API Gateway API jest nadmiernym rozwiązaniem, które wymaga zarządzania dwoma niezależnymi instancjami API Gateway, co zwiększa nakład operacyjny.