Una aplicación implementada a través de CloudFormation utiliza API Gateway REST APIs integradas con Lambda y DynamoDB. Hay etapas de desarrollo, pruebas y producción, cada una con su propia tabla de DynamoDB. Los cambios promovidos a producción han causado problemas inesperados a pesar de que funcionaron en desarrollo y pruebas. Para la próxima versión, el desarrollador necesita enrutar el 20% del tráfico de producción a la nueva implementación de la API y el 80% a la implementación de producción existente, minimizando la posibilidad de que un solo cliente vea errores. ¿Cuál es el mejor enfoque?

La configuración de implementaciones canary en API Gateway permite enrutar un porcentaje específico del tráfico a una nueva versión de la API mientras el resto del tráfico sigue yendo a la versión estable. Esto minimiza el impacto de posibles errores, ya que solo un pequeño subconjunto de usuarios experimenta la nueva versión inicialmente. Si surgen problemas, se pueden revertir rápidamente sin afectar a la mayoría de los usuarios. Las otras opciones son menos adecuadas: Implementar los cambios en producción en incrementos del 20% es un proceso manual y propenso a errores, sin una gestión automática del tráfico o reversión. Cambiar el registro DNS de Route 53 a una política de enrutamiento ponderado es una opción para balancear el tráfico entre diferentes puntos finales, pero no es específica para las etapas de API Gateway y no ofrece la misma granularidad de control para las implementaciones canary. Además, usar la etapa de pruebas para tráfico de producción no es una buena práctica. Colocar un Application Load Balancer (ALB) delante de la REST API añade complejidad innecesaria y coste, ya que API Gateway ya ofrece funcionalidades de gestión de tráfico y etapas. Además, no es la forma nativa de API Gateway para gestionar despliegues canary.