Du pushst das Image, legst den Service an, und die ersten Tasks erreichen nie RUNNING. Sie stoppen mit einem ResourceInitializationError: unable to pull secrets or registry auth. Am Image liegt es nicht. Die Tasks laufen in privaten Subnetzen ohne Route zu Amazon ECR oder Secrets Manager, deshalb kann Fargate sie nicht starten.
Viele Probleme mit ECS on Fargate sehen so aus: Die Container funktionieren, aber das Netzwerk, die Rollen oder die Load-Balancer-Einstellungen drumherum nicht. Dieser Beitrag beschreibt einen produktiven Webservice auf Amazon ECS mit AWS Fargate, von Netzwerk und Load Balancing über IAM, Scaling und Deployments bis zu ECS vs. EKS, mit einem Diagramm zum Kopieren.
ECS-Konzepte in einer Tabelle
| Konzept | Was es ist | Im Beispiel |
|---|---|---|
| Cluster | Eine logische Gruppe aus Services und Tasks | prod |
| Task Definition | Versionierte Vorlage: Image, CPU, Speicher, Ports, Rollen, Secrets, Logging | orders-api:42 |
| Task | Eine laufende Kopie einer Task Definition; auf Fargate hat sie einen eigenen Kernel, eigenen Speicher und ein eigenes Netzwerk-Interface | 2 bis 10 Kopien |
| Service | Hält die gewünschte Task-Anzahl, registriert Tasks beim Load Balancer, führt Deployments aus | orders-api |
| Capacity Provider | Wo Tasks laufen: FARGATE, FARGATE_SPOT, EC2-Auto-Scaling-Gruppen oder ECS Managed Instances |
FARGATE und FARGATE_SPOT |
Der Cluster ist keine Netzwerkgrenze: Tasks laufen in den Subnetzen, die du angibst, hinter ihren eigenen Security Groups. ECS berechnet nichts für die Orchestrierung; Fargate rechnet vCPU, Speicher und Storage jedes Tasks sekundengenau ab, mit einer Mindestdauer von einer Minute.
Netzwerk: ein ENI pro Task
Fargate-Tasks nutzen immer den Netzwerkmodus awsvpc: Jeder Task bekommt ein eigenes Elastic Network Interface (ENI), eine private IP aus seinem Subnetz und eigene Security Groups (Fargate-Task-Netzwerk). Daraus folgen drei Dinge:
- Subnetze brauchen Platz. Jeder Task belegt eine IP, und AWS reserviert fünf pro Subnetz. Sechzig Tasks auf zwei AZs bedeuten 30 pro Subnetz, und ein Rolling Deployment mit 200 % braucht kurzzeitig 60. Ein /24 (251 nutzbar) reicht; ein /27 (27 nutzbar) nicht.
- Security Groups gelten pro Task. Öffne den Container-Port nur für die Gruppe des Load Balancers und Port 5432 der Datenbank nur für die Gruppe der Tasks.
- Tasks brauchen einen Weg zu den AWS-APIs. Bevor dein Code läuft, zieht Fargate das Image, holt Secrets und beginnt, Logs über das ENI des Tasks zu senden.
Aus einem privaten Subnetz ist dieser Weg ein NAT Gateway oder VPC-Endpoints (US-East-Preise zum Zeitpunkt des Schreibens, November 2026):
| Weg | Du erstellst | Kosten | Kompromiss |
|---|---|---|---|
| NAT Gateway | Eines pro AZ oder ein regionales NAT Gateway | 0,045 USD pro AZ-Stunde plus 0,045 USD pro GB | Erreicht auch APIs von Drittanbietern |
| VPC-Endpoints | Interface-Endpoints ecr.api, ecr.dkr, logs, secretsmanager, dazu den S3-Gateway-Endpoint |
0,01 USD pro Endpoint und AZ-Stunde plus 0,01 USD pro GB; der S3-Gateway ist kostenlos | Gar kein Weg ins Internet |
Lass den S3-Gateway-Endpoint nicht weg: ECR speichert Image-Layer in S3 (ECR-Interface-Endpoints). Vier Interface-Endpoints in zwei AZs kosten vor den Datengebühren etwa 58 USD im Monat (8 × 0,01 USD × 730 Stunden), fast so viel wie zwei NAT Gateways für 66 USD. Endpoints gewinnen also bei Datenkosten und Privatsphäre, NAT bei der Reichweite. Seit November 2025 erstreckt sich ein regionales NAT Gateway selbst über mehrere AZs und braucht kein öffentliches Subnetz. Öffentliche IPs an Tasks funktionieren ebenfalls, lassen aber jeden Task nur eine Security-Group-Regel vom Internet entfernt. Das AWS-VPC-Diagramm behandelt Routen und die Platzierung von NAT.
Der Load Balancer: Target Groups und Health Checks
Der ALB braucht Subnetze in mindestens zwei AZs, jedes ein /27 oder größer mit acht freien Adressen. Weil ein awsvpc-Task ein ENI ist und keine EC2-Instanz, muss der Typ der Target Group ip sein. Nutze eine Target Group pro Service; ECS registriert und deregistriert die Tasks.
| Einstellung | Standard | Erwäge |
|---|---|---|
| Health-Check-Intervall | 30 s | 5 s, wenn der Service in unter 10 s startet (Empfehlung von AWS) |
| Unhealthy Threshold | 2 Checks | Ein fehlerhafter Task ist nach etwa einer Minute raus |
| Healthy Threshold | 5 Checks | Neue Targets brauchen nur einen bestandenen Check |
| Deregistration Delay | 300 s | 30 s oder weniger bei kurzen Requests; alte Tasks können so lange drainen |
healthCheckGracePeriodSeconds |
0 | Decke die Startzeit ab, sonst werden langsam startende Tasks in einer Schleife ersetzt |
Seit November 2025 kann ECS Express Mode dieses ALB-, HTTPS- und Scaling-Setup aus einem Container-Image erzeugen. Das Load-Balancer-Diagramm behandelt Health Checks und Draining allgemein.
IAM: die Execution Role und die Task Role
Zwei Rollen, zwei Aufgaben:
- Die Task Execution Role wird von ECS und dem Fargate-Agent genutzt, nicht von deinem Code: Sie zieht das Image, schreibt Logs und liest die in der Task Definition genannten Secrets (Task Execution Role).
AmazonECSTaskExecutionRolePolicydeckt ECR und Logs ab; fügesecretsmanager:GetSecretValueselbst hinzu, undkms:Decryptfür einen kundenverwalteten Schlüssel. - Die Task Role nutzt dein Code über das AWS SDK, etwa für S3 oder SQS, und sie braucht ECS Exec.
Secrets kommen als Umgebungsvariablen an:
"secrets": [{
"name": "DB_PASSWORD",
"valueFrom": "arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/orders/db-AbCdEf:password::"
}]
ECS liest den Wert, wenn der Container startet. Ein rotiertes Secret erreicht laufende Tasks nicht, also deploye nach der Rotation neu oder lass die App das Secret mit ihrer Task Role selbst lesen. Einen einzelnen JSON-Key wie oben auszuwählen, setzt Platform Version 1.4.0 voraus, die aktuelle LATEST.
Scaling: Target Tracking und Fargate Spot
Beginne für Service Auto Scaling mit Target Tracking auf ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization oder ALBRequestCountPerTarget. Es skaliert schnell hoch, langsam herunter und pausiert das Herunterskalieren während Deployments; bei mehreren Policies skaliert es nur herunter, wenn alle zustimmen. Halte mindestens einen Task pro AZ.
Fargate Spot kostet bis zu 70 % weniger. Wenn AWS die Kapazität zurückholt, bekommt der Task eine Zwei-Minuten-Warnung, als EventBridge-Event mit dem Stop Code SpotInterruption und als SIGTERM (Fargate Capacity Providers). stopTimeout ist auf 120 Sekunden begrenzt, und Fargate weicht nie von selbst auf reguläre Kapazität aus, also halte eine Basis:
"capacityProviderStrategy": [
{ "capacityProvider": "FARGATE", "base": 2, "weight": 1 },
{ "capacityProvider": "FARGATE_SPOT", "weight": 1 }
]
Die ersten zwei Tasks laufen immer auf regulärem Fargate; der Rest teilt sich eins zu eins auf. Ein Service mit einem einzigen Task auf Spot steht einfach, bis wieder Kapazität da ist.
Deployments: Rolling, Blue/Green, Linear und Canary
Rolling ist der Standard: Mit minimumHealthyPercent 100 und maximumPercent 200 startet ECS neue Tasks, bevor es alte stoppt. Aktiviere den Deployment Circuit Breaker mit Rollback; standardmäßig lässt er ein Deployment fehlschlagen, sobald die fehlgeschlagenen Tasks die Hälfte der gewünschten Anzahl erreichen (mindestens 3, höchstens 200). CloudWatch-Alarme können denselben Rollback auslösen.
Seit Juli 2025 führt ECS Blue/Green-Deployments selbst aus, ohne CodeDeploy, und seit Oktober 2025 auch Linear und Canary. Sie starten die neue Revision hinter einer zweiten Target Group, verschieben den Listener-Traffic und behalten die alten Tasks für eine Bake Time, sodass der Rollback ein Traffic-Wechsel ist.
| Strategie | Traffic-Verschiebung | Rollback | Zusätzliche Kapazität |
|---|---|---|---|
| Rolling | Tasks werden in Batches ersetzt | Neu deployen | Bis maximumPercent |
| Blue/Green | Alles auf einmal, nach optionalem Test-Traffic | Zurückschalten | 2x |
| Linear | Gleiche Schritte, etwa 10 % alle paar Minuten | Zurückschalten | 2x |
| Canary | Ein kleiner Anteil, dann der Rest | Zurückschalten | 2x |
Lambda- oder Pause-Hooks können jede Stufe absichern. Target Tracking auf ALBRequestCountPerTarget wird mit Blue/Green nicht unterstützt. Das Deployment-Strategien-Diagramm vergleicht die Muster.
Observability
Der awslogs-Treiber braucht awslogs-group, awslogs-region und auf Fargate awslogs-stream-prefix. Seit dem 25. Juni 2025 steht er standardmäßig im Modus non-blocking mit einem 10-MB-Puffer: Ein CloudWatch-Aussetzer friert deine App nicht mehr ein, aber ein voller Puffer verliert Zeilen. Ergänze Container Insights mit Enhanced Observability, ECS Exec für Shells und eine EventBridge-Regel auf Task-Statusänderungen; der Stopped Reason sagt, warum ein Task gestorben ist. Für Traces lässt du einen OpenTelemetry Collector als Sidecar im Task laufen; er bildet die Agent-Stufe einer Pipeline für Logs, Metriken und Traces mit OpenTelemetry.
ECS vs. EKS
| Amazon ECS | Amazon EKS | |
|---|---|---|
| Control Plane | Kostenlos | 0,10 USD pro Cluster-Stunde, etwa 73 USD im Monat |
| API | AWS-Task-Definitions und -Services | Kubernetes, Helm, Operatoren |
| Compute | Fargate, EC2, ECS Managed Instances | Fargate, EC2-Node-Groups, EKS Auto Mode |
| Upgrades | Keine für die Control Plane | 14 Monate Standard Support pro Kubernetes-Version, danach 0,60 USD pro Cluster-Stunde |
| Eingebaute Deployments | Rolling, Blue/Green, Linear, Canary | Rolling; andere über Tools wie Argo Rollouts |
Die Preise stammen von der EKS-Preisseite zum Zeitpunkt des Schreibens (November 2026). Wähle EKS, wenn du Kubernetes-Portabilität oder sein Ökosystem brauchst; das Kubernetes-Architekturdiagramm zeigt dieses Bild. Für kurze, ereignisgesteuerte Aufgaben brauchen Lambda-basierte Serverless-Designs gar keinen dauerhaft laufenden Service.
Das ECS-on-Fargate-Diagramm
Diagramminhalt
- VPC
- Public subnet · AZ a
- Public subnet · AZ b
- Private subnet · AZ a
- Private subnet · AZ b
- Application Load Balancer
- orders-api task
- RDS for PostgreSQL
- VPC endpoints
- Users
- Amazon ECR
- Secrets Manager
- CloudWatch Logs
- HTTPS 443
- HTTP 8080
- SQL 5432
- image pull
- secrets at start
- awslogs
So liest du es:
- AZs sind Zeilen. Jede hat ein öffentliches und ein privates Subnetz. Der ALB, RDS und die Endpoints liegen zwischen den Zeilen, weil jeder beide AZs abdeckt: ein ALB-Node in jedem öffentlichen Subnetz, ein Multi-AZ-Standby für die Datenbank.
- Durchgezogenes Blau ist der Request-Pfad: HTTPS zum ALB, HTTP 8080 zu einem Task pro AZ, SQL auf Port 5432.
- Gestricheltes Lila ist Plattform-Traffic: der Image-Pull, Secrets und Logs, von Fargate mit der Task Execution Role über die VPC-Endpoints gesendet.
- Nur die öffentlichen Subnetze routen 0.0.0.0/0 zum Internet Gateway.
- Der Markdown-Block listet die Service-Einstellungen auf.
ECS-Diagramme klar zeichnen
- Setze Tasks in Subnetze pro AZ. Eine Box «ECS-Cluster» um alles versteckt, wo Tasks laufen und was sie erreichen können.
- Zeichne einen Task pro AZ, mit dem Scaling-Bereich daneben.
- Zeige den Weg zu ECR, Secrets Manager und CloudWatch Logs. Ein fehlender Weg ist ein häufiger Grund, warum Tasks nicht starten.
- Beschrifte die ALB-Kante mit Port und Target-Typ, und nenne die Rolle hinter den gestrichelten Kanten in einer Legende.
- Lass weg: Sidecars, CI/CD und DNS-Einträge, sofern das Diagramm nicht von ihnen handelt.
Die AWS-Drei-Schichten-Architekturvorlage hat dasselbe VPC-Layout mit EC2.
In Archboard nachbauen
- Melde dich mit Google oder GitHub an und erstelle ein Diagramm.
- Füge aus dem Paket Netzwerk eine VPC hinzu und darin vier Subnetz-Nodes, je ein öffentliches und ein privates pro AZ.
- Füge aus dem Paket Cloud einen Cloud-Lastverteiler zwischen den öffentlichen Subnetzen hinzu und Text-Notizen in den öffentlichen Subnetzen für die Route und den ALB-Node.
- Füge aus dem Paket Cloud in jedes private Subnetz eine Recheninstanz ein, mit der Task-Größe im Feld für den Instanztyp.
- Füge zwischen den privaten Subnetzen eine Verwaltete Datenbank mit aktivierter Hochverfügbarkeit und eine Cloud-Ressource für die VPC-Endpoints hinzu, beide aus dem Paket Cloud.
- Füge außerhalb der VPC Internet aus dem Paket Netzwerk, Container-Registry aus dem Paket Docker, Tresor aus dem Paket Sicherheit und Protokolle aus dem Paket DevOps hinzu.
- Zeichne beschriftete Kanten, gestrichelt für Plattform-Traffic, und füge einen Markdown-Block aus dem Paket Basis mit den Einstellungen hinzu.
Die Tools CloudFormation zu Diagramm und Terraform zu Diagramm machen aus vorhandenem Stack-Code einen ersten Entwurf; wenn du den Service aus Terraform zeichnest, kürze den Entwurf und ergänze den Request-Pfad von Hand.
Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan.
FAQ
Verlangt Fargate den Netzwerkmodus awsvpc?
Ja. Jeder Fargate-Task bekommt ein eigenes Netzwerk-Interface und eine private IP-Adresse, weshalb seine Target Groups den Target-Typ ip nutzen müssen.
Was ist der Unterschied zwischen der ECS Task Role und der Task Execution Role? Die Execution Role lässt ECS den Task starten: Image ziehen, Secrets holen, Logs senden. Die Task Role nutzt dein Anwendungscode für seine eigenen AWS-Aufrufe.
Brauchen Fargate-Tasks in privaten Subnetzen ein NAT Gateway? Nicht für AWS-Services. Interface-Endpoints für ECR, CloudWatch Logs und Secrets Manager plus der S3-Gateway-Endpoint genügen. NAT brauchst du nur, um das Internet zu erreichen.
Unterstützt ECS Blue/Green-Deployments ohne CodeDeploy? Ja. ECS führt Blue/Green seit Juli 2025 nativ aus, Linear und Canary seit Oktober 2025, mit Bake Times, Lifecycle Hooks und alarmbasiertem Rollback.
Ist ECS günstiger als EKS? Bei der Control Plane ja: ECS hat keine Orchestrierungsgebühr, ein EKS-Cluster kostet dagegen 0,10 USD pro Stunde im Standard Support. Die Preise für Fargate und EC2-Instanzen sind bei beiden gleich.