AWS ECS vs. EKS: Container-Orchestrierung im Vergleich

Im Mittelstand fällt die Container-Orchestrierungs-Entscheidung oft auf einer LinkedIn-Pause oder in der Mittagspause auf einer Konferenz. Der Berater sagt Kubernetes, der AWS-Account-Manager sagt ECS, und am Ende landet das Setup in dem, was das Team gerade kennt. Das funktioniert manchmal, häufig nicht.

Container sind seit zehn Jahren etabliert, aber zwischen re:Invent 2024 und re:Invent 2025 hat AWS das Spielfeld signifikant verändert. EKS Auto Mode, ECS Managed Instances und das App-Mesh-EOL bedeuten: Wer seine Container-Strategie 2024 festgelegt hat, sollte sie 2026 neu prüfen. Dieser Artikel ist eine Trade-off-Analyse auf Basis verifizierter Pricing-Daten und konkreter Architektur-Szenarien, mit Stand Mai 2026 und Pricing-Werten aus us-east-1.

Was er nicht ist: eine Hello-World-Einführung in Kubernetes oder ECS. Wer noch nie ein Cluster aufgesetzt hat, beginnt mit den offiziellen Tutorials. Was er ist: die Grundlage für eine bewusste Entscheidung zwischen ECS und EKS, die nicht in der Mittagspause fällt.

Was ECS ist und was es nicht ist

Amazon Elastic Container Service ist AWS-eigener Orchestrator, kein Kubernetes. Die Kern-Konzepte sind:

• Cluster: logischer Container für Tasks und Services
• Task Definition: JSON-Beschreibung eines Containers oder einer Container-Gruppe (analog zu Kubernetes Pod-Spec, aber AWS-spezifisch)
• Service: hält N Tasks am Laufen, mit Load Balancer, Auto-Scaling, Deployment-Strategien
• Capacity Provider: regelt, ob Tasks auf Fargate, ECS Managed Instances oder self-managed EC2 laufen

Was ECS gut macht: Tiefe AWS-Integration mit IAM, CloudWatch, ALB, Secrets Manager und ECR ist vorgedacht. Es gibt keine Control-Plane-Gebühr. Service Connect (seit November 2022) liefert Service-zu-Service-Kommunikation mit AWS-managed Envoy-Sidecar. Drei Capacity Provider stehen zur Wahl. Mit den Updates auf re:Invent 2025 sind Blue/Green, Canary und Linear Deployments mit automatischem Rollback bei CloudWatch-Alarmen aus dem Karton verfügbar, ohne externe Tools.

Was ECS nicht macht: Kein Helm, keine Custom Resource Definitions, keine Operators. Kein Standard-Ökosystem für Service Mesh seit App Mesh EOL am 30. September 2026. Keine Portabilität jenseits AWS. Eine einfache Task Definition für eine Laravel-App auf Fargate sieht so aus:

{
  "family": "laravel-web",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/laravel-task-role",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789012.dkr.ecr.eu-central-1.amazonaws.com/laravel-web:1.2.3",
      "essential": true,
      "portMappings": [
        { "name": "http", "containerPort": 9000, "protocol": "tcp" }
      ],
      "environment": [
        { "name": "APP_ENV", "value": "production" }
      ],
      "secrets": [
        { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:eu-central-1:123456789012:secret:laravel/db-AbCdEf" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/laravel-web",
          "awslogs-region": "eu-central-1",
          "awslogs-stream-prefix": "web"
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:9000/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 10
      }
    }
  ]
}

Was EKS ist und was es nicht ist

Amazon Elastic Kubernetes Service ist managed Kubernetes-Control-Plane. AWS managt die Control Plane in mehreren Availability Zones, liefert Kubernetes-Versions-Upgrades und Patches für etcd und integriert IAM via IRSA (IAM Roles for Service Accounts) oder das neuere EKS Pod Identity. VPC CNI als Default-Netzwerk-Plugin gibt Pods VPC-IPs aus dem CIDR-Block.

Was du selbst machst (ohne Auto Mode): Worker-Nodes über EC2-Auto-Scaling-Gruppen oder Karpenter verwalten, Add-ons konfigurieren (VPC CNI, kube-proxy, CoreDNS, EBS CSI Driver, EFS CSI Driver), Helm/Argo/Flux/Kustomize für Deployments, Service Mesh, Ingress Controller, Cert-Manager, External-DNS und Cluster Autoscaler einrichten. Das ist substantiell mehr Arbeit als ECS.

EKS Auto Mode (re:Invent 2024 mit Erweiterungen 2025) verschiebt diese Grenze. AWS managt jetzt Karpenter, den Load-Balancer-Controller, EBS CSI und GPU-Plugins (NVIDIA Device Plugin, DCGM Exporter). Pre-configured kommen ALB, EBS, NVIDIA-Plugin und SOCI Parallel Pull (laut AWS bis zu 60 Prozent reduzierte Container-Start-Zeiten). Auto Mode ist verfügbar in allen kommerziellen Regionen, GovCloud und Local Zones. Der Preis ist eine Management-Gebühr von rund 10 bis 12 Prozent auf die EC2-Stundenkosten, die nicht durch Savings Plans rabattiert wird.

EKS Hybrid Nodes ergänzen die Architektur um on-premises oder Edge-Hardware, die als Node an einen EKS-Cluster angemeldet wird. Pricing ist gestaffelt von 0,020 USD pro vCPU pro Stunde für die ersten 576.000 vCPU-Stunden pro Monat bis hinunter zu 0,006 USD pro vCPU pro Stunde bei sehr hohem Volumen. Hyperthreading-Cores werden als zwei vCPUs gezählt. Anwendungsfall: Hybrid-Cloud, Datensouveränität, Edge-Workloads.

Karpenter Stand Mai 2026: Der aws/karpenter-provider-aws ist bei v1.9.x, kubernetes-sigs/karpenter bei v1.5.x. Stable APIs gibt es seit v1.0 (August 2024), wichtige Features sind Disruption Controls mit Disruption Budgets, Drift Stability, Termination Grace Period und IMDS-Restriktion für Container per default.

Ein einfaches EKS-Deployment für die gleiche Laravel-App:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: laravel-web
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: laravel-web
  template:
    metadata:
      labels:
        app: laravel-web
    spec:
      serviceAccountName: laravel-web
      containers:
        - name: web
          image: 123456789012.dkr.ecr.eu-central-1.amazonaws.com/laravel-web:1.2.3
          ports:
            - containerPort: 9000
              name: http
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
            limits:
              memory: "1Gi"
          envFrom:
            - secretRef:
                name: laravel-secrets
          readinessProbe:
            httpGet:
              path: /health
              port: 9000
            periodSeconds: 30
            timeoutSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: laravel-web
  namespace: production
spec:
  selector:
    app: laravel-web
  ports:
    - port: 80
      targetPort: 9000

Kubernetes-Versionen und das Pricing-Risiko

Stand Mai 2026 sind drei Kubernetes-Versionen in EKS Standard Support und drei in Extended Support:

Die wichtige Realität für viele Mittelstandscluster: Version 1.32 ist erst seit dem 23. März 2026 in Extended Support, also rund sechs Wochen vor diesem Artikel. Wer sein Cluster nicht aktiv aktualisiert, zahlt seitdem 0,60 USD statt 0,10 USD pro Cluster pro Stunde, also 438 USD statt 73 USD pro Monat. Version 1.30 endet vollständig am 23. Juli 2026, dann erfolgt ein automatisches Upgrade auf die nächste verfügbare Version. Version 1.31 läuft im November 2026 vollständig aus.

Der AWS-Lifecycle ist 14 Monate Standard Support plus 12 Monate Extended Support, also 26 Monate insgesamt pro Version. Drei Versionen sind gleichzeitig in Standard Support. Lesson Learned: Die Sprung-Kosten von Standard auf Extended sind sechsfach. Wer sein Cluster-Inventory nicht regelmäßig prüft, zahlt unbemerkt vier- bis fünfstellige Summen pro Jahr extra.

Die fünf realen Unterschiede

Operations-Overhead

ECS hat minimalen Operations-Overhead. AWS-Konsole oder Terraform reichen, eine produktive Anwendung läuft in wenigen Stunden. EKS klassisch ist signifikant aufwendiger. Ein Team-Member sollte Kubernetes solide können, sonst werden Cluster-Upgrades, Add-on-Verwaltung und Troubleshooting zur Belastung. EKS Auto Mode reduziert das deutlich, aber Kubernetes-Konzepte (Pods, Services, RBAC, NetworkPolicies) bleiben Pflicht.

Realistische Faustregel aus der Praxis: Ein EKS-Cluster ohne Auto Mode kostet ungefähr eine halbe Person-Stelle Operations-Aufwand pro Jahr, mit Auto Mode etwa ein Viertel. Ein ECS-Setup im gleichen Funktionsumfang liegt deutlich darunter, oft bei wenigen Stunden pro Monat.

Pricing-Realität (alle Werte us-east-1)

Die Control-Plane-Kosten:

Fargate-Pricing ist für ECS und EKS identisch:

ECS hat drei Compute-Optionen, die zueinander kombinierbar sind:

Bei EKS Auto Mode kommen pro Instance-Typ unterschiedliche Aufschläge dazu:

Drei Beobachtungen aus der Realität: Auto-Mode-Management-Gebühr ist nicht über Savings Plans rabattierbar, der EC2-Anteil schon. ECS Managed Instances Management-Gebühr ist flat 0,02 USD pro Stunde unabhängig von Instance-Typ, was bei großen Instances relativ günstiger ist als Auto Mode, bei kleinen umgekehrt. Region-Unterschiede gelten: eu-central-1 liegt typischerweise rund 5 bis 15 Prozent über us-east-1, aktuelle Werte vor jedem Setup beim AWS Pricing Calculator nachschlagen.

Konkretes Drei-Cluster-Szenario in us-east-1, alles Standard Support: Drei EKS-Cluster mit jeweils zehn Fargate-Tasks (0,5 vCPU plus 1 GB), 24 Stunden pro Tag, 730 Stunden pro Monat. Pro Task: 0,5 mal 0,04048 mal 730 plus 1 mal 0,004445 mal 730, also 14,78 USD plus 3,24 USD, insgesamt 18,02 USD pro Monat. Dreißig Tasks ergeben rund 541 USD pro Monat. Drei Cluster Control Plane: 3 mal 73 USD = 219 USD pro Monat. Gesamt EKS: rund 760 USD. Gleicher Setup auf ECS spart die 219 USD Control-Plane-Gebühr.

Wann der Pricing-Unterschied egal wird: Sobald die Compute-Kosten die Control Plane überproportional übersteigen. Bei einem produktiven Cluster mit 50 vCPU-Stunden pro Tag liegt EKS Control Plane bei unter 4 Prozent der Gesamtkosten. Bei kleinen Setups mit wenigen Tasks ist die Control Plane das dominierende Argument.

Ökosystem-Hebel

ECS-Ökosystem: ECS Service Connect, Capacity Providers, ECS Exec, ECS Anywhere, Blue/Green/Canary/Linear-Deployments mit automatischem Rollback (re:Invent 2025), MCP-Integration und Amazon Q Developer für ECS. Alles AWS-spezifisch.

EKS-Ökosystem: das gesamte CNCF-Universum. Helm für Paketierung, ArgoCD oder Flux für GitOps, Istio oder Linkerd für Service Mesh (App Mesh ist EOL 30. September 2026), Cert-Manager, External-DNS, Vault, Knative, Custom Resource Definitions und Operators. Karpenter v1.x für sehr feinkörniges Compute-Management, in Auto Mode AWS-managed.

Wann das Ökosystem zählt: Multi-Service-Architekturen mit etablierten Helm-Charts, GitOps-Workflows oder Multi-Cloud-Portabilität. Für eine PHP-App mit drei Services ist das Ökosystem-Argument schwach.

Netzwerk-Modell

Auf Fargate bekommt jeder Task oder Pod eine ENI mit privater IP, einfach. Auf ECS mit EC2 im awsvpc-Mode bekommen Tasks ENIs, die ENI-Quota pro Instance ist eine echte Limitierung. EKS mit VPC CNI gibt jedem Pod eine VPC-IP, Pod-Density ist durch ENI-Quota limitiert. Mit Prefix Delegation deutlich höhere Pod-Dichte pro Node. EKS mit Cilium oder Calico nutzt Pod-IPs aus separatem Netzwerk, mehr Flexibilität, aber zusätzliche Komplexität.

Praktische Konsequenz: VPC-IP-Adressraum sollte bei beiden Diensten von Anfang an großzügig geplant werden. Ein /16-VPC mit /24-Subnetzen wirkt großzügig, ist aber bei aggressiven Pod-Density-Configs schneller knapp als erwartet.

Deployment- und Release-Strategien

ECS unterstützt seit re:Invent 2025 Rolling, Blue/Green, Canary und Linear-Deployments mit automatischem Rollback bei CloudWatch-Alarm-Schwellen, ohne externe Tools. EKS bietet alles, was Kubernetes anbietet, plus Argo Rollouts für Canary und Flagger für progressive Delivery. Realistische Einschätzung: Mit den ECS-Updates 2025 ist die Funktionalität für die meisten Mittelstand-Releases vergleichbar. Argo Rollouts ist genial, wenn man die Komplexität auch nutzt.

Fargate, ECS Managed Instances und EC2 als Compute-Layer

Fargate ist der einfachste Weg. Kein Server-Management, keine Patches, Pricing pro vCPU und GB Memory sekundengenau abgerechnet (1-Minuten-Minimum für Linux, 5-Minuten-Minimum für Windows). 20 GB ephemeral Storage inklusive, max 16 vCPU plus 120 GB Memory pro Task. Begrenzungen: kein DaemonSet auf EKS, kein Privileged Container, keine GPU bei ECS Fargate.

ECS Managed Instances (verfügbar seit 30. September 2025 in sechs Regionen: us-east-1, us-west-2, eu-west-1, af-south-1, ap-southeast-1, ap-northeast-1) sitzen zwischen Fargate und self-managed EC2. Achtung: NICHT in eu-central-1 zum Launch verfügbar, das ist relevant für deutschen Mittelstand mit Frankfurt-Affinität. AWS provisioniert, patcht (alle 14 Tage) und ersetzt Instances automatisch. Volle EC2-Sichtbarkeit und Instance-Typ-Wahl. Erlaubt was Fargate nicht kann: Privileged Container, eBPF-basierte Observability und Security-Agenten, GPU-Workloads und Tasks mit mehr als 120 GB Memory. Pricing: 0,02 USD pro Stunde flat Management-Fee plus reguläre EC2-Kosten, unabhängig vom Instance-Typ. Alle EC2 Purchase Options (On-Demand, Spot, Compute Savings Plans), aber Savings Plans rabattieren NUR den EC2-Anteil.

EC2 Launch Type bietet volle Kontrolle, alle Instance-Typen verfügbar (auch Spot, GPU, Graviton). Karpenter auf EKS oder Capacity Providers auf ECS erledigen Auto-Scaling. Reserved Instances und Savings Plans drücken den Preis um 30 bis 70 Prozent. Patch-Management bleibt beim Team, oder Bottlerocket als minimaler Container-OS reduziert die Angriffsfläche.

Faustregel: Niedriges Volumen, variable Last, kein Operations-Team passt zu Fargate. Privileged Containers, eBPF oder GPU mit AWS-managed Patches und in unterstützter Region passen zu ECS Managed Instances. Hohes Volumen, vorhersagbare Last, Reserved Instances oder spezielle Hardware passen zu EC2 mit eigenem Patch-Management. Hybrid-Setups nutzen Capacity Providers oder Karpenter Mixed-Instance-Pools.

Service-Mesh-Realität nach App-Mesh-EOL

AWS App Mesh wird abgekündigt, EOL ist der 30. September 2026. Wer auf App Mesh setzt, muss migrieren. Die Migrationspfade laut AWS:

• ECS-zu-ECS-Kommunikation: ECS Service Connect (AWS-managed Envoy als Sidecar)
• Cross-Service-Kommunikation (ECS plus EKS plus Lambda plus EC2): VPC Lattice
• EKS-internes Service Mesh: Istio (CNCF-Standard) oder Linkerd

VPC Lattice Pricing in us-east-1: 0,025 USD pro Stunde pro Service, 0,025 USD pro GB Datenverarbeitung, 0,10 USD pro 1 Mio HTTP-Requests, erste 300.000 pro Stunde kostenlos. VPC-Association und Service-Network-Endpoints kostenlos.

Praktische Empfehlung: Wer ECS-only fährt, nutzt Service Connect. Wer EKS plus andere Services hat, prüft VPC Lattice. Istio ist die richtige Antwort, wenn Kubernetes-natives Tracing, Authorization und Traffic Shaping zentral werden. App Mesh in neuen Projekten ist ein Anti-Pattern.

EKS Auto Mode, der Game-Changer für den Mittelstand

Auto Mode automatisiert: Karpenter-basiertes Compute Auto-Scaling mit AWS-managed Karpenter-Pods, den Application Load Balancer Controller, EBS CSI Driver für persistent Volumes, GPU-Support mit NVIDIA Device Plugin und DCGM Exporter, sowie SOCI Parallel Pull für Container-Start-Zeiten.

Auto Mode automatisiert nicht: Kubernetes-Konzepte (Pods, Services, RBAC, NetworkPolicies bleiben Wissen, das Teams brauchen), Application-Level-Operatoren (Cert-Manager, External-DNS bleiben Setup-Arbeit), und Service Mesh (weiterhin Istio oder Linkerd, kein Auto-Mode-Mesh).

Wer profitiert: Mittelständler, die Kubernetes-Vorteile (Helm-Ökosystem, Multi-Cloud-Option) wollen, ohne die volle Operations-Last. Wer nicht profitiert: Wer ECS-Funktionalität sucht, sollte ECS nehmen, nicht EKS Auto Mode. Auto Mode reduziert den Operationsaufwand, aber er macht aus EKS kein ECS.

Migration zwischen ECS und EKS

Container sind portabel, Konfiguration ist es nicht. Das Image bleibt gleich, aber Task Definition (ECS) und Pod-Spec (EKS) sind nicht 1:1 austauschbar. Die IAM-Anbindung unterscheidet sich (Task Role auf ECS vs. IRSA oder Pod Identity auf EKS).

Realistischer Migrationsaufwand für eine Laravel-App mit fünf Services: ECS zu EKS liegt bei vier bis acht Wochen, davon ein Großteil Helm-Charts und CI/CD-Pipeline-Anpassung. EKS zu ECS sind drei bis sechs Wochen, hauptsächlich Vereinfachung von Manifests zu Task Definitions.

Wann Migration sinnvoll ist: Wachstum aus dem ECS-Anwendungsbereich heraus (Multi-Cloud-Anforderung, Kubernetes-Standardisierung) oder Vereinfachung aus überdimensioniertem EKS-Setup. Wann nicht: Migration als Selbstzweck oder weil ein neuer Architekt "modernisieren" will.

Entscheidungs-Framework

Sechs Fragen, die vor der Wahl beantwortet werden sollten:

1. Wie viele Services orchestrieren wir, jetzt und in 24 Monaten?
2. Haben wir Multi-Cloud- oder Hybrid-Anforderungen?
3. Hat das Team Kubernetes-Erfahrung oder ist sie geplant?
4. Brauchen wir spezifische Kubernetes-Features (CRDs, Operators, Helm-Ökosystem)?
5. Wie hoch ist unser Compute-Volumen relativ zur Control-Plane-Gebühr?
6. Wie kritisch ist Time-to-First-Production-Deploy?

Die Empfehlungs-Matrix:

Anti-Patterns

Sieben Muster, die ich in technischen Audits regelmäßig sehe:

Kubernetes für drei Services: hohe Komplexität, niedriger Nutzen. Ein simples ECS-Setup hätte denselben Job mit deutlich weniger Operations-Overhead erledigt.

ECS für Multi-Cloud: ECS ist AWS-only, Multi-Cloud bricht das Mental Model. ECS Anywhere ist eine Insel-Lösung, kein voller Multi-Cloud-Ersatz.

EKS ohne Auto Mode und ohne Plattform-Team: das Team verbringt 30 Prozent seiner Zeit mit Cluster-Wartung statt Features. Mit Auto Mode oder einem Wechsel zu ECS lässt sich der Aufwand drastisch reduzieren.

App Mesh in neuen Projekten: ist EOL 30. September 2026, neue Setups gehen direkt zu Service Connect, VPC Lattice oder Istio.

Selbstgebauter Kubernetes-Cluster auf EC2 (kops, kubeadm): Operations-Albtraum, kaum noch durch reale Anforderungen gerechtfertigt.

Datenbanken im Cluster ohne klare Strategie: stateful Workloads in Kubernetes sind machbar, aber RDS oder Aurora sind im Mittelstand fast immer der bessere Default. Wer PostgreSQL in den Cluster zwingt, übernimmt Backups, Failover und Tuning, die bei einer managed Datenbank kostenlos dabei sind.

EKS Extended Support ignorieren: die 0,60 USD pro Stunde-Gebühr für EOL-Kubernetes-Versionen kann unbemerkt sechsfach höher werden als geplant. Stand Mai 2026 sind 1.30, 1.31 und 1.32 in Extended Support, viele Cluster laufen unbemerkt darauf.

Auto Mode ohne Kubernetes-Know-how anschalten: die Compute-Schicht wird einfacher, aber Pods, Services, RBAC und NetworkPolicies bleiben Pflichtwissen. Wer das nicht hat, scheitert spätestens beim ersten Production-Incident.

Beispiel: Vollständiges Setup für eine Laravel-App

Szenario: Laravel-App mit drei Services (Web, Worker, Scheduler), PostgreSQL als RDS, Redis als ElastiCache, monatliches Compute-Budget rund 500 USD.

Die ECS-Variante mit Fargate als Default und Fargate Spot für Worker-Tasks:

resource "aws_ecs_cluster" "laravel" {
  name = "laravel-production"
 
  setting {
    name  = "containerInsights"
    value = "enabled"
  }
}
 
resource "aws_ecs_cluster_capacity_providers" "laravel" {
  cluster_name = aws_ecs_cluster.laravel.name
 
  capacity_providers = ["FARGATE", "FARGATE_SPOT"]
 
  default_capacity_provider_strategy {
    capacity_provider = "FARGATE"
    weight            = 1
    base              = 1
  }
}
 
resource "aws_ecs_service" "laravel_worker" {
  name            = "laravel-worker"
  cluster         = aws_ecs_cluster.laravel.id
  task_definition = aws_ecs_task_definition.laravel_worker.arn
  desired_count   = 2
 
  capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight            = 4
  }
 
  capacity_provider_strategy {
    capacity_provider = "FARGATE"
    weight            = 1
  }
 
  network_configuration {
    subnets         = var.private_subnet_ids
    security_groups = [aws_security_group.laravel_tasks.id]
  }
}

Die EKS-Variante mit Auto Mode:

# eksctl-cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
 
metadata:
  name: laravel-production
  region: eu-central-1
  version: "1.34"
 
autoModeConfig:
  enabled: true
 
iam:
  withOIDC: true
 
addons:
  - name: aws-ebs-csi-driver
  - name: vpc-cni

Auto Mode managt die Compute-Schicht automatisch, kein Karpenter-Setup nötig. Die Anwendung kommt als Helm-Chart oder direktes Manifest dazu.

Der Kosten-Vergleich für dieses Szenario in us-east-1: ECS Fargate kostet rund 542 USD pro Monat (siehe Beispielrechnung weiter oben). EKS Auto Mode kostet 542 USD plus 73 USD Control Plane plus rund 10 bis 12 Prozent Auto-Mode-Aufschlag, je nach Instance-Mix. Bei vergleichbaren Workloads liegt EKS rund 100 bis 130 USD pro Monat über ECS, hauptsächlich durch die Control-Plane-Gebühr.

Fazit

ECS und EKS sind nicht "besser oder schlechter", sie sind unterschiedliche Werkzeuge für unterschiedliche Anforderungen. Im Mittelstand ist ECS Fargate für die Mehrheit der Workloads die richtige Wahl. Die Operations-Ersparnis und das fehlende Control-Plane-Pricing zahlen sich aus, solange das Kubernetes-Ökosystem nicht tragend ist. Eine Container-Basis mit produktionsreifen PHP-Images ist die Voraussetzung dafür, unabhängig von der Orchestrator-Wahl.

Mit ECS Managed Instances seit September 2025 schließt ECS die wichtigste Lücke zu EKS für Workloads, die Privileged Containers, eBPF oder GPU brauchen. EKS Auto Mode hat die Entscheidungsmatrix seit re:Invent 2024 verschoben. Wer früher EKS aus Operations-Gründen abgelehnt hätte, sollte Auto Mode neu bewerten.

Die endgültige Entscheidung hängt von Team, Workload-Profil und Roadmap ab, nicht vom Buzzword. Pflicht-Hausaufgabe für jeden EKS-Cluster: Version regelmäßig prüfen. Version 1.30 läuft im Juli 2026 vollständig aus, 1.31 im November. Extended Support ist sechsmal teurer als Standard Support, und der Sprung passiert ohne aktive Benachrichtigung.

Sie planen die Container-Orchestrierung neu oder zweifeln am aktuellen Setup? Kontaktieren Sie mich für einen technischen Audit, der Architektur, Pricing und Migrationspfad in zwei bis drei Tagen klärt.