Viele kleine DevOps-Teams starten mit AWS aus einem guten Grund: Infrastruktur ist schnell verfügbar, die Auswahl an Diensten ist groß und für fast jedes Problem gibt es einen verwalteten Baustein. Genau daraus entsteht aber das Risiko. Nach wenigen Monaten laufen EC2-Instanzen, Lambda-Funktionen, S3-Buckets, CloudFront-Distributionen, RDS-Datenbanken, mehrere IAM-Rollen und ein paar vergessene Testumgebungen nebeneinander. Auf dem Papier wirkt das modern. Im Alltag wird jede Änderung langsamer, weil niemand mehr sicher sagen kann, welche Abhängigkeit wirklich produktionskritisch ist.
Für kleine Teams ist AWS dann sinnvoll, wenn es Betrieb reduziert und Entscheidungen vereinfacht. Es ist weniger sinnvoll, wenn jeder Service eigenes Monitoring, eigene Kostenlogik, eigene Security-Ausnahmen und eigene Deployment-Pfade mitbringt. Ein guter Einstieg beginnt daher nicht mit einer Feature-Liste, sondern mit drei Fragen: Welche Anwendung muss laufen? Welche Daten sind kritisch? Wer kann das System im Fehlerfall um 22 Uhr verstehen?
Die solide Basis: IAM, Budgets und Logging
Bevor Workloads gebaut werden, braucht jedes kleine Team eine minimale Plattformbasis. Dazu gehören getrennte AWS-Accounts oder zumindest klar getrennte Umgebungen für Produktion und Entwicklung, MFA für alle Benutzer, Rollen statt langfristiger Access Keys und ein zentraler Ort für Logs. CloudTrail sollte aktiv sein, AWS Budgets sollte monatliche Kostenlimits melden und der Zugriff auf die Root-Identität muss sauber dokumentiert sein.
Diese Basis wirkt unspektakulär, spart aber später sehr viel Zeit. Wenn ein Entwickler versehentlich eine große Instanz startet oder ein Schlüssel in einem alten CI-Job liegen bleibt, sind Warnungen und Logs wichtiger als der fünfte Spezialservice. Gerade kleine Teams sollten sich angewöhnen, Infrastrukturänderungen über Terraform, OpenTofu oder CloudFormation zu beschreiben. Das muss nicht perfekt modularisiert sein. Wichtig ist, dass Ressourcen auffindbar bleiben und Änderungen nachvollziehbar sind.
S3, CloudFront und Route 53 sind fast immer sinnvoll
S3 ist einer der Dienste, die kleine Teams sehr früh einsetzen können. Statische Assets, Backups, Exporte, Logs und einfache Website-Dateien lassen sich robust und günstig speichern. Mit Lifecycle-Regeln können alte Dateien automatisch in günstigere Speicherklassen wandern oder gelöscht werden. Wichtig ist nur, Buckets nicht pauschal öffentlich zu machen und Verschlüsselung, Versionierung und Block-Public-Access bewusst zu konfigurieren.
CloudFront lohnt sich, wenn Inhalte weltweit oder einfach stabil ausgeliefert werden sollen. Es nimmt Last von Ursprungsservern, bringt TLS sauber an die Kante und kann auch vor statischen S3-Inhalten sitzen. Route 53 ist ebenfalls pragmatisch, sobald DNS, Zertifikate und AWS-Ressourcen zusammen verwaltet werden. Diese drei Dienste erzeugen wenig operativen Overhead, wenn sie einmal sauber eingerichtet sind.
Für Anwendungen: ECS Fargate oft vor Kubernetes
Viele Teams springen gedanklich sofort zu Kubernetes, sobald Container im Spiel sind. Für kleine Teams ist das häufig zu viel. Amazon ECS mit Fargate deckt viele typische Anforderungen ab: Container starten, skalieren, Logs nach CloudWatch schreiben, Secrets einbinden und Deployments über eine Pipeline ausrollen. Man bekommt Container-Betrieb ohne eigene Control Plane, ohne Node-Patching und ohne die ganze Lernkurve rund um Ingress, Cluster-Autoscaling und Helm.
Kubernetes auf EKS ist sinnvoll, wenn das Team bereits Kubernetes-Erfahrung hat, mehrere Services mit komplexen Netzwerkregeln betreibt oder portabel zwischen Plattformen bleiben muss. Ohne diese Gründe ist EKS oft ein Multiplikator für Betrieb. Kleine Teams sollten zuerst prüfen, ob ein einzelner ECS-Service, ein Application Load Balancer und RDS das Problem lösen. Wenn ja, ist das meistens die bessere Architektur.
RDS statt selbst betriebener Datenbank
Bei relationalen Datenbanken ist RDS fast immer sinnvoller als eine selbst verwaltete PostgreSQL- oder MySQL-Instanz auf EC2. Backups, Minor-Version-Updates, Storage-Erweiterung, Read Replicas und Multi-AZ sind Dinge, die im Fehlerfall zählen. Eine selbst betriebene Datenbank wirkt anfangs günstiger, kostet aber Bereitschaft, Tests und Erfahrung. Für kleine Teams ist die Frage nicht nur, ob die Datenbank heute läuft, sondern ob ein Restore unter Stress gelingt.
Aurora kann spannend sein, ist aber nicht automatisch die richtige Wahl. Für viele Anwendungen reicht eine normale RDS-Instanz mit sauberer Backup-Policy, Performance Insights bei Bedarf und einer nachvollziehbaren Parametergruppe. Serverless-Varianten sollten erst eingesetzt werden, wenn Lastprofile wirklich schwanken und die Kaltstart- oder Skalierungsdetails verstanden sind.
Lambda ist gut für klare, kleine Aufgaben
Lambda ist hervorragend für Event-Verarbeitung, kleine Integrationen, Webhooks, geplante Jobs und Glue-Code. Ein Report soll jede Nacht erzeugt werden, ein S3-Upload soll ein Thumbnail auslösen, ein Formular soll validiert und an eine Queue übergeben werden: Das sind passende Aufgaben. Problematisch wird Lambda, wenn eine komplette Anwendung in viele schwer nachvollziehbare Funktionen zerlegt wird, ohne Observability und lokale Teststrategie.
Ein guter Prüfstein lautet: Kann jemand im Team den Ablauf in zehn Minuten erklären? Wenn nicht, ist ein kleiner Container-Service oft verständlicher. Lambda reduziert Serverbetrieb, ersetzt aber keine Architektur. Logs, Dead-Letter-Queues, Timeouts, Retry-Verhalten und Berechtigungen müssen genauso bewusst geplant werden.
Dienste, die schnell zu viel werden
Einige AWS-Services sind stark, aber für kleine Teams nur mit klarem Bedarf sinnvoll. EKS wurde bereits genannt. Auch komplexe Event-Architekturen mit EventBridge, Step Functions, mehreren Queues und vielen Lambdas können mehr mentale Last erzeugen als Nutzen. Managed OpenSearch ist praktisch, aber teuer und betrieblich anspruchsvoll, wenn es nicht wirklich gebraucht wird. Multi-Account-Setups mit Control Tower, Security Hub, GuardDuty, Config und zentralem SIEM sind für reifere Organisationen wertvoll, sollten aber stufenweise eingeführt werden.
Das heißt nicht, diese Dienste zu vermeiden. Es heißt, sie nicht als Standardantwort zu verwenden. Für kleine Teams ist eine langweilige Architektur oft die schnellere Architektur: wenige Komponenten, klare Verantwortlichkeiten, gute Backups, nachvollziehbare Deployments und Alerts, die tatsächlich jemand liest.
Ein pragmatischer Startpunkt
Eine solide kleine AWS-Architektur kann so aussehen: Route 53 für DNS, CloudFront und S3 für statische Assets, ECS Fargate für die Anwendung, RDS PostgreSQL für Daten, Secrets Manager für sensible Konfiguration, CloudWatch für Logs und Alarme, dazu Terraform oder OpenTofu für die Ressourcen. CI/CD baut Container, pusht sie nach ECR und aktualisiert den ECS-Service. Budgets melden Kostenabweichungen, CloudTrail dokumentiert API-Aktionen.
Dieser Stack ist nicht spektakulär, aber er ist wartbar. Er lässt Raum für Wachstum, ohne jedes Teammitglied zum Plattformingenieur zu machen. Wenn später mehr Anforderungen entstehen, kann man gezielt erweitern: SQS für robuste Hintergrundjobs, Lambda für kleine Event-Hooks, WAF vor CloudFront oder ALB, bessere Observability über OpenTelemetry. Der Unterschied liegt darin, dass jede Erweiterung ein konkretes Problem löst.
Fazit
AWS ist für kleine Teams dann stark, wenn es Stabilität einkauft und Komplexität sichtbar hält. Sinnvolle Services sind jene, die Betrieb senken: S3, CloudFront, Route 53, RDS, ECS Fargate, ECR, Secrets Manager, CloudWatch und Budgets. Vorsicht ist bei Diensten geboten, die viele neue Konzepte einführen, bevor das Team sie wirklich braucht.
Die beste Cloud-Architektur für ein kleines Team ist selten die beeindruckendste. Sie ist die, die auch nach sechs Monaten noch verstanden, gepatcht, wiederhergestellt und bezahlt werden kann.