AWS Container Hosting mit ECS, EKS und Fargate richtig wählen

Eine containerisierte Anwendung läuft auf AWS nicht automatisch zuverlässig, günstig oder sicher. Entscheidend ist die Wahl zwischen Amazon ECS, Amazon EKS, AWS Fargate und den passenden Bausteinen für Netzwerk, Deployment und Monitoring. Ich zeige, welche Architektur für typische Hosting- und DevOps-Szenarien sinnvoll ist, wie sich die Dienste unterscheiden und welche Kosten- und Betriebsfallen häufig übersehen werden.

Was Container auf AWS in der Praxis leisten

Ein Container verpackt eine Anwendung zusammen mit ihren Abhängigkeiten in ein reproduzierbares Laufzeitpaket. Dadurch läuft derselbe Build lokal, in der Testumgebung und in der Produktion deutlich konsistenter. Für Teams bedeutet das weniger Überraschungen beim Deployment und eine bessere Grundlage für automatisierte Releases.

Auf AWS besteht eine typische Container-Architektur aus mehreren Teilen. Amazon ECR speichert das Image, Amazon ECS oder EKS orchestriert die Ausführung und Fargate oder EC2 stellt die Rechenleistung bereit. Ein Application Load Balancer verteilt den Datenverkehr, während CloudWatch Logs und Metriken für Transparenz sorgen.

Ich würde Container deshalb nicht als einzelnen AWS-Dienst betrachten. Es handelt sich eher um ein Zusammenspiel aus Image-Registry, Orchestrierung, Netzwerk, Identitäten, Secrets und Monitoring. Wer nur den Container startet und diese Umgebung ignoriert, bekommt häufig eine Anwendung, die zwar funktioniert, aber schwer zu betreiben ist.

Die grundlegenden Bausteine

• Amazon ECR verwaltet private Container-Images und Versionen.
• Amazon ECS steuert Tasks und Services ohne Kubernetes-Komplexität.
• Amazon EKS bietet eine verwaltete Kubernetes-Kontrollebene.
• AWS Fargate führt Tasks aus, ohne dass eigene Server gepflegt werden müssen.
• Amazon EC2 bietet maximale Kontrolle über Instanzen, Betriebssystem und Auslastung.
• IAM, VPC, Secrets Manager und CloudWatch bilden die Sicherheits- und Betriebsgrundlage.

ECS, EKS oder ECS Express Mode

Die wichtigste Architekturentscheidung betrifft die Orchestrierung. Für die meisten klassischen Webanwendungen, APIs und überschaubaren Microservices ist Amazon ECS der einfachere Weg. EKS bringt die Portabilität und das Ökosystem von Kubernetes, verlangt dafür aber mehr Know-how im täglichen Betrieb.

Meine Faustregel ist einfach. ECS passt zu einer AWS-zentrierten Plattform, bei der das Team möglichst schnell produktiv werden möchte. EKS ist dann sinnvoll, wenn Kubernetes bereits strategisch gesetzt ist, mehrere Cluster betrieben werden oder vorhandene Tools und Kompetenzen diesen Aufwand rechtfertigen.

Ein häufiger Fehler besteht darin, EKS nur deshalb auszuwählen, weil Kubernetes modern oder flexibel klingt. Ein kleiner Onlineshop mit drei Services braucht in der Regel keine Kubernetes-Plattform. Die zusätzliche Komplexität zeigt sich später bei Upgrades, Netzwerkregeln, Ingress-Konfiguration, Observability und Fehleranalyse.

Fargate, EC2 und Managed Instances richtig einordnen

Nach der Orchestrierung folgt die Frage, wo die Container laufen. Fargate ist serverlos im praktischen Sinn. AWS verwaltet die zugrunde liegenden Server, während das Team CPU, Arbeitsspeicher, Netzwerk und Container-Konfiguration festlegt.

Bei ECS auf EC2 verwaltet das Team dagegen die Instanzen selbst. Das bietet mehr Kontrolle und kann bei dauerhaft hoher Auslastung günstiger sein. Dafür müssen Betriebssystem-Updates, Kapazitätsplanung, Skalierung, Patching und die Verteilung der Tasks zuverlässig automatisiert werden.

Die neueren ECS Managed Instances liegen zwischen diesen Modellen. AWS übernimmt wesentliche Aufgaben wie Provisionierung, Patching und Skalierung der zugrunde liegenden EC2-Kapazität. Das kann interessant sein, wenn Fargate zu wenig Kontrolle bietet, der klassische EC2-Betrieb aber zu viel Arbeit verursacht.

Fargate rechnet die angeforderten Ressourcen grundsätzlich pro Sekunde ab, bei Linux-Tasks mit einer Mindestdauer von einer Minute. Für jeden Task sind 20 GB temporärer Speicher standardmäßig enthalten. Zusätzliche Kosten entstehen unter anderem für Load Balancer, NAT Gateway, CloudWatch, Datenübertragung und öffentliche IPv4-Adressen.

Ein dauerhaft laufender Service mit zwei Tasks und jeweils 0,5 vCPU sowie 1 GB Arbeitsspeicher verursacht daher nicht nur Kosten für die Rechenleistung. Die Tasks laufen bei 730 Betriebsstunden pro Monat, hinzu kommen Netzwerk- und Betriebsdienste. Für eine realistische Kalkulation sollte ich immer Region, Architektur, Traffic, Logvolumen und Mindestanzahl der Tasks in den AWS Pricing Calculator eintragen.

Für unterbrechungstolerante Jobs kann Fargate Spot die Rechnung deutlich reduzieren. Diese Tasks können jedoch mit kurzer Vorwarnung beendet werden und eignen sich deshalb eher für Batch-Verarbeitung, Datenaufbereitung oder CI/CD als für eine kritische Webanwendung.

So sieht ein belastbarer DevOps-Weg aus

Eine gute Container-Plattform beginnt nicht mit einem manuellen Klick in der AWS-Konsole, sondern mit einem reproduzierbaren Ablauf. Ich würde die Bereitstellung in sechs klaren Schritten aufbauen:

1. Image bauen und Unit-, Integrations- sowie Sicherheitstests ausführen.
2. Image prüfen, unter anderem auf bekannte Schwachstellen und unnötige Pakete.
3. Image nach ECR pushen und unveränderliche Tags oder Image-Digests verwenden.
4. Infrastruktur als Code mit AWS CDK, CloudFormation oder Terraform verwalten.
5. Service ausrollen und Health Checks, Deployment Circuit Breaker oder Blue-Green-Deployment nutzen.
6. Metriken und Logs auswerten und bei Problemen automatisiert oder kontrolliert zurückrollen.

Besonders wichtig ist die Trennung zwischen Anwendung und Konfiguration. Datenbankpasswörter gehören nicht in das Dockerfile und nicht in das Image. Secrets Manager oder Systems Manager Parameter Store sind dafür die bessere Lösung, weil Zugriffe über IAM geregelt und Werte getrennt vom Build verwaltet werden können.

Lesen Sie auch: AWS Lambda erklärt - Serverless Hosting richtig einsetzen

Ein sinnvoller Produktionsaufbau

Für eine typische deutsche Webanwendung würde ich den Load Balancer in öffentlichen Subnetzen betreiben und die ECS-Tasks in privaten Subnetzen über mindestens zwei Availability Zones verteilen. Datenbanken, Caches und interne Dienste bleiben ebenfalls privat. Dadurch ist die Angriffsfläche kleiner und ein Ausfall einzelner Infrastrukturkomponenten besser abzufangen.

Die Anwendung sollte einen Readiness- und einen Liveness-Check besitzen. Der erste zeigt, ob ein Container tatsächlich Traffic übernehmen kann. Der zweite erkennt, ob der Prozess noch lebt. Ohne passende Health Checks kann AWS zwar neue Tasks starten, aber trotzdem defekte Container hinter dem Load Balancer halten.

Für kleine Teams ist ECS Express Mode interessant, weil der Dienst zentrale Ressourcen wie Fargate, Load Balancer und CloudWatch vorbereiten kann. Sobald individuelle Netzwerksegmente, komplexe Deployments oder mehrere Umgebungen wichtig werden, sollte die Konfiguration in eine eigene Infrastructure-as-Code-Struktur überführt werden.

Sicherheit und Betrieb werden oft unterschätzt

Container sind keine vollständige Sicherheitsgrenze. Ein veraltetes Basis-Image, weitreichende IAM-Rechte oder ein öffentlich erreichbarer Task können die Vorteile der Plattform schnell zunichtemachen. Ich halte deshalb vier Kontrollen für unverzichtbar.

• Minimale IAM-Rechte für Task Role und Execution Role.
• Private Subnets für Anwendungen, die nicht direkt aus dem Internet erreichbar sein müssen.
• Image-Scanning und regelmäßige Updates der Basis-Images.
• Zentrale Logs und Alarme für Fehler, Neustarts, Latenz, CPU und Arbeitsspeicher.

Für Unternehmen in Deutschland kann die Region Frankfurt, eu-central-1, bei Anforderungen an Datenstandort und Latenz sinnvoll sein. Der Standort allein erfüllt jedoch keine DSGVO-Pflichten. Aufbewahrungszeiten, Verschlüsselung, Zugriffskonzepte, Auftragsverarbeitung und eingesetzte AWS-Dienste müssen separat geprüft werden.

Auch beim Logging gilt Zurückhaltung. Ein dauerhaft hohes Logvolumen kann teurer werden als erwartet. Ich empfehle strukturierte Logs im JSON-Format, sinnvolle Aufbewahrungsfristen und Alarme für echte Betriebsprobleme statt für jede harmlose Statusmeldung.

Die häufigsten Fehlentscheidungen beim Container-Hosting

Viele Probleme entstehen nicht durch technische Grenzen, sondern durch falsche Annahmen. Besonders oft sehe ich diese Muster:

• Zu große Tasks, weil CPU und Arbeitsspeicher großzügig geschätzt statt gemessen werden.
• Ein einzelner Task in der Produktion, obwohl ein Ausfall sofort die Anwendung beendet.
• NAT Gateways ohne Kostenprüfung, obwohl die Container nur wenige externe Verbindungen benötigen.
• Mutable Tags wie latest, die spätere Deployments und Rollbacks unklar machen.
• Kein definiertes Rollback, sodass ein fehlerhaftes Release lange online bleibt.
• EKS ohne Kubernetes-Kompetenz, obwohl ECS die Anforderungen bereits erfüllt hätte.

Der größte Kostentreiber ist nicht immer Fargate. Bei kleinen Services können NAT Gateway, Application Load Balancer und Logs einen spürbaren Anteil der Monatsrechnung ausmachen. Für interne Anwendungen lohnt es sich daher zu prüfen, ob ein privater Load Balancer, VPC-Endpunkte oder ein anderes Kommunikationsmuster besser passt.

Auch die Skalierung sollte an einer sinnvollen Messgröße hängen. CPU-Auslastung allein reicht bei einer API oft nicht aus. Request-Latenz, Anzahl wartender Nachrichten oder aktive Verbindungen können viel früher zeigen, dass zusätzliche Tasks gebraucht werden.

Die beste erste Entscheidung ist selten die technisch größte

Für eine neue, AWS-native Webanwendung würde ich im Jahr 2026 meist mit Amazon ECS auf Fargate starten. Diese Kombination reduziert den Infrastrukturaufwand, unterstützt automatisierte Deployments und lässt sich später auf EC2 oder Managed Instances erweitern, wenn die Last oder die Kostenstruktur es verlangen.

EKS ist eine gute Wahl, wenn Kubernetes nicht nur ein Wunsch, sondern eine echte Plattformentscheidung ist. Wer dagegen eine überschaubare Anwendung mit wenigen Services betreibt, gewinnt mit ECS meistens schneller produktive Stabilität als mit einer größeren Plattform.

Die wichtigste praktische Regel lautet für mich deshalb: erst den Betriebsbedarf klären, dann den Dienst auswählen. Ein kleines, automatisiertes ECS-Setup mit sauberem Monitoring ist oft wertvoller als eine technisch beeindruckende Architektur, deren Betrieb niemand zuverlässig verantworten kann.