Bezserwerowa aplikacja internetowa jest wdrażana za pomocą funkcji Lambda przez CloudFormation. Ostatnie wydanie spowodowało awarię. Proces wdrażania musi obsługiwać wydania w stylu canary, aby przekierować część ruchu do nowej wersji Lambda. Które podejście to umożliwia?

Prawidłowa odpowiedź to utworzenie aliasu dla każdej nowo wdrożonej wersji Lambda i użycie polecenia AWS CLI update-alias z parametrem routing-config, aby podzielić ruch między wersje. AWS Lambda obsługuje wdrażanie canary poprzez aliasy, które mogą wskazywać na dwie wersje funkcji Lambda i rozdzielać ruch między nie na podstawie określonych wag. Parametr routing-config w update-alias pozwala na precyzyjną kontrolę nad procentowym podziałem ruchu. Pozostałe opcje są nieprawidłowe: Wdrożenie nowej wersji w osobnym stosie CloudFormation i użycie polityki routingu ważonego Amazon Route 53 nie jest optymalnym rozwiązaniem dla zarządzania wersjami funkcji Lambda, ponieważ Route 53 działa na poziomie DNS, a nie na poziomie funkcji. Użycie update-function-configuration z parametrem routing-config jest nieprawidłowe, ponieważ routing-config jest parametrem aliasu, a nie konfiguracji funkcji. AWS CodeDeploy może być używany do wdrażania funkcji Lambda, ale CodeDeployDefault.OneAtATime to strategia wdrażania typu "wszystko albo nic", a nie canary.