Une application déployée via CloudFormation utilise des API REST API Gateway intégrées à Lambda et DynamoDB. Il existe des environnements de développement, de test et de production, chacun avec sa propre table DynamoDB. Les modifications promues en production ont causé des problèmes inattendus, même si elles fonctionnaient en développement et en test. Pour la prochaine version, le développeur doit acheminer 20 % du trafic de production vers le nouveau déploiement d'API et 80 % vers le déploiement de production existant, en minimisant les risques qu'un client unique rencontre des erreurs. Quelle est la meilleure approche ?

La configuration des paramètres de déploiement canary pour l'étape d'API de production est la meilleure approche. API Gateway prend en charge les déploiements canary, permettant de diriger un pourcentage spécifié du trafic vers une nouvelle version de l'API tout en maintenant la majorité du trafic vers la version stable. Cela minimise le risque en exposant un petit sous-ensemble d'utilisateurs aux changements, permettant une surveillance et un retour d'information avant un déploiement complet. Les autres options sont moins efficaces ou plus risquées : Déployer 20 % des modifications à la fois est un processus manuel et itératif, sujet aux erreurs et ne garantissant pas un routage du trafic contrôlé. Modifier l'enregistrement DNS Route 53 pour pointer vers l'environnement de test n'est pas une bonne pratique, car l'environnement de test n'est pas conçu pour gérer le trafic de production et pourrait introduire des problèmes de configuration et de performance. Placer un Application Load Balancer devant l'API REST n'est pas nécessaire, car API Gateway offre déjà des fonctionnalités de gestion du trafic, y compris les déploiements canary, qui sont plus intégrées et optimisées pour les API.