Приложение, развернутое с помощью CloudFormation, использует REST API Gateway, интегрированные с Lambda и DynamoDB. Существуют среды разработки, тестирования и продакшена, каждая со своей таблицей DynamoDB. Изменения, перенесенные в продакшен, вызвали непредвиденные проблемы, хотя они работали в dev и test. Для следующего релиза разработчику необходимо направить 20% продакшен-трафика на новое развертывание API и 80% на существующее продакшен-развертывание, минимизируя вероятность того, что какой-либо отдельный клиент увидит ошибки. Какой подход является наилучшим?

Настройка канареечного развертывания для стадии API Gateway позволяет постепенно направлять небольшой процент трафика на новую версию API, минимизируя риск для конечных пользователей. Это позволяет разработчику направить 20% трафика на новое развертывание, наблюдая за его поведением, прежде чем полностью переключить трафик. Первый вариант (развертывание 20% изменений пять раз) не является эффективным, так как это не контролирует трафик на уровне API Gateway и может привести к неполным или некорректным развертываниям. Второй вариант (изменение записи DNS Route 53 на тестовую среду) неверен, так как тестовая среда обычно не предназначена для обработки продакшен-трафика и может иметь другую конфигурацию или данные. Третий вариант (использование Application Load Balancer перед REST API) избыточен и не является нативным решением для управления трафиком между версиями API Gateway. API Gateway имеет встроенные функции для канареечных развертываний.