Zum Inhalt springen

AWS ECS on Fargate Architektur-Diagramm: Services, Tasks und Load Balancing

Ein produktiver Webservice auf ECS mit Fargate, gezeichnet und erklärt: Task-Netzwerk, ALB, IAM-Rollen, Secrets, Auto Scaling, Fargate Spot und Deployments.

· Gründer & Entwickler

Veröffentlicht am

Eine VPC über zwei Availability Zones. Nutzer erreichen einen Application Load Balancer zwischen den öffentlichen Subnetzen, der je einen Fargate-Task im privaten Subnetz bedient. Die Tasks fragen Multi-AZ-RDS ab; ECR, Secrets Manager und Logs laufen über VPC-Endpoints.

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). AmazonECSTaskExecutionRolePolicy deckt ECR und Logs ab; füge secretsmanager:GetSecretValue selbst hinzu, und kms:Decrypt fü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

Eine VPC über zwei Availability Zones. Nutzer erreichen einen Application Load Balancer zwischen den öffentlichen Subnetzen, der je einen Fargate-Task im privaten Subnetz bedient. Die Tasks fragen Multi-AZ-RDS ab; ECR, Secrets Manager und Logs laufen über VPC-Endpoints.

22 Komponenten · 10 Verbindungen

In Archboard öffnen
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
Ein ECS-Service auf Fargate über zwei Availability Zones. Der ALB in den öffentlichen Subnetzen leitet an Task-IPs in privaten Subnetzen weiter; die Tasks erreichen ECR, Secrets Manager und CloudWatch Logs über VPC-Endpoints, nicht über das Internet.

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

  1. Melde dich mit Google oder GitHub an und erstelle ein Diagramm.
  2. Füge aus dem Paket Netzwerk eine VPC hinzu und darin vier Subnetz-Nodes, je ein öffentliches und ein privates pro AZ.
  3. 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.
  4. Füge aus dem Paket Cloud in jedes private Subnetz eine Recheninstanz ein, mit der Task-Größe im Feld für den Instanztyp.
  5. 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.
  6. 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.
  7. 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.

Kostenlos starten — ein Seat, keine Kreditkarte.

Ähnliche Beiträge

← Zurück zum Blog

In einer Minute ein Canvas öffnen

Melden Sie sich mit Google oder GitHub an. Kostenlos für einen Sitzplatz. Upgraden Sie, wenn das Team dazukommt.