Aplikacja wdrożona za pośrednictwem CloudFormation używa interfejsów API REST API Gateway zintegrowanych z Lambda i DynamoDB. Istnieją etapy development, testing i production, każdy z własną tabelą DynamoDB. Zmiany wprowadzone do środowiska produkcyjnego spowodowały nieoczekiwane problemy, mimo że działały w środowiskach dev i test. W przypadku następnego wydania deweloper musi skierować 20% ruchu produkcyjnego do nowego wdrożenia API i 80% do istniejącego wdrożenia produkcyjnego, minimalizując ryzyko, że pojedynczy klient zobaczy błędy. Jakie jest najlepsze podejście?

Poprawna odpowiedź to skonfigurowanie wdrożenia canary dla etapu API Gateway. Wdrożenia canary w API Gateway pozwalają na stopniowe przekierowywanie procentu ruchu do nowej wersji API, jednocześnie utrzymując większość ruchu na stabilnej, istniejącej wersji. To minimalizuje ryzyko i pozwala na monitorowanie nowej wersji w środowisku produkcyjnym przed pełnym wdrożeniem. Pozostałe opcje są nieoptymalne lub błędne: Wdrażanie 20% zmian pięć razy jest nieefektywne i nie odnosi się do przekierowywania ruchu. Zmiana rekordu DNS Route 53 z polityką routingu ważonego wskazującą na etap testowy jest niewłaściwa, ponieważ etap testowy nie powinien obsługiwać ruchu produkcyjnego. Umieszczenie Application Load Balancer przed API REST jest niepotrzebne, ponieważ API Gateway natywnie obsługuje wdrożenia canary.