AWS-Kosten strukturiert senken: Rechnung zerlegen, Maßnahmen absichern, danach messen
Wie ich die AWS-Rechnung meines Ein-Personen-Accounts mit Rechnungsanalyse, Review-Board, abgesicherten Maßnahmen und Budget als Code um rund 40 Prozent gesenkt habe – und welche Posten nicht gesunken sind.
Wie ich die AWS-Kosten meines eigenen Accounts nicht mit einer Aufräumaktion, sondern mit einem nachvollziehbaren Ablauf gesenkt habe. Derselbe Ablauf funktioniert in Kunden-Accounts – dort meist mit mehr Beteiligten und mehr zu verlieren.
Ausgangslage
Mein AWS-Account ist klein und gehört einer Ein-Personen-Firma: Website, ein Chatbot, ein paar Serverless-Anwendungen und einige EC2-Instanzen, die nur bei Bedarf laufen – darunter SonarQube, eine Datenbank-Oberfläche und ein Agenten-Orchestrator für KI-Coding-Agenten. Alles ist mit AWS CDK als Code beschrieben.
Über das erste Halbjahr ist die Monatsrechnung schrittweise gewachsen, jeder Schritt für sich gut begründet. Im Juli war sie dann deutlich höher als erwartet. Der Auslöser war meine eigene Komfortänderung: Anfang Juli hatte ich für den Agenten-Orchestrator einen automatischen Morgenstart eingebaut. Die großzügig dimensionierte Instanz lief damit rund 18 Stunden am Tag – bei einer CPU-Auslastung von zwei bis fünf Prozent. Compute machte im Juli knapp 40 Prozent der Nettorechnung aus, fast vollständig diese eine Instanz.
Daneben gab es die üblichen Altlasten: Snapshots, deren Zweck niemand mehr sicher benennen konnte, nicht mehr genutzte Secrets, Monitoring-Optionen eines Experimentierprojekts. Und ein manuell angelegtes Budget, das seit Monaten jeden Monat überschritten wurde, ohne dass eine Warnung ankam.
Lösung
Ich bin in vier Schritten vorgegangen.
1. Rechnung zerlegen. Mit Cost Explorer habe ich die Juli-Rechnung bis auf Nutzungsarten heruntergebrochen und jedem größeren Posten eine konkrete Ressource und ein verursachendes Projekt zugeordnet. So wird aus „AWS ist teuer“ eine Liste.
2. Befunde prüfen lassen. Die Maßnahmenliste ging an ein Review-Board aus fünf Rollen – Architektur, Security, Senior Dev, FinOps und ein ausdrücklicher Skeptiker –, die ich als KI-Agenten mit getrennten Aufträgen habe arbeiten lassen. Das Board hat vier meiner Annahmen widerlegt. Eine scheinbar verwaiste Elastic IP gehörte in Wahrheit zu einer von AWS verwalteten Ressource, von der zwei Dienste abhingen. Zwei Sicherheits-Snapshots sollten weg, weil es ein S3-Backup gab – nur war dieses Backup älter als die letzte Konfigurationsänderung. Ein weiterer Snapshot war die einzige Kopie eines Datenvolumens außerhalb der Instanz. Und ein altes Maschinen-Image, das ich als archiviert abgehakt hatte, ist die einzige forensische Referenz eines früheren Servers. Jeder dieser Punkte hätte mehr gekostet, als die Löschung gespart hätte.
3. Maßnahmen absichern statt sofort ausführen. Jede Maßnahme bekam einen Schalter oder eine harte Vorbedingung.
4. Danach messen. Statt eines Zielwerts zählen die tatsächlichen Monatskosten aus Cost Explorer. Das Board hatte vorab zwei Erfolgskriterien als Tageskosten festgelegt, an denen ich mich messe.
Leitplanken
- Schalter statt Löschen. Der automatische Morgenstart ist nicht entfernt, sondern über eine Stack-Eigenschaft abgeschaltet, Standard „aus“. Die nächtliche Abschaltung bleibt. Gestartet wird die Instanz bei Bedarf, über mein Betriebs-Cockpit oder die CLI. Nebeneffekt: Eine gestoppte Instanz bleibt jetzt gestoppt – auch das ist eine Sicherheitseigenschaft.
- Backup vor Cleanup, im Skript erzwungen. Das Aufräumskript läuft standardmäßig im Probelauf. Snapshots löscht es nur, wenn ein datiertes Backup der betroffenen Daten höchstens sieben Tage alt ist. Secrets, die in den letzten 90 Tagen gelesen wurden, sind gesperrt; alle anderen gehen mit 30 Tagen Wiederherstellungsfrist. Ausführen lässt es sich nur interaktiv, mit einer getippten, datumsgebundenen Bestätigung – nicht aus einer Pipeline und nicht von einem Agenten.
- Ein Backup-Skript als Vorbedingung. Für den Agenten-Orchestrator gab es vorher keine vollständige Kopie außerhalb der Instanz. Das neue Skript sichert Datenbank-Dump und Datenvolumen direkt nach S3, ohne Zwischenablage auf der knappen Systemplatte.
- Budget als Code. Das account-weite Monatsbudget steht jetzt in einem eigenen CDK-Stack, mit E-Mail-Warnungen, statt als manuelle Einstellung in der Konsole. Wichtig für die Erwartungshaltung: Die direkte Nutzung der Anthropic-API läuft außerhalb der AWS-Rechnung und wird von diesem Budget nicht erfasst.
- Der Mensch entscheidet. Code und Analyse kamen per Pull Request; die Wahl zwischen den Varianten und das Deployment lagen bei mir.
Ergebnis
Die gemessenen Zahlen aus Cost Explorer, Juli bis September:
- Die Gesamtrechnung sank um rund 40 Prozent, mit und ohne Umsatzsteuer gleichermaßen. Schon im August lag sie gut ein Drittel unter dem Juli.
- Die Compute-Kosten fielen von Juli auf August um über 90 Prozent und blieben im September niedrig. Dieser eine Schalter erklärt fast den gesamten Rückgang.
- Das erste der beiden Erfolgskriterien war im September erreicht, das zweite nicht.
Genauso wichtig ist, was nicht gesunken ist. Netzwerkkosten – vor allem Interface-Endpoints und öffentliche IPv4-Adressen – und CloudWatch blieben nahezu unverändert. Im September machten diese beiden Posten zusammen mehr als zwei Drittel der Nettorechnung aus. Das Budget wurde im August und September trotz des Rückgangs überschritten; eine niedrigere Schwelle ergibt erst Sinn, wenn die nächsten Hebel greifen.
Die gesperrte Aufräumaktion lief erst im Oktober, als die erzwungenen Backups frisch waren. Das Experimentierprojekt, das den größten Teil der CloudWatch-Metriken verursachte, ist inzwischen beendet, eine nicht mehr benötigte Datenbank gelöscht. Deren Wirkung lässt sich noch nicht belegen: Der Oktober ist durch einmalige Domain-Registrierungen verzerrt, ich messe im November nach. Offen sind außerdem die Bewertung einer kleineren Instanzgröße, die Frage, ob die Endpoints in einer statt zwei Availability Zones reichen, und ein regelmäßiger statt manueller Backup-Lauf.
Transfer
Eins zu eins übertragbar auf Kunden-Accounts ist der Ablauf: Rechnung bis auf Ressource und Verursacher zerlegen, Befunde von einer kritischen zweiten Instanz prüfen lassen, Maßnahmen hinter Schalter und erzwungene Vorbedingungen legen, das Budget im Code führen und hinterher messen statt Zielwerte zu berichten. Besonders der Skeptiker im Review lohnt sich – die teuersten Fehler bei Kostensenkungen sind Löschungen, die sich später als einzige Kopie herausstellen.
Nicht übertragbar ist die Entscheidungsgeschwindigkeit. Bei mir sind Betreiber, Kostenstelle und Freigabe eine Person. In einem Unternehmen braucht dieselbe Maßnahmenliste Verantwortliche je Posten, abgestimmte Wartungsfenster und oft Tagging, bevor die Zerlegung überhaupt sauber gelingt.
Das Pattern passt, wenn eine Rechnung schrittweise gewachsen ist, niemand mehr jeden Posten erklären kann und schnelles Aufräumen riskanter wäre als langsames.
Stack: AWS · AWS CDK · AWS Cost Explorer · AWS Budgets · EventBridge Scheduler · Bash