À qui s’adresse « ECS Fargate prod : patterns SRE » ?

Aux praticiens DevOps / platform / SRE qui veulent un lab concret 2026 sur ecs fargate prod. Prérequis et niveau sont indiqués en tête de page.

Faut-il un cluster ou un compte cloud pour ecs fargate prod ?

Oui dans la plupart des labs WOW (kube local, Free Tier ou sandbox). Suivez la section Prérequis pour outils, droits et coûts.

Ce tuto remplace-t-il la doc officielle ?

Non : c’est un parcours hands-on orienté DevOps Elastic Hayway. Gardez la doc upstream pour les API et breaking changes.

ECS Fargate prod : patterns SRE

À la fin de ce tutoriel, vous saurez opérer ECS Fargate en production comme un SRE : service derrière ALB multi-AZ, deployment circuit breaker, health checks, autoscaling, secrets/IAM, observabilité CloudWatch, et un lab CLI en ca-central-1. Fondations dans aws-ecs-fargate ; ici l’angle est patterns prod DevOps Elastic Hayway (DEH).

Niveau : Intermédiaire · Temps estimé : 60–80 min · Versions cibles : AWS CLI v2 · ECS / Fargate 2026 · ALB · CloudWatch · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-ecs-fargate-prod · Série : WOW (20/50) · Mot-clé SEO : ECS Fargate prod · Publish : HOLD

← Précédent : EKS Pod Identity · → Suivant : Lambda Powertools · Aussi : ECS Fargate (lab) · ALB · CloudWatch alarmes

Prérequis

Lab Fargate simple — ECS Fargate
Notions ALB — ALB équilibrage de charge
Compte lab (AWS_PROFILE=lab) — Démarrer avec AWS
VPC avec ≥ 2 subnets publics (ou privés + NAT) dans ca-central-1

Coût estimé : quelques € (Fargate + ALB facturés à l’heure). Cleanup obligatoire. Pas de NAT/RDS « pour tester ».

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

ECS Fargate prod (WOW 20/50) — ca-central-1
  ├── Pourquoi Fargate en prod (vs EC2 launch type / EKS)
  ├── Contrats SRE : tâches, service, rolling, circuit breaker
  ├── Patterns DEH : ALB multi-AZ + health + secrets + scale
  ├── Observabilité Container Insights / logs / alarmes
  ├── Lab : service Fargate + ALB + circuit breaker (CLI)
  └── Anti-patterns + checklist + quiz + FAQ

(Schéma — alt : « Service ECS Fargate derrière ALB multi-AZ en ca-central-1, circuit breaker et autoscaling ».)

Étape 1 — Pourquoi Fargate en prod (SRE) ?

Fargate = compute managé pour ECS : vous définissez CPU/mémoire de la task, AWS place le conteneur. Pas de patch AMI, pas de capacity provider EC2 à soigner.

Approche	Quand DEH le choisit	Limite
Fargate	Microservices HTTP, workers, jobs courts, équipes sans ops EC2	Moins de knobs GPU / host network
ECS + EC2	GPU, densification, Spot agressif, custom daemon	Patch + capacity = toil
EKS	API Kubernetes, operators, multi-cloud tooling	Control plane + courbe

Lab = 1 task IP publique. Prod = ALB, multi-AZ, rolling safe, secrets hors image, métriques actionnables. DEH : Fargate quand le coût ops EC2 dépasse le premium Fargate.

Étape 2 — Contrats SRE ECS à maîtriser

Concept	Contrat prod
Task definition	Immutable revision ; CPU/mem fixes ; `essential` ; logs `awslogs`
Service	Maintient `desiredCount` ; rolling / blue-green
Health check	Conteneur et cible ALB (HTTP `/health`)
Circuit breaker	Rollback auto si le déploiement échoue
Execution role	Pull ECR + write logs
Task role	App → APIs AWS (S3, Secrets Manager…) — moindre privilège

Fargate impose awsvpc : chaque task a une ENI. En prod, préférez subnets privés + egress contrôlé ; lab court peut rester public derrière ALB.

Étape 3 — Patterns prod sans drama (DEH)

ALB + Target Group ip (awsvpc) sur ≥ 2 AZ
Health check ALB (/health, interval 15–30 s) + healthCheckGracePeriodSeconds
Deployment circuit breaker enable=true, rollback=true
minimumHealthyPercent=100, maximumPercent=200 (rolling sans trou)
Secrets via Secrets Manager / SSM dans la task def — jamais dans l’image
Autoscaling : target tracking CPU ou ALBRequestCountPerTarget
Tags env, service, owner + alarmes 5xx / CPU / RunningTaskCount

[ Client HTTPS ]
       │
       ▼
[ ALB multi-AZ — ca-central-1a/b ]
       │
       ▼
[ Target Group ip → tasks Fargate ]
  ├── Task rev:N  (healthy)
  └── Task rev:N+1 (rolling + circuit breaker)
       │
[ CloudWatch Logs + Container Insights + Alarmes ]

Blue/green CodeDeploy si vous voulez bascule traffic contrôlée ; pour la majorité des APIs DEH, rolling + circuit breaker suffit.

Étape 4 — Secrets, IAM et réseau

Execution role : AmazonECSTaskExecutionRolePolicy (+ secretsmanager:GetSecretValue / SSM si injectés)
Task role : policies app uniquement (pas AdministratorAccess)
SG ALB : 443/80 depuis Internet (ou CloudFront) ; SG tasks : seulement depuis le SG ALB sur le port app
ECR privé + scan ; images digérées (@sha256:…) en prod stricte

Voir aussi EKS Pod Identity pour le parallèle identité pods — sur ECS, le task role est l’équivalent mental.

Étape 5 — Lab : service Fargate + ALB + circuit breaker

Objectif lab : un service desiredCount=2 derrière un ALB, circuit breaker ON, image publique nginx:alpine (ou votre image ECR). Adaptez VPC/subnets.

export AWS_PROFILE=lab AWS_DEFAULT_REGION=ca-central-1

# IDs lab (remplacez)
VPC_ID=vpc-xxxxxxxx
SUBNET_A=subnet-aaaa  # AZ a
SUBNET_B=subnet-bbbb  # AZ b
SG_ALB=$(aws ec2 create-security-group --group-name lab-ecs-alb-sg 
  --description "ALB lab ECS" --vpc-id "$VPC_ID" --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG_ALB" 
  --protocol tcp --port 80 --cidr 0.0.0.0/0

SG_TASK=$(aws ec2 create-security-group --group-name lab-ecs-task-sg 
  --description "Tasks lab ECS" --vpc-id "$VPC_ID" --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG_TASK" 
  --protocol tcp --port 80 --source-group "$SG_ALB"

Créez cluster, task definition (Fargate, awsvpc, port 80, awslogs), ALB + TG ip, listener 80, puis le service :

aws ecs create-service 
  --cluster lab-ecs-prod 
  --service-name lab-web 
  --task-definition lab-nginx 
  --desired-count 2 
  --launch-type FARGATE 
  --network-configuration "awsvpcConfiguration={subnets=[$SUBNET_A,$SUBNET_B],securityGroups=[$SG_TASK],assignPublicIp=ENABLED}" 
  --load-balancers "targetGroupArn=$TG_ARN,containerName=nginx,containerPort=80" 
  --health-check-grace-period-seconds 60 
  --deployment-configuration "minimumHealthyPercent=100,maximumPercent=200,deploymentCircuitBreaker={enable=true,rollback=true}"

Vérifiez :

aws ecs describe-services --cluster lab-ecs-prod --services lab-web 
  --query 'services[0].{running:runningCount,desired:desiredCount,rollouts:deployments}'
curl -sI "http://$ALB_DNS/" | head -5

Cleanup : desired-count 0 → delete-service --force → delete ALB/TG/listener → delete cluster si vide → delete SGs. Fargate + ALB laissés tournent = facture.

Étape 6 — Observabilité et runbook

CloudWatch Logs : groupe /ecs/lab-web, rétention définie
Container Insights sur le cluster (CPU/mem task, network)
Alarmes : HTTPCode_Target_5XX_Count, CPU > 70 %, RunningTaskCount < desired
Déploiement raté : circuit breaker → événement ECS → rollback ; lire stoppedReason des tasks

Runbook court : 5xx spike → TG health → logs task → dernière revision → update-service --force-new-deployment seulement si cause claire (config/secret), sinon rollback révision précédente.

Étape 6b — Scaling et déploiements quotidiens

Autoscaling Application Auto Scaling : registre la resource ID service/<cluster>/<service>, policy TargetTracking sur ECSServiceAverageCPUUtilization (cible 60–70 %) ou métrique ALB ALBRequestCountPerTarget. Évitez le scale-in agressif pendant un rolling — laissez un cooldown raisonnable.

Pour un déploiement de config :

aws ecs update-service --cluster lab-ecs-prod --service lab-web 
  --task-definition lab-nginx:2 --force-new-deployment

Surveillez deployments jusqu’à une seule entrée PRIMARY healthy. Si le circuit breaker rollback, corrigez la revision avant de forcer un nouveau déploiement. Documentez le numéro de révision « dernière bonne » dans le runbook.

Capacity providers : FARGATE (baseline) et optionnellement FARGATE_SPOT pour workers. Un service API user-facing DEH reste en majorité FARGATE On-Demand.

Étape 7 — Anti-patterns

Anti-pattern	Remplacez par
1 task, 1 AZ, IP publique seule	ALB + ≥ 2 tasks / 2 AZ
Secrets dans ENV en clair dans le repo	Secrets Manager / SSM + task role
Rolling `minimumHealthyPercent=0`	100 / 200 + circuit breaker
Execution role = task role admin	Deux rôles, least privilege
Aucun `/health`	Endpoint léger + check ALB
Scale manuel au feeling	Target tracking + alarmes

Checklist prod DEH

[ ] Multi-AZ + ALB + TG ip
[ ] Circuit breaker + rollback
[ ] Health conteneur + ALB + grace period
[ ] Execution role ≠ task role
[ ] Secrets hors image
[ ] Autoscaling + alarmes 5xx/CPU
[ ] Tags + rétention logs
[ ] Runbook rollback documenté
[ ] Cleanup lab / budget alert

Quiz (5 questions)

1. En Fargate, le mode réseau des tasks est :
– A. bridge
– B. awsvpc
– C. host

2. Le deployment circuit breaker sert surtout à :
– A. Augmenter desiredCount
– B. Rollback auto si le déploiement échoue
– C. Remplacer l’ALB

3. Region lab de ce tuto :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

4. Le Target Group pour Fargate awsvpc utilise le type :
– A. instance
– B. ip
– C. lambda

5. Qui tire l’image ECR et écrit les logs ?
– A. Task role
– B. Execution role
– C. Instance profile EC2 (toujours)

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : cohérence IAM/FinOps. Placez les tasks sur plusieurs AZ dans ca-central-1.

Fargate vs EC2 launch type en prod ?

Fargate = moins de toil host. EC2 = densification, GPU, Spot host. DEH démarre Fargate pour APIs standards ; EC2 si FinOps densifié justifié.

Fargate Spot en prod ?

Possible pour workloads interruptibles (batch). APIs user-facing : capacity provider FARGATE (On-Demand) en baseline ; Spot en burst tolérant. Voir Spot en prod.

Blue/green ou rolling ?

Rolling + circuit breaker = défaut DEH. Blue/green (CodeDeploy) si bascule traffic / validation shadow critique.

Combien de tasks minimum ?

Prod : ≥ 2 (idéalement réparties 2 AZ). Lab : 1 acceptable, puis montez à 2 pour valider le rolling.

Où mettre les secrets ?

Secrets Manager ou SSM Parameter Store, référencés dans la task definition ; droits sur l’execution role (injection) et politiques app sur le task role si l’app lit encore AWS.

Lien avec EKS ?

Même besoin (multi-AZ, health, identity, obs). EKS si vous voulez l’écosystème Kubernetes. Voir EKS concepts et Pod Identity.

Pour aller plus loin

Maillage série WOW


← Précédent	EKS Pod Identity
→ Suivant	Lambda Powertools
Aussi	ECS Fargate lab · ALB · CloudWatch

Meta publication (SEO)

Title SEO : ECS Fargate prod : patterns SRE (ALB, circuit breaker, guide FR)
Meta description : ECS Fargate en production : patterns SRE — ALB multi-AZ, circuit breaker, scaling, secrets, lab ca-central-1, FAQ, quiz et check-list DEH.
Focus keyword : ECS Fargate prod
Secondary : Amazon ECS Fargate production, ECS circuit breaker, ECS ALB multi-AZ, Fargate SRE
Image : assets/web/devopelastichayway/cover-wow-ecs-fargate-prod-1200x630.webp (à générer)
Catégorie : WOW / AWS · Niveau : Intermédiaire
URL cible : https://devopelastichayway.com/tutoriels/wow-ecs-fargate-prod/
Post live : N/A (nouveau) · slug wow-ecs-fargate-prod · Publish : HOLD (draft only — feu vert Maître requis)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.