Firma handlowa używa regionalnego interfejsu API Amazon API Gateway dla swoich publicznych interfejsów REST API. API Gateway używa niestandardowej nazwy domeny, która mapuje się na rekord aliasu Amazon Route 53. Architekt rozwiązań potrzebuje podejścia do wdrożenia, które minimalizuje wpływ na klienta i minimalizuje utratę danych podczas wydawania nowej wersji API. Które rozwiązanie spełnia te wymagania?

Poprawna odpowiedź to utworzenie etapu wdrożenia canary release dla API Gateway. Canary deployment pozwala na stopniowe przekierowywanie ruchu do nowej wersji API, minimalizując wpływ na użytkowników i ryzyko awarii. Można monitorować nową wersję na małym procencie ruchu, a po weryfikacji promować ją do pełnej produkcji. Pozostałe opcje są mniej odpowiednie: Opcje z import-to-update w trybie merge lub overwrite bezpośrednio modyfikują istniejące API w środowisku produkcyjnym, co wiąże się z ryzykiem przerw w działaniu lub błędów, jeśli nowa wersja nie jest w pełni kompatybilna. Utworzenie zupełnie nowego punktu końcowego API Gateway i nowej niestandardowej nazwy domeny wymagałoby zmiany konfiguracji DNS Route 53, co może prowadzić do przestojów podczas propagacji zmian DNS i jest bardziej złożone niż canary deployment.