Amazon ECS ajoute les déploiements blue/green, linéaires et canary via VPC Lattice
Le 2 octobre 2026, Amazon ECS intègre des stratégies de déploiement blue/green, linéaires et canary pilotées nativement par VPC Lattice, avec validation par hooks et rollback automatique sur alarmes CloudWatch. Les équipes qui communiquent déjà entre VPC via Lattice peuvent désormais déplacer le trafic par paliers sans sortir d’ECS ni déployer un maillage de services.
2 octobre 2026. Amazon ECS prend en charge, nativement, les stratégies de déploiement blue/green, linéaire et canary pour les services qui communiquent via Amazon VPC Lattice. Le trafic se déplace désormais de manière contrôlée, directement depuis ECS, sans service de maillage externe. Pourquoi c’est important : les équipes qui routent déjà leurs appels entre VPC et comptes AWS à travers Lattice n’ont plus à greffer un outil tiers pour faire des montées de version progressives — la bascule fait partie de la configuration du service.
Ce que ça change concrètement pour un déploiement
Jusqu’ici, faire un déploiement progressif sur ECS exigeait soit un service de maillage de services, soit une orchestration externe de type CodeDeploy, soit de la tuyauterie manuelle sur les target groups. La nouveauté supprime cet intercalaire pour les services branchés sur VPC Lattice. On choisit sa stratégie dans la configuration du service ECS, on désigne ses target groups Lattice, sa règle de listener, et ECS déplace le trafic selon le rythme demandé.
Les trois stratégies couvrent les trois profils de confiance. Le blue/green bascule tout d’un coup d’une version à l’autre — adapté quand la nouvelle version a été largement validée en amont et qu’on veut un basculement net. Le linéaire avance par incréments égaux — une fraction fixe à chaque étape, pour ceux qui veulent un rythme prévisible et mesurable. Le canary commence par un petit pourcentage — le choix des équipes qui veulent exposer la nouvelle version à un échantillon réduit avant de généraliser.
L’essentiel n’est pas le menu de stratégies, déjà connu ailleurs, mais son intégration au cycle de vie. Une équipe peut valider la nouvelle version avec du trafic de test avant de basculer la production, puis déclencher des étapes de validation personnalisées ou des approbations manuelles via des hooks de cycle de vie — dont des hooks Lambda et des hooks de pause. Si la version se comporte mal, les alarmes CloudWatch et le circuit breaker de déploiement d’ECS déclenchent un rollback automatique, pendant qu’un bake time garde la version précédente prête pour un retour rapide sans interruption de service.
Pourquoi Lattice est le bon vecteur
Le choix de VPC Lattice comme support n’est pas anodin. Lattice est la brique d’AWS pour la communication de service à service entre VPC et entre comptes, avec routage par target groups et listeners. En l’adossant aux déploiements, AWS fait converger deux choses que les équipes maintenaient séparées : le routage applicatif (qui parle à qui, via quelles règles) et le cycle de vie de déploiement (comment une nouvelle version remplace l’ancienne). Le résultat est qu’un déplacement de trafic devient une opération de configuration déclarative, exprimable dans le console, la CLI, les SDK ou des outils d’infrastructure-as-code — et donc versionnable, rejouable et auditable comme le reste du service.
Cette convergence a un coût d’entrée à mesurer : elle ne profite qu’aux services qui sont déjà routés via Lattice. Une équipe qui communique encore par Service Discovery d’ECS ou par adresses directes devra d’abord migrer son routage vers Lattice avant de bénéficier des stratégies progressives. La fonctionnalité est disponible pour les services ECS nouveaux et existants, dans toutes les régions AWS où VPC Lattice est disponible — ce qui inclut les grandes régions commerciales, mais pas forcément les régions de moindre envergure ni les partitions GovCloud selon la couverture de Lattice elle-même.
Ce que cela enlève à votre stack, et ce que cela n’enlève pas
Le bénéfice immédiat est une pile moins épaisse : pas de contrôleur de maillage de services à opérer, pas d’outil de progressive delivery séparé à brancher, pas de script de bascule de target groups à maintenir. Le rollback automatique sur alarme CloudWatch et le bake time couvrent les deux scénarios les plus douloureux d’une montée de version — la régression qui passe inaperçue jusqu’en production et le retour en arrière qui exige de reconstruire l’ancienne version à la main.
Mais la fonctionnalité ne remplace pas le jugement de déploiement. Elle gère le mouvement du trafic, pas la qualité du signal. Les alarmes CloudWatch qui pilotent le rollback doivent être choisies avec soin : une alarme trop sensible déclenchera des retours en arrière inutiles, une alarme trop laxiste laissera une version dégradée absorber le trafic. Le canary à petit pourcentage ne détectera que ce que l’échantillon expose — une régression qui ne se manifeste que sous pleine charge ne sera pas vue pendant la phase canary. La règle reste la même qu’avec n’importe quel outil de progressive delivery : la stratégie est une enveloppe, les métriques qu’on y branche sont la vraie défense.
Verdict
Si vos services ECS communiquent déjà via VPC Lattice, activez ces stratégies dès votre prochain déploiement : vous remplacez une tuyauterie externe par une configuration déclarative, et vous gagnez le rollback automatique sur alarme sans ajouter d’outil. Si vous communiquez encore par Service Discovery ou adresses directes, pesez la migration vers Lattice comme un prérequis — elle vaut l’investissement si vos équipes multiplient les services entre VPC et comptes, mais elle n’est pas gratuite. Dans tous les cas, ne déléguez pas le jugement au mécanisme : choisissez des alarmes CloudWatch qui reflètent vos vrais signaux de santé — latence, taux d’erreur, saturation — et traitez le canary comme un détecteur de régression précoce, pas comme une preuve de fiabilité. Le déplacement de trafic est désormais un problème résolu par la plateforme ; la qualité de la bascule reste, elle, une décision d’équipe.