Die Migration von On-Premise-Infrastrukturen in die Cloud wird oft von einem Gefühl der Euphorie begleitet. Endlich Skalierbarkeit, endlich Flexibilität, endlich modernste Services auf Knopfdruck – zudem die Annahme, man zahle nur noch das, was man auch nutzt. Doch nach der erfolgreichen technischen Migration folgt oft die Ernüchterung: die erste monatliche Abrechnung.
In unserer Rolle als Softwarearchitekten haben wir im vergangenen Jahr genau diesen Zyklus begleitet. Wir haben eine umfangreiche On-Prem-Landschaft mit 22 Spring-Microservices, einer riesigen MongoDB und weiteren unterstützenden Diensten für Monitoring und Logging erfolgreich in die AWS-Cloud migriert (siehe Blogartikel Sprung in die Cloud: Ein Migrationsbericht von Private Cloud zu AWS). Doch was danach kam, war fast spannender als die Migration selbst: die Phase der Konsolidierung und Kostenoptimierung. Wir mussten lernen, dass "Lift & Shift" zwar gut funktioniert, aber selten direkt kosteneffizient ist.
Im Folgenden zeigen wir anhand realer Daten und Charts aus unserem Projekt, wo die Kostenfallen lauerten und mit welchen – teils überraschend einfachen, teils tiefgreifenden – Maßnahmen wir gemeinsam mit unserem Partner devlix die monatlichen Ausgaben deutlich senken konnten. Dabei hatten wir die Herausforderung eines gemischten Lastprofils: Zum einen hohe Lastspitzen durch Batchverarbeitung und zum anderen konstantes Grundrauschen durch Echtzeitverarbeitung globaler Events.
Kostenoptimierung bei EC2 Instanzen: Sizing und Architekturwahl
Ein großer Hebel bei fast jeder Cloud-Infrastruktur sind die Compute-Ressourcen. Bei einer Migration werden Instanzen oft „sicherheitshalber“ zu groß gewählt, um die Performance der alten On-Prem-Server zu spiegeln. Doch Cloud-Computing bietet die Flexibilität, genau das nicht tun zu müssen.
Die Falle der Überprovisionierung
Die Wahl der Instanzgröße hat massiven Einfluss auf die EC2-Kosten. Wir haben gelernt, dass eine korrekte Interpretation des EC2-Monitorings – insbesondere der CPU-Auslastung – essenziell ist, um das passende Sizing zu finden.
Ein Beispiel aus unserem Projekt: Durch den Wechsel des Instanztyps von m5.xlarge (4 vCPUs, 16 GiB RAM) auf t3.xlarge (4 vCPUs, 16 GiB RAM) Ende Juli konnten wir die Kosten merklich reduzieren. Die T-Serie bietet kostengünstige EC2-Instanzen für unregelmäßige Lasten mit zeitweilig höherem CPU-Bedarf, während die M-Serie eine gleichmäßige, konstante Leistung für dauerhafte Workloads bereitstellt. Nach einer sorgfältigen Prüfung unserer Workloads sind wir zu der Erkenntnis gelangt, dass ein Wechsel für uns sinnvoll ist.
Die Power von AWS Graviton
Ein weiterer entscheidender Faktor ist der Wechsel zu ARM-basierten Instanzen, den sogenannten AWS-Graviton-Prozessoren. Sofern die Softwarearchitektur dies zulässt (was bei modernen Workloads meist der Fall ist), bieten Graviton-Instanzen ein deutlich besseres Preis-Leistungs-Verhältnis.
Ein direkter Vergleich zweier ähnlicher Instanztypen in der Region eu-central-1:
- t3a.large (2 vCPU, 8 GiB RAM, x86 Architektur): ca. 0,0737 € pro Stunde
- t4g.large (2 vCPU, 8 GiB RAM, ARM64 Architektur): ca. 0,0655 € pro Stunde
Durch einen Wechsel auf t4g.large kann man hier ca. 11% der Kosten sparen.
Weitere Methoden zur Kostenoptimierung
Um weiter Kosten einzusparen könnte sich ein Blick auf das EC2-Autoscaling lohnen, denn dadurch wird die Anzahl der laufenden EC2-Instanzen automatisch an die tatsächliche Auslastung angepasst. Aufgrund unseres eher konstanten Lastprofils ist diese Möglichkeit zur Kostenoptimierung hier weniger relevant.
AWS Reserved Instances ermöglichen durch eine vertragliche Verpflichtung EC2 Instanzen für eine bestimmte Dauer zu nutzen signifikante Rabatte. Da diese Kontingente bei unserem Kunden zentral verwaltet werden, sind sie für uns aus dem Projekt heraus nicht einsehbar. Sie wirken sich aber stark auf die Cloudkosten des Unternehmens aus.
Unser Fazit: Nutze Metriken, um das notwendige Sizing zu erkennen, und wähle die kleinstmögliche Instanzklasse, die dennoch den Anforderungen genügt. Prüfe immer, ob ARM-basierte Instanzen, Autoscaling oder Reserved Instances eine Option sind.
Document DB: Der Teufel steckt im I/O-Detail
Während EC2-Optimierungen oft offensichtlich sind, verbergen sich bei Datenbanken wie Amazon DocumentDB die Kosten oft in den Details der Nutzungsmuster. Hier haben wir die größten Überraschungen erlebt – und die größten Erfolge erzielt.
Das richtige Sizing der Instanzen
Ähnlich wie bei EC2 ist auch bei DocumentDB die Wahl der Instanzklasse entscheidend. Wir starteten, angelehnt an unser vorherige On-Prem-Landschaft, mit db.r8g.xlarge (4 vCPUs, 32 GiB Speicher) für unsere produktiven Workloads. Auch hier zeigte das Monitoring: Wir zahlen für Luft.
Mitte April führten wir ein Downsizing auf db.r8g.large (2 vCPUs, 16 GiB Speicher) durch. Im Ergebnis haben sich die Instanzkosten nahezu halbiert:
Wichtig: Achte auf die DB-Auslastung und Lastspitzen. Wähle die kleinste Instanzklasse, die den Anforderungen noch entspricht, um nicht für ungenutzte Ressourcen zu zahlen. Nutze Metriken!
Der versteckte Kostentreiber: Fehlende Indexe und I/O
Doch das Sizing war nur die halbe Miete. Ab April 2025 bemerkten wir, dass unsere Gesamtkosten für DocumentDB trotz kleinerer Instanzen stetig stiegen. Eine Analyse im Cost Explorer zeigte den Schuldigen: I/O-Operationen.
Was war passiert? Unsere Datenbank wuchs stetig. Gleichzeitig nutzten Abfragen vorgesehene Indexe nicht. Die Folge: Full Table Scans. Bei einer kleinen Datenbank fällt das nicht auf. Aber wenn die Datenbank durch fortwährend neue Features wächst, muss für jede Abfrage immer mehr Datenvolumen von der Disk gelesen werden. Da AWS bei der Standard-Konfiguration pro I/O-Operation abrechnet, steigen die Kosten proportional zum Datenwachstum stark an:
Index-Optimierung war die Lösung: Wir analysierten die langsamen Querys, identifizierten die Abfragen ohne Indexnutzung und legten entsprechende Indexe an. Das reduzierte die I/O-Last drastisch.
Das richtige Speichermodell: Standard vs. I/O-Optimized
AWS bietet für DocumentDB zwei Speichermodelle an, und die Wahl eines unpassenden Modells kann teuer werden:
- Standard: Geringe Speicherkosten, aber man zahlt für jede I/O-Operation.
- I/O-Optimized: Höhere Speicherkosten, aber dafür sind I/O-Operationen inklusive (wie eine Flatrate).
Wir haben berechnet, dass sich für unser I/O-intensives Szenario (häufige umfangreiche Abfragen und Datenmigrationen) das Flatrate-Modell lohnt. Am 15. Juli stellten wir auf I/O-optimized um. Die Kostenspitzen verschwanden sofort, und die Kosten wurden planbar und stabil.
Instanzanzahl in Non-Prod-Umgebungen
Ein weiterer "Quick Win": Ausfallsicherheit ist wichtig, aber braucht die Entwicklungsumgebung wirklich ein DocumentDB-Cluster aus drei Instanzen für High Availability? AWS empfiehlt für die Produktionsumgebung drei Instanzen. Für unsere Test-Stages haben wir die Anzahl am 22.10. von drei auf eins reduziert. Fällt die Instanz aus, müssen die Entwickler kurz warten, bis sie neu startet – ein vertretbares Risiko, das die Kosten für diese Umgebungen deutlich senkt.
Infrastructure as Code (IaC): Ordnung ist die halbe Miete
Manuelle Eingriffe in der Cloud ("ClickOps") sind nicht nur fehleranfällig, sondern auch teuer. Wir setzen konsequent auf Infrastructure as Code mit OpenTofu. Warum spart das Geld?
Äquivalente Umgebungen
Dank IaC können wir dieselben Skripte sowohl für die Produktionsumgebung als auch für die Testumgebungen nutzen. Durch Parametrisierung stellen wir sicher, dass die Testumgebungen architektonisch identisch zur Produktionsumgebung sind, aber auf deutlich kleineren (und günstigeren) Instanztypen laufen. Dies spart Zeit bei der Fehlersuche und senkt gleichzeitig die Kosten.
Im Betrieb erhöht IaC die Ausfallsicherheit, da beispielsweise die Ressourcen einfach und schnell in einer anderen Region neu aufgesetzt werden können, falls es Probleme mit der Cloud-Infrastruktur gibt.
Vermeiden von Ressourcen-Leichen
Große und unnötige Kostentreiber sind vergessene Ressourcen. Durch IaC wird alles nachvollziehbar:
- Traceability: Es ist genau nachvollziehbar, wer was wann erstellt hat.
- Vollständiges Aufräumen: IaC-Tools löschen beim Entfernen einer Hauptressource automatisch alle abhängigen Ressourcen (z.B. EBS-Volumes oder Elastic IPs bei EC2-Instanzen), die beim manuellen Löschen leicht übersehen werden.
- Drift-Detection: Manuell erstellte „Schatten-Ressourcen“ fallen sofort auf, da sie nicht im Code definiert sind.
CloudWatch: Wenn Logging zum Luxus wird
CloudWatch ist ein mächtiges Werkzeug, aber es kann schnell zu einem der größten Kostenfaktoren auf der Rechnung werden, wenn es unbedacht benutzt wird.
Die Kosten der Neugier (Log Insights)
Viele Teams sind sich nicht bewusst, dass Kosten für CloudWatch Logs-Insights pro gescannte Gigabyte berechnet werden (meist ca. 0,005 USD pro GB). Das klingt wenig. Aber wenn Terabytes an Logs gelesen werden und dabei kein enger Zeitfilter gesetzt wird, summieren sich diese Cent-Beträge bei jeder Abfrage.
In Entwicklungsteams wird intuitiv oft dazu tendiert, große Zeiträume ("letzte 4 Wochen") zu wählen oder über mehrere riesige Log-Groups gleichzeitig zu suchen.
Die Spitzen in der Grafik oben korrelieren direkt mit Tagen, an denen intensive Fehlersuche betrieben wurde.
Unser Tipp: Sensibilisiere dein Team. Ein stark einschränkender Suchfilter (z.B. nur ERROR filtern) reduziert nicht die Menge der gescannten Daten, sondern nur das Ergebnis. Nur die Einschränkung des Zeitraums oder der durchsuchten Log-Streams reduziert die gescannten Gigabytes und damit die Kosten.
Log-Volumen reduzieren
Noch effektiver als effizientes Abfragen ist es, die Daten gar nicht erst zu erzeugen. CloudWatch berechnet nicht nur Kosten für das Durchsuchen, sondern auch für das Schreiben/Verarbeiten von Logs.
Als wir die hohen Kosten sahen, haben wir am 21.08. folgende Maßnahmen getroffen:
- Anpassung der Log-Level: Wir haben das Log-Level einiger häufiger, aber weniger wichtiger Logs reduziert. Je nach Umgebung werden diese dann nur geschrieben, wenn zu Analysezwecken das Log-Level des Loggers gesenkt wird.
- Entfernen von unnötigen Log-Statements ("Noise"), die keinen diagnostischen Mehrwert bieten
- Prüfung auf häufig wiederholte Logs und Abwägen der Notwendigkeit
- Setzen von Log-Retentions, um alte Logs nicht unbegrenzt vorzuhalten
Durch diese Anpassungen konnten wir die geschriebenen Logs und damit die Kosten merklich reduzieren:
Trusted Advisor: Der automatisierte Berater
Manchmal liegt das Gute so nah. Der AWS Trusted Advisor ist ein oft übersehenes Tool, das in jedem Account verfügbar ist (der Funktionsumfang variiert je nach Support-Plan).
Er bietet automatisierte "Cost Optimization Checks". Er erkennt beispielsweise:
- EC2-Instanzen mit sehr geringer Auslastung (< 10 Prozent CPU über mehrere Tage)
- Ungenutzte Elastic IPs
- Idle Load Balancers
In unserem Fall wies uns der Trusted Advisor auf ein Einsparpotenzial von über 200 $ monatlich hin, hauptsächlich durch überdimensionierte Instanzen. Es lohnt sich, diesen Check in eine wöchentliche oder monatliche Routine aufzunehmen.
Elastic Container Registry (ECR) Lifecycle Rules
Ein schleichender Kostentreiber, den wir im Cost Explorer entdeckten, ist die ECR. Die Kosten steigen linear an. Der Grund: Unsere CI/CD-Pipelines bauen für jedes Release und jedes Deployment (auch auf Testumgebungen) neue Container-Images und laden sie in die Registry hoch. Wir speichern aktuell alte Images, die nach dem Deployment eines neueren Releases nicht mehr benötigt werden.
Die Lösung ist trivial, aber man muss sie kennen: Lifecycle Rules. Dort können individuell Regeln definiert werden, wie zum Beispiel, dass untagged Images nach einer Woche gelöscht werden. Das Ergebnis ist eine saubere Registry und stabile Storage-Kosten.
Idee: OpenSearch als Alternative zu CloudWatch?
Kostenoptimierung hört nie auf. Wenn die Standard-Maßnahmen umgesetzt sind, lohnt es sich, kreativ zu werden und auch gefasste Architekturentscheidungen zu hinterfragen.
Mit den Kostenoptimierungen für CloudWatch erzielten wir gute Erfolge. Dennoch stellen wir die folgende These auf: Wäre eine selbstgehostete OpenSearch-Instanz (oder der Managed Service) günstiger als CloudWatch Logs?
Die Idee ist, Anwendungs-Logs, die bei uns die größten Kostentreiber sind, nicht mehr nach CloudWatch zu streamen, sondern in einen selbstgehosteten OpenSearch Cluster. Unsere Grobkalkulation zeigt: Es fallen dennoch relevante Kosten an, da wir für Compute und Storage des Clusters zahlen müssen. Aber ab einem gewissen Log-Volumen ist die "Flatrate" eines Clusters günstiger als das "Pay-per-GB"-Modell von CloudWatch.
Dieses Szenario muss individuell durchgerechnet werden (der AWS Cost Calculator ist hier hilfreich), aber es zeigt, dass auch Managed Services hinterfragt werden dürfen.
Fazit
Unsere Projekterfahrungen zeigen, dass man durch folgende Prinzipien hohe Summen sparen kann:
- Messen statt Raten: Nutze CloudWatch-Metriken, um das richtige Sizing zu finden.
- Architektur verstehen: Ob ARM-Prozessoren, DB-Indizes oder Speicher-Flatrates – die technologische Wahl hat großen Einfluss auf den Preis.
- Automatisierung nutzen: IaC verhindert "Müll" in der Cloud und sorgt für schlanke Umgebungen.
- Regelmäßigkeit: Prüfe monatlich den Cost Explorer und den Trusted Advisor, um Trends wie bei ECR frühzeitig zu erkennen. Auch Cost-Monitors und Alerts können vor unerwarteten Anstiegen schützen.
- Sensibilisierung des Teams: Alle im Entwicklungsteam sollten wissen, dass ein unbedachtes Log-Statement oder eine ineffiziente Query direkte Auswirkungen auf die Rechnung hat.
- Verhältnismäßigkeit: Kosten senken um jeden Preis, ist nicht zielführend. Große Einsparpotenziale auszumachen und sich darauf zu konzentrieren, bringt mehr als jedem einzelnen Euro hinterherzurennen.
Der Weg in die Cloud lohnt sich – an Flexibilität und Geschwindigkeit ist sie kaum zu überbieten. Aber sie erfordert ein neues Bewusstsein. Als Verantwortliche in der Softwarearchitektur sind wir heute nicht mehr nur für die Struktur des Codes zuständig, sondern auch für die Effizienz der Ressourcen. Und am Ende des Tages ist eine effiziente Architektur auch immer eine kostengünstige Architektur.
