Stell dir vor: “Wir nehmen Kubernetes.” Die Frage: womit deployen wir unseren neuen Service? Drei Endpoints, 200 req/s, ein Cronjob. Das Team: 4 Entwickler, keiner hat K8s-Erfahrung. Sechs Wochen später: Helm Charts, Ingress Controller, Cluster Autoscaler, Karpenter, ArgoCD. Der Service selbst hat 800 Zeilen Code. Die Infra drumherum: 3.000.
Das AWS-Whitepaper “Microservices on AWS” zeigt alle vier Compute-Optionen. Was es nicht zeigt: den Ops-Overhead.
Klick durch die Optionen und schau dir die Score-Verteilung an besonders “Setup” vs “Cost @ High”:
Lambda bei Setup: 95%. EKS bei Setup: 15%. Das ist kein kleiner Unterschied. Das sind Wochen vs Minuten.
Lambda: wenn du keinen Server willst
Lambda ist genial für alles was sporadisch läuft. API-Endpoint der 50x am Tag aufgerufen wird? Lambda kostet dich nichts. Event Processing aus SQS? Lambda skaliert auf 1000 gleichzeitige Executions ohne dass du was tust.
Der Break-Even kommt bei ~500k Requests pro Tag. Ab da wird Lambda teurer als ein Container der 24/7 läuft. Und Cold Starts 100-500ms für Node.js, 1-3 Sekunden für Java machen Lambda für Latenz-kritische APIs unbrauchbar.
export const handler = async (event: APIGatewayEvent) => {
const order = JSON.parse(event.body!);
await processOrder(order);
return { statusCode: 200, body: "OK" };
};Das ist dein gesamter Deployment-Artifact. Kein Dockerfile. Kein Helm Chart. Kein Cluster. Zip, Upload, fertig.
Provisioned Concurrency löst Cold Starts für $15-30/mo pro Instanz. Für eine API mit konsistentem Traffic sinnvoll. Für sporadische Workloads: Geldverschwendung.
Fargate: Container ohne Server
Fargate ist der Kompromiss. Du schreibst ein Dockerfile, definierst CPU/Memory, und AWS managed den Rest. Kein Cluster, keine Nodes, kein OS-Patching.
Gut wenn dein Team Docker kann aber kein K8s will. Weniger gut wenn du Spot Instances brauchst (Fargate Spot gibt’s, aber mit Einschränkungen) oder Host-Level Networking.
containerDefinitions:
- name: api
image: 123456789.dkr.ecr.eu-west-1.amazonaws.com/api:latest
cpu: 256 # 0.25 vCPU
memory: 512 # 512 MB
portMappings:
- containerPort: 8080Scaling dauert 30-60 Sekunden für neue Tasks. Für stabile APIs kein Problem. Für spiky Traffic (0 auf 100 Requests in einer Sekunde) zu langsam; da ist Lambda besser.
ECS auf EC2: wenn Kosten zählen
ECS auf EC2 ist der billigste Container-Compute auf AWS. Du managst die EC2 Instances selbst, ECS platziert Container drauf. Capacity Provider + Auto Scaling Group handelt die Skalierung.
Der Trade-off: du bist für OS-Patches, Security Updates und Instance-Gesundheit verantwortlich. Das ist Ops-Arbeit. Aber dafür bekommst du Spot Instances (60-80% Rabatt) und Reserved Capacity.
Stell dir vor: ein Team wechselt von Fargate auf ECS/EC2 mit Spot. Compute-Kosten: von $4.200 auf $1.100 pro Monat. Gleiche Workload. Der Preis: ein Ops-Engineer der sich um die Instances kümmert. Je nach Team rechnet sich das.
EKS: wenn du Kubernetes wirklich brauchst
EKS macht Sinn wenn:
- Du 10+ Services hast und ein einheitliches Deployment-Modell brauchst
- Dein Team K8s-Erfahrung hat (nicht “will lernen” hat)
- Du Hybrid oder Multi-Cloud brauchst
- Du Features wie Service Mesh, Custom Operators, oder CRDs brauchst
EKS macht keinen Sinn wenn:
- Du weniger als 5 Services hast
- Dein Team kleiner als 8 Leute ist
- Du “Microservices ausprobieren” willst
Die $73/Monat für die Control Plane sind das geringste Problem. Das Problem sind die 2-4 Wochen Setup, die permanente Maintenance, und die Tatsache dass jedes K8s-Update ein Projekt ist.
Also was nehm ich?
Sporadisch, Event-Driven, unter 15min Runtime? Lambda. Stabile API, Team kann Docker, will kein K8s? Fargate. Hoher Traffic, Kosten kritisch, Ops-Team vorhanden? ECS/EC2 mit Spot. 10+ Services, K8s-Erfahrung, Platform Team? EKS. Unsicher? Fargate. Du kannst jederzeit auf ECS/EC2 oder EKS migrieren.
Das Whitepaper empfiehlt Container für alles. Drei Endpoints und 200 req/s brauchen kein Kubernetes. Die brauchen eine Lambda oder einen Fargate Task.