Schéma d'architecture AWS ECS sur Fargate : services, tâches et répartition de charge

Vous poussez l'image, vous créez le service, et les premières tâches n'atteignent jamais RUNNING. Elles s'arrêtent avec une ResourceInitializationError : unable to pull secrets or registry auth. L'image n'est pas en cause. Les tâches sont dans des sous-réseaux privés sans route vers Amazon ECR ni Secrets Manager, donc Fargate ne peut pas les démarrer.

Beaucoup de problèmes d'ECS sur Fargate ressemblent à celui-ci : les conteneurs fonctionnent, mais le réseau, les rôles ou les réglages du répartiteur de charge autour d'eux ne fonctionnent pas. Cet article décrit un service web de production sur Amazon ECS avec AWS Fargate, du réseau et de la répartition de charge à IAM, au scaling, aux déploiements et à ECS vs EKS, avec un schéma à copier.

Les concepts ECS en un tableau

Le cluster n'est pas une frontière réseau : les tâches s'exécutent dans les sous-réseaux que vous indiquez, derrière leurs propres groupes de sécurité. ECS ne facture rien pour l'orchestration ; Fargate facture à la seconde le vCPU, la mémoire et le stockage de chaque tâche, avec un minimum d'une minute.

Réseau : une ENI par tâche

Les tâches Fargate utilisent toujours le mode réseau awsvpc : chaque tâche reçoit sa propre interface réseau élastique (ENI), une IP privée de son sous-réseau et ses propres groupes de sécurité (réseau des tâches Fargate). Trois conséquences :

• Les sous-réseaux ont besoin de place. Chaque tâche prend une IP, et AWS en réserve cinq par sous-réseau. Soixante tâches sur deux AZ font 30 par sous-réseau, et un déploiement progressif à 200 % en demande brièvement 60. Un /24 (251 utilisables) suffit ; un /27 (27 utilisables) non.
• Les groupes de sécurité s'appliquent par tâche. Ouvrez le port du conteneur uniquement au groupe du répartiteur de charge, et le port 5432 de la base uniquement au groupe des tâches.
• Les tâches ont besoin d'un chemin vers les API AWS. Avant que votre code ne s'exécute, Fargate récupère l'image, va chercher les secrets et commence à envoyer les journaux par l'ENI de la tâche.

Depuis un sous-réseau privé, ce chemin est une passerelle NAT ou des endpoints VPC (tarifs US East au moment de la rédaction, novembre 2026) :

N'oubliez pas l'endpoint de passerelle S3 : ECR stocke les couches d'image dans S3 (endpoints d'interface ECR). Quatre endpoints d'interface dans deux AZ coûtent environ 58 USD par mois avant les données (8 × 0,01 USD × 730 heures), presque deux passerelles NAT à 66 USD. Les endpoints l'emportent donc sur les frais de données et la confidentialité, le NAT sur la portée. Depuis novembre 2025, une passerelle NAT régionale couvre les AZ d'elle-même et n'a pas besoin de sous-réseau public. Donner des IP publiques aux tâches fonctionne aussi, mais laisse chaque tâche à une seule règle de groupe de sécurité d'Internet. Le schéma de VPC AWS traite des routes et du placement du NAT.

Le répartiteur de charge : target groups et health checks

L'ALB demande des sous-réseaux dans au moins deux AZ, chacun en /27 ou plus grand avec huit adresses libres. Comme une tâche awsvpc est une ENI et non une instance EC2, le type du target group doit être ip. Utilisez un target group par service ; ECS enregistre et désenregistre les tâches.

Depuis novembre 2025, ECS Express Mode peut créer cette configuration d'ALB, de HTTPS et de scaling à partir d'une image de conteneur. Le schéma de répartiteur de charge traite des health checks et du drainage en général.

IAM : le rôle d'exécution et le rôle de tâche

Deux rôles, deux missions :

• Le rôle d'exécution de tâche est utilisé par ECS et l'agent Fargate, pas par votre code : il récupère l'image, écrit les journaux et lit les secrets nommés dans la task definition (rôle d'exécution de tâche). AmazonECSTaskExecutionRolePolicy couvre ECR et les journaux ; ajoutez vous-même secretsmanager:GetSecretValue, et kms:Decrypt pour une clé gérée par le client.
• Le rôle de tâche est celui que votre code utilise via le SDK AWS, pour S3 ou SQS, et celui dont ECS Exec a besoin.

Les secrets arrivent sous forme de variables d'environnement :

"secrets": [{
  "name": "DB_PASSWORD",
  "valueFrom": "arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/orders/db-AbCdEf:password::"
}]

ECS lit la valeur au démarrage du conteneur. Un secret renouvelé n'atteint pas les tâches en cours d'exécution : redéployez après la rotation, ou laissez l'application lire le secret avec son rôle de tâche. Choisir une seule clé JSON, comme ci-dessus, demande la plateforme en version 1.4.0, l'actuelle LATEST.

Scaling : target tracking et Fargate Spot

Pour Service Auto Scaling, commencez par le target tracking sur ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization ou ALBRequestCountPerTarget. Il monte vite en charge, redescend lentement et suspend la réduction pendant les déploiements ; avec plusieurs politiques, il ne réduit que si toutes sont d'accord. Gardez au moins une tâche par AZ.

Fargate Spot coûte jusqu'à 70 % de moins. Quand AWS récupère la capacité, la tâche reçoit un préavis de deux minutes, sous forme d'événement EventBridge avec le code d'arrêt SpotInterruption et d'un SIGTERM (capacity providers Fargate). stopTimeout plafonne à 120 secondes, et Fargate ne bascule jamais de lui-même vers la capacité normale, donc gardez une base :

"capacityProviderStrategy": [
  { "capacityProvider": "FARGATE", "base": 2, "weight": 1 },
  { "capacityProvider": "FARGATE_SPOT", "weight": 1 }
]

Les deux premières tâches s'exécutent toujours sur Fargate normal ; les autres se répartissent un pour un. Un service à une seule tâche sur Spot s'arrête simplement jusqu'au retour de la capacité.

Déploiements : progressif, blue/green, linéaire et canary

Le déploiement progressif (rolling) est le défaut : avec minimumHealthyPercent à 100 et maximumPercent à 200, ECS démarre les nouvelles tâches avant d'arrêter les anciennes. Activez le deployment circuit breaker avec rollback ; par défaut, il fait échouer un déploiement dès que les tâches en échec atteignent la moitié du nombre souhaité (au moins 3, au plus 200). Des alarmes CloudWatch peuvent déclencher le même rollback.

Depuis juillet 2025, ECS exécute lui-même les déploiements blue/green, sans CodeDeploy, et depuis octobre 2025 aussi les déploiements linéaires et canary. Ils démarrent la nouvelle révision derrière un second target group, déplacent le trafic du listener et gardent les anciennes tâches pendant un bake time, si bien que le rollback est un simple basculement de trafic.

Des hooks Lambda ou de pause peuvent conditionner chaque étape. Le target tracking sur ALBRequestCountPerTarget n'est pas pris en charge avec le blue/green. Le schéma des stratégies de déploiement compare ces modèles.

Observabilité

Le pilote awslogs demande awslogs-group, awslogs-region et, sur Fargate, awslogs-stream-prefix. Depuis le 25 juin 2025, il est par défaut en mode non-blocking avec un tampon de 10 Mo : un incident CloudWatch ne fige plus votre application, mais un tampon plein perd des lignes. Ajoutez Container Insights avec observabilité améliorée, ECS Exec pour les shells et une règle EventBridge sur les changements d'état des tâches ; la raison de l'arrêt (stopped reason) indique pourquoi une tâche est morte. Pour les traces, faites tourner un OpenTelemetry Collector en sidecar dans la tâche ; c'est le niveau agent d'un pipeline de logs, métriques et traces avec OpenTelemetry.

ECS vs EKS

Les tarifs viennent de la page de tarification d'EKS au moment de la rédaction (novembre 2026). Choisissez EKS quand vous avez besoin de la portabilité de Kubernetes ou de son écosystème ; le schéma d'architecture Kubernetes montre ce tableau. Pour un travail court et piloté par les événements, des architectures serverless basées sur Lambda se passent de tout service permanent.

Le schéma d'ECS sur Fargate

Comment le lire :

• Les AZ sont des lignes. Chacune a un sous-réseau public et un privé. L'ALB, RDS et les endpoints se trouvent entre les lignes, car chacun couvre les deux AZ : un nœud ALB dans chaque sous-réseau public, un standby Multi-AZ pour la base.
• Le bleu continu est le chemin des requêtes : HTTPS vers l'ALB, HTTP 8080 vers une tâche par AZ, SQL sur le port 5432.
• Le violet en pointillés est le trafic de la plateforme : le téléchargement de l'image, les secrets et les journaux, envoyés par Fargate avec le rôle d'exécution de tâche via les endpoints VPC.
• Seuls les sous-réseaux publics routent 0.0.0.0/0 vers la passerelle Internet.
• Le bloc Markdown liste les réglages du service.

Dessiner clairement des schémas ECS

• Placez les tâches dans des sous-réseaux par AZ. Une boîte « cluster ECS » autour de tout cache où les tâches s'exécutent et ce qu'elles peuvent joindre.
• Dessinez une tâche par AZ, avec la plage de scaling à côté.
• Montrez le chemin vers ECR, Secrets Manager et CloudWatch Logs. Un chemin manquant est une raison fréquente d'échec de démarrage des tâches.
• Étiquetez l'arête de l'ALB avec le port et le type de cible, et nommez le rôle derrière les arêtes en pointillés dans une légende.
• Omettez les sidecars, le CI/CD et les enregistrements DNS, sauf si le schéma les concerne.

Le modèle d'architecture AWS à trois niveaux a la même disposition de VPC avec EC2.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un VPC depuis le pack Réseau et quatre nœuds Sous-réseau à l'intérieur, un public et un privé pour chaque AZ.
3. Ajoutez un Répartiteur de charge cloud depuis le pack Cloud entre les sous-réseaux publics, et des notes Texte dans les sous-réseaux publics pour la route et le nœud ALB.
4. Ajoutez une Instance de calcul depuis le pack Cloud dans chaque sous-réseau privé, avec la taille de la tâche dans le champ du type d'instance.
5. Entre les sous-réseaux privés, ajoutez une Base de données gérée avec la haute disponibilité activée et une Ressource cloud pour les endpoints VPC, toutes deux depuis le pack Cloud.
6. En dehors du VPC, ajoutez Internet depuis le pack Réseau, Registre depuis le pack Docker, Coffre-fort depuis le pack Sécurité et Journaux depuis le pack DevOps.
7. Tracez des arêtes étiquetées, en pointillés pour le trafic de la plateforme, et ajoutez un bloc Markdown depuis le pack Base avec les réglages.

Les outils CloudFormation vers diagramme et Terraform vers diagramme transforment du code de stack existant en un premier brouillon ; pour dessiner le service à partir de Terraform, allégez le brouillon et ajoutez le chemin des requêtes à la main.

L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Fargate exige-t-il le mode réseau awsvpc ? Oui. Chaque tâche Fargate reçoit sa propre interface réseau et son adresse IP privée, c'est pourquoi ses target groups doivent utiliser le type de cible ip.

Quelle est la différence entre le rôle de tâche ECS et le rôle d'exécution de tâche ? Le rôle d'exécution permet à ECS de démarrer la tâche : récupérer l'image, aller chercher les secrets, envoyer les journaux. Le rôle de tâche est celui que le code de votre application utilise pour ses propres appels AWS.

Les tâches Fargate dans des sous-réseaux privés ont-elles besoin d'une passerelle NAT ? Pas pour les services AWS. Des endpoints d'interface pour ECR, CloudWatch Logs et Secrets Manager, plus l'endpoint de passerelle S3, suffisent. Vous n'avez besoin du NAT que pour joindre Internet.

ECS prend-il en charge les déploiements blue/green sans CodeDeploy ? Oui. ECS exécute le blue/green nativement depuis juillet 2025, et le linéaire et le canary depuis octobre 2025, avec des bake times, des lifecycle hooks et un rollback basé sur des alarmes.

ECS est-il moins cher qu'EKS ? Pour le plan de contrôle, oui : ECS n'a pas de frais d'orchestration, alors qu'un cluster EKS coûte 0,10 USD par heure en support standard. Les prix de Fargate et des instances EC2 sont les mêmes des deux côtés.

Commencez gratuitement — un siège, sans carte bancaire.