L’arrivée d’Amazon ECS Gateway, une nouvelle ressource au niveau du compte, vise à résoudre un goulot d’étranglement récurrent dans la gestion des applications conteneurisées sur Amazon Elastic Container Service (ECS). Auparavant, pour chaque nouveau service, les équipes de plateforme devaient provisionner et maintenir manuellement un ensemble de composants : Application Load Balancers (ALB), certificats AWS Certificate Manager (ACM), listes de contrôle WAF (AWS WAF web ACLs) et groupes de sécurité. Ce surcoût par service ralentissait la vélocité de déploiement et augmentait le risque de dérive de configuration.

ECS Gateway prend en charge cette complexité en gérant dynamiquement l’infrastructure nécessaire en arrière-plan, créant tous les éléments directement dans l’environnement du client. Cette architecture instaure une séparation claire des responsabilités. Les équipes de plateforme définissent les normes de réseau – sous-réseaux, groupes de sécurité, certificats TLS et ACL WAF – au niveau du Gateway, puis l’associent aux clusters ECS. Les équipes d’application, quant à elles, activent le service en ajoutant simplement un paramètre de connecteur Gateway lors de la création ou de la mise à jour de leur service, sans nécessiter de connaissance approfondie en réseautique.

Le système permet aux services de bénéficier d’un routage basé sur l’hôte via un ALB partagé, optimisant les coûts en permettant jusqu’à vingt-cinq services de partager un seul ALB. Le cycle de vie de cette infrastructure est entièrement pris en charge par ECS : l’ALB est créé au premier service qui se connecte et supprimé quand plus aucun service n’en a besoin. Chaque service se voit attribuer un nom d’hôte unique, lui donnant un point d’accès prêt à l’emploi dès la finalisation du provisionnement.

La répartition des rôles entre plateforme et application

En coulisses, la puissance du Gateway réside dans cette division des tâches. Les équipes de plateforme créent le Gateway en spécifiant une fonction IAM dédiée à l’infrastructure et en définissant les paramètres généraux (schéma public ou interne VPC, ports, etc.). Cette définition globale est ensuite liée aux clusters ECS pertinents. D’après les documents AWS, ce lien est bidirectionnel : un Gateway peut être associé à dix mille clusters, et un cluster peut référencer jusqu’à cinq Gateways.

Pour l’équipe d’application, l’intégration se fait par une simple modification de la définition du service, en ajoutant le paramètre gateway-connectors lors de l’appel à CreateService ou UpdateService. Ce mécanisme permet une adoption progressive ; si un service existant utilisait déjà un ALB, il peut être mis à jour pour intégrer le Gateway tout en conservant son chemin d’accès précédent jusqu’à validation.

Il faut toutefois noter, comme le soulignent certains praticiens sur des forums de discussion, que le Gateway fournit un nom d’hôte généré, du type https://<identifiant>.ecs.<région>.on.aws. La question de l’intégration de domaines personnalisés, via Route 53 ou des enregistrements CNAME, n’est pas abordée dans la documentation officielle, suscitant des interrogations sur l’usage de cette fonctionnalité pour des environnements en production qui nécessitent une marque spécifique.

Contraintes et alternatives au niveau de l’infrastructure

Au-delà de l’automatisation de l’ingress, il est pertinent de comparer cette approche à d’autres méthodes de gestion du trafic dans l’écosystème cloud. Par exemple, Amazon EKS Auto Mode supporte désormais l’API Gateway Kubernetes, permettant une gestion de trafic standardisée via des ressources Gateway et HTTPRoute pour les utilisateurs de Kubernetes. Ce standard apporte une portabilité que l’approche propriétaire d’ECS Gateway ne garantit pas intrinsèquement. Les fonctionnalités de l’API Gateway incluent le fractionnement de trafic pondéré ou le routage basé sur des en-têtes.

Concernant les contraintes de ECS Gateway lui-même, AWS précise que le Gateway ne consolide pas les ALB existants, et que plusieurs ALB peuvent rester en place même après le départ de services. De plus, le système ne répare pas les changements effectués en dehors de lui ; modifier ou supprimer une ressource gérée peut entraîner l’arrêt du trafic. Le Gateway est limité à vingt-cinq services par ALB, avec un plafond documenté de deux cents ALB par Gateway, et les écouteurs ne servent HTTPS que sur le port 443. Surveiller ces limites est essentiel pour toute architecture à grande échelle.

Sources

• Introducing Amazon ECS Gateway: A fully-managed ingress solution for ECS services | Amazon Web Services, aws.amazon.com
• CreateService, docs.aws.amazon.com
• Amazon ECS Gateway Arrives with Generated Hostnames and No Custom Domain Support, InfoQ, 2 novembre 2026
• Amazon EKS Auto Mode now supports Kubernetes Gateway API, AWS, 28 octobre 2026