Amazon ECS Gateway automatise le réseau d’entrée de vos services et supprime le provisionnement par service
Le 20 octobre 2026, AWS lance ECS Gateway, une ressource de compte qui provisionne et gère à votre place les Application Load Balancers, certificats ACM, règles WAF et groupes de sécurité de vos services ECS. Une équipe plateforme définit la norme une fois, l’équipe applicative connecte son service en une ligne : c’est la fin du goulet d’étranglement d’entrée par service.
20 octobre 2026. AWS annonce Amazon ECS Gateway, une ressource de niveau compte qui provisionne et gère automatiquement l’infrastructure réseau d’entrée des services Amazon ECS. Un ALB pour vingt-cinq services. La même ressource partage un Application Load Balancer entre jusqu’à 25 services et attribue à chacun un nom d’hôte DNS unique, prêt à l’emploi dès la fin du provisionnement. Pourquoi c’est important : le câblage d’entrée — load balancer, certificat, WAF, groupes de sécurité — était jusqu’ici le goulot d’étranglement que chaque nouveau service rejouait à l’identique, et il disparaît.
Le problème que résout ECS Gateway
Sur ECS, faire tourner un conteneur est devenu simple. Le mettre en ligne, moins. Pour chaque nouveau service, une équipe devait provisionner et raccorder un Application Load Balancer, un certificat AWS Certificate Manager, une web ACL AWS WAF et des groupes de sécurité, puis maintenir ces ressources synchronisées à mesure que le service évolue. Multiplié par des dizaines de services, ce travail répétitif ralentit la vélocité de déploiement et augmente le risque de dérive de configuration — deux services censés être identiques finissent par diverger.
ECS Gateway attaque le problème à la racine en séparant les responsabilités. L’équipe plateforme crée la passerelle et fixe la norme réseau une seule fois : sous-réseaux, groupes de sécurité, certificats TLS, paramètres du listener et web ACL WAF. Elle associe ensuite la passerelle à un ou plusieurs clusters ECS. L’équipe applicative, elle, active son service en ajoutant un simple paramètre de connector lors de la création ou de la mise à jour — sans aucune expertise réseau.
Ce que la passerelle fait à votre place
Dès qu’un service se connecte, ECS provisionne les ressources par service automatiquement : un certificat ACM, un nom d’hôte DNS unique, des règles de listener, des target groups et un groupe de sécurité de service qui n’autorise le trafic entrant que depuis l’ALB.
Le routage par hôte (host-based routing) de l’ALB est au cœur du mécanisme : un même ALB porte plusieurs services, chacun sur son nom d’hôte. ECS gère ensuite le cycle de vie complet de l’infrastructure sous-jacente — il provisionne le premier ALB quand le premier service se connecte, ajoute des ALB quand la capacité est atteinte et les retire quand ils ne servent plus.
La relation est many-to-many : une passerelle peut être associée à jusqu’à 10 000 clusters, et un cluster supporte jusqu’à cinq associations de passerelles. Une équipe plateforme peut ainsi partager une passerelle entre environnements, ou attribuer plusieurs passerelles — publique et privée — à un même cluster.
Avant et après, en un tableau
Le changement se mesure le plus simplement en comparant ce qu’une équipe faisait à la main et ce que la passerelle prend en charge.
| Tâche d’entrée | Approche manuelle | Avec ECS Gateway |
|---|---|---|
| Load balancer | Un ALB par service, ou un partage maintenu à la main | Provisionné et partagé automatiquement |
| Certificat TLS | Créer, valider et attacher un certificat ACM | Créé et attaché automatiquement |
| WAF | Associer une web ACL ressource par ressource | Définie une fois sur la passerelle |
| Groupes de sécurité | Ouvrir des règles entrantes à la main | SG de service limité au seul trafic ALB |
| Fin de vie | Purger ALB, certificats et règles à la suppression | Nettoyage automatique à la suppression |
La ligne « fin de vie » est souvent la plus négligée : c’est là que naît la dérive de configuration, quand des ressources orphelines restent en place parce que personne n’a pensé à les supprimer. La passerelle ferme cette brèche par construction.
Le modèle de sécurité et d’IAM
La passerelle repose sur un rôle d’infrastructure IAM qu’ECS endosse pour créer les ALB, les groupes de sécurité et les certificats dans votre compte. C’est le point de contrôle central : la plateforme accorde à ce rôle le strict minimum pour provisionner le réseau, et rien de plus.
Le contrôle d’accès se joue ensuite à deux niveaux. D’abord, quelles passerelles sont associées à quels clusters — une équipe plateforme décide qui peut déployer vers quel environnement. Ensuite, des politiques IAM restrictives limitent qui peut créer ou connecter des services sur un cluster donné. Résultat : l’équipe applicative n’a jamais besoin des droits réseau larges qu’exigeait l’approche manuelle, et la surface d’erreur se réduit d’autant.
En pratique
La création se fait en console ou via la CLI. On crée d’abord la passerelle avec un rôle d’infrastructure IAM qu’ECS endosse pour provisionner ALB, groupes de sécurité et certificats dans votre compte.
aws ecs create-gateway \
--name my-team-gateway \
--infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole \
--configuration '{
"HostSharedAlb": {
"networkConfiguration": {
"subnets": ["subnet-080779f9bd887757a", "subnet-03d5b2fead6bc6258"],
"ipAddressType": "ipv4"
},
"scheme": "internet-facing"
}
}' Aucune infrastructure n’est provisionnée tant qu’un service ne se connecte pas. L’association au cluster vient ensuite :
aws ecs associate-gateway-with-cluster \
--gateway my-team-gateway \
--cluster arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster L’adoption est opt-in et sans migration : un service existant continue de tourner sur son ALB actuel tant qu’on ne lui ajoute pas de gateway connector. Vous pouvez donc basculer un cluster service par service, sans fenêtre de coupure, et comparer la passerelle à votre montage actuel avant de généraliser. Pour piloter le tout par du code, la passerelle expose ses API et se documente via le AWS MCP Server et ses plugins.
Ce qu’il faut surveiller
Quelques garde-fous évitent les surprises au déploiement.
- Réseau. La passerelle s’applique aux services en mode réseau awsvpc, sur ECS EC2, Fargate et ECS Managed Instances. Les zones de disponibilité de votre service doivent être un sous-ensemble de celles de la passerelle — l’ALB ne route que vers les tâches des AZ où il a des sous-réseaux.
- Capacité. Si
maxAlbCountest atteint et qu’aucun ALB n’a de place libre, le déploiement échoue. Le quota par défaut est 10 ALB par passerelle : dimensionnez-le selon le nombre de services attendus. - Observabilité. Suivez le trafic par service avec la dimension
TargetGroupdes métriques ALB dans CloudWatch, et le trafic de l’ALB partagé avec la dimensionLoadBalancer.describe-target-healthdonne l’état des cibles en temps réel. - Suppression. Quand un service est supprimé, ECS le déconnecte de toutes les passerelles, retire ses routes et nettoie ses ressources — et déprovisionne l’ALB s’il portait la dernière route.
- Paramètres immuables. Le nom, le schéma, le VPC, les sous-réseaux, le type d’adresse IP, ainsi que le protocole et le port du listener ne peuvent plus être modifiés après la création de la passerelle — choisissez-les juste du premier coup.
La passerelle est disponible dans toutes les régions commerciales où ECS existe, sans frais supplémentaires : vous payez l’infrastructure réellement provisionnée — ALB, logs et métriques CloudWatch, certificats ACM et transfert de données.
Où se situe la passerelle dans l’offre AWS
ECS Gateway ne remplace ni App Mesh ni API Gateway. App Mesh reste l’outil de la maille de service — mutual TLS, observabilité applicative, gestion du trafic entre services. API Gateway reste l’outil de la gestion d’API — quotas, authentification, plans d’usage. La passerelle couvre strictement l’entrée HTTP/HTTPS d’un service ECS, en routage par hôte : c’est la brique qui manquait entre un conteneur et Internet, désormais native du service.
Cette frontière est aussi sa limite. Pas de path-based routing avancé, pas de transformation de requêtes : pour ces besoins, vous continuerez à piloter un ALB ou un API Gateway à la main. La passerelle excelle sur le cas massif et répétitif — des dizaines de services web simples — et s’efface devant les besoins spécialisés.
Verdict
Si vous exploitez plus de quelques services ECS, adoptez ECS Gateway. Le coût d’entrée est nul, et le gain est proportionnel à la taille du parc : chaque service de plus cesse d’être un chantier réseau à part entière. Si vous êtes une équipe plateforme qui impose déjà une norme d’entrée, la passerelle matérialise cette norme dans une ressource unique au lieu d’un runbook. Si vous êtes sur EKS avec App Mesh ou un gateway API, restez où vous êtes — ceci n’est pas un remplacement, c’est la même logique enfin portée nativement sur ECS.