FinOps auf AWS jenseits von Savings Plans: Architekturkosten haben kein Dashboard. Warum die teuersten Stellen in Ihrer Rechnung keine Alerts schicken, wie Sie sie finden und wann sich das Suchen nicht lohnt.
Ein Setup, das mir kürzlich begegnet ist: Logs liefen von den ECS-Tasks an CloudWatch, von dort per Lambda-Forwarder weiter an Datadog. Technisch sauber, lief seit Monaten, niemand hatte ein Problem damit. Kosten: rund 700 Euro im Monat, über acht Monate hinweg. Für einen Umweg, den niemand brauchte.
Niemand hatte diese Architektur gebaut, um Geld zu verbrennen. Sie war so gewachsen. Jemand hatte irgendwann den naheliegenden Weg genommen, CloudWatch war ohnehin da, der Forwarder war schnell geschrieben, und danach hat das System einfach funktioniert. Genau das ist das Problem.
Ein abgestürzter Service schickt einen Alert. Eine überdimensionierte Instanz nicht. Eine fehlerhafte Kostenarchitektur läuft still weiter und schreibt jeden Monat dieselbe Zahl auf die Rechnung, bis irgendwann jemand genau hinschaut. Meistens dauert das Jahre.
Warum niemand hinschaut
Wenn ein Unternehmen wächst, zählt eine Zahl: Wachstum. Neue Kunden, neue Features, mehr Traffic. Das Engineering-Team baut, deployt, baut weiter. Wer fragt da nach den AWS-Kosten?
Niemand. Und das ist auch richtig so.
Wer jeden Monat zweistellig wächst, steckt keine Kapazität in S3-Storage-Klassen oder CloudWatch-Retention. Eine Entwicklerstunde, die in die Optimierung einer 200-Euro-Position fließt, statt in das Feature, das den nächsten Großkunden bringt, ist in dieser Phase falsch investiert. Kostenbewusstsein zur falschen Zeit ist genauso teuer wie Kostenblindheit zur richtigen.
Aber irgendwann flacht die Kurve ab. Der Fokus verschiebt sich von schneller zu effizienter. Und dann schaut sich jemand zum ersten Mal die AWS-Rechnung wirklich an, nicht die Summe unten, sondern die Struktur dahinter. In diesem Moment wird sichtbar, was sich über Jahre angesammelt hat.
Das eigentliche Problem ist nicht, dass diese Kosten existieren. Es ist, dass sie keine Sichtbarkeit haben. Ein Service mit hoher Latenz taucht im Tracing auf. Eine Fehlerquote landet im Dashboard. Aber die Entscheidung, Logs über einen teuren Umweg zu schicken oder Traffic über AZ-Grenzen laufen zu lassen, hinterlässt keine Spur in den Systemen, auf die ein Team täglich schaut. Sie steht nur in der Rechnung, und die liest niemand zeilenweise.
Der Umweg, den niemand sieht
Zurück zum Logging-Beispiel, weil es exemplarisch ist.
Der awslogs-Driver schickt Container-Logs an CloudWatch Logs. Von dort holt ein Subscription Filter sie ab und ein Lambda leitet sie an Datadog weiter. Jede Station kostet: CloudWatch berechnet die Ingestion pro Gigabyte, das Lambda berechnet Invocations und Laufzeit, und der ausgehende Traffic kostet ebenfalls. CloudWatch ist hier reine Durchlaufstation, für die voll bezahlt wird.
Der häufigste Reflex an dieser Stelle ist falsch: die Retention kürzen. Das spart nichts Relevantes. Bei CloudWatch Logs ist der dominierende Kostenfaktor die Ingestion, also das Aufnehmen der Daten, nicht die Aufbewahrung. Wer die Retention von 365 auf 30 Tage senkt, reduziert die Storage-Kosten, die ohnehin nur einen Bruchteil ausmachen. Die Ingestion ist da längst bezahlt.
Der richtige Hebel ist die Architektur. FireLens ist ein Log-Router, der als Sidecar im ECS-Task läuft, intern meist auf Fluent Bit. Er nimmt die Container-Logs entgegen und schickt sie direkt an Datadog, ohne CloudWatch dazwischen. Die Ingestion-Kosten fallen weg, das Forwarder-Lambda wird überflüssig, der Datenpfad wird kürzer.
Wichtig ist, präzise zu sein, was das spart und was nicht. Die rund 700 Euro im Monat sind die AWS-seitigen Kosten des Umwegs. An der Datadog-Rechnung ändert FireLens nichts, denn Datadog rechnet ebenfalls nach ingestiertem Volumen ab. FireLens entfernt die Maut auf der Strecke, nicht das Ziel. Und es ist ein Trade-off: Wer CloudWatch ganz aus dem Pfad nimmt, verliert die native Abfragbarkeit über Logs Insights und eine Pufferschicht, auf die manche Teams für Ad-hoc-Analysen bauen. Für ein Team, das ohnehin alles in Datadog auswertet, ist das ein reiner Gewinn. Für ein Team, das CloudWatch aktiv nutzt, ist es eine bewusste Entscheidung. Über die acht Monate, die das Setup lief, waren es so oder so 5.600 Euro für eine Konfiguration, die in einem halben Tag korrigierbar gewesen wäre. Und das war eine einzige Stelle.
Die üblichen Verdächtigen
Gewachsene AWS-Setups haben fast immer mehrere solche Stellen. Keine einzelne reißt das Budget. Zusammen sind es regelmäßig vier- bis fünfstellige Beträge pro Jahr, die still verschwinden.
NAT Gateway
Ein NAT Gateway kostet doppelt: einen Stundenpreis für die Bereitstellung und einen Preis pro Gigabyte verarbeiteter Daten. Der Stundenpreis ist bekannt. Die Datenverarbeitung ist es selten.
Der teure Fehler entsteht, wenn Traffic zu anderen AWS-Diensten durch das NAT Gateway läuft, obwohl er das nicht müsste. Ein Service in einem privaten Subnetz, der S3, DynamoDB oder ECR anspricht, schickt diesen Verkehr standardmäßig über das NAT Gateway. Jedes Gigabyte wird berechnet, obwohl das Ziel innerhalb von AWS liegt.
VPC Gateway Endpoints für S3 und DynamoDB lösen das. Sie sind kostenlos und halten diesen Traffic vollständig vom NAT Gateway fern. Für Dienste wie ECR oder Secrets Manager gibt es Interface Endpoints, die zwar selbst etwas kosten, bei hohem Volumen aber deutlich günstiger sind als die NAT-Datenverarbeitung. In Setups, in denen der Großteil des NAT-Volumens auf solchen AWS-internen Verkehr entfällt, verschwindet damit der Löwenanteil der Kosten. Wer zusätzlich pro Availability Zone ein eigenes Gateway betreibt, ohne es zu brauchen, zahlt den Stundenpreis mehrfach.
Datentransfer
Das NAT Gateway ist nur die sichtbarste Scheibe eines größeren Blocks, und der ist oft der teuerste überhaupt: Datentransfer. Er taucht in keiner Architekturskizze auf und in keinem Dashboard, aber er steht in jeder Rechnung.
Drei Stellen lohnen den Blick. Erstens der Verkehr zwischen Availability Zones. Er wird in beide Richtungen berechnet, pro Gigabyte in jede Richtung. Ein Service, der ständig mit einer Datenbank in einer anderen AZ spricht, oder eine Replikation über AZ-Grenzen, summiert sich genau wie die NAT-Geschichte, nur dass niemand einen einzelnen Verursacher vor Augen hat. Zweitens das Cross-Zone Load Balancing: Beim ALB ist es inklusive, beim NLB ist es standardmäßig aus und erzeugt beim Einschalten genau diese Inter-AZ-Kosten. Wer es ohne Grund aktiviert, zahlt dafür. Drittens der Egress ins Internet. Ausgehender Traffic kostet pro Gigabyte, eingehender ist frei. Bei Workloads, die viel ausliefern, ist CloudFront davor oft günstiger als direkter Egress, weil gecachte Auslieferung niedriger bepreist ist und gleichzeitig die Last sinkt.
Der gemeinsame Nenner ist Topologie. Datentransferkosten sind fast immer die Quittung dafür, wo Komponenten zueinander stehen. Wer eng kommunizierende Teile in derselben AZ hält und weiß, welcher Verkehr Zonen oder Regionen kreuzt, hat den größten Teil des Problems schon gelöst.
S3 ohne Lifecycle
S3-Buckets füllen sich mit Daten, die irgendwann niemand mehr anfasst. Logs, alte Exports, Backups von Systemen, die längst abgeschaltet sind. Alles liegt in S3 Standard, der teuersten Klasse, und niemand räumt auf.
Wenn das Zugriffsmuster bekannt ist, gehört eine Lifecycle-Policy auf den Bucket: Übergang nach Standard-IA, dann in eine Glacier-Klasse, am Ende Löschung, sofern die Aufbewahrungsfrist es erlaubt. Hier lauert allerdings eine Falle, die den naiven Wechsel teurer machen kann als das Original. Standard-IA rechnet jedes Objekt mit mindestens 128 Kilobyte und mindestens 30 Tagen Speicherdauer ab, plus eine kleine Gebühr pro Übergang. Bei einem Bucket voller winziger Objekte kostet die Verschiebung nach IA am Ende mehr, nicht weniger. Wenn das Zugriffsmuster unbekannt oder unregelmäßig ist, ist Intelligent-Tiering der bessere Default: Es verschiebt Objekte automatisch und verlangt keine Retrieval-Gebühren.
CloudWatch, das Volumenproblem
Die Retention habe ich oben als Scheinhebel entlarvt. Der echte Hebel bei den Logging-Kosten ist das Volumen: was überhaupt geloggt wird, in welcher Granularität.
Der häufigste Einzelposten ist Debug-Logging, das beim Deployment versehentlich in Produktion aktiv blieb und seitdem jede Anfrage protokolliert. Daneben gibt es Logs, die AWS selbst erzeugt und die niemand je liest, allen voran VPC Flow Logs mit voller Granularität auf Subnetzen, die kaum jemand auswertet. Beides treibt die Ingestion, beides taucht nirgends als bewusste Entscheidung auf. Wer hier sparen will, senkt nicht die Aufbewahrung, sondern die Menge an der Quelle.
Dev und Stage, die rund um die Uhr laufen
Nicht-produktive Umgebungen laufen erstaunlich oft 24 Stunden am Tag, sieben Tage die Woche, exakt wie Produktion. Die Rechnung dahinter ist simpel und lohnt sich, einmal sichtbar gemacht zu werden. Eine Woche hat 168 Stunden. Genutzt wird eine Nicht-Prod-Umgebung vielleicht von 8 bis 18 Uhr an Werktagen, also rund 50 Stunden. Wer sie außerhalb dieser Zeit herunterfährt, zahlt die laufzeitabhängigen Kosten für 50 statt 168 Stunden. Das sind rund 70 Prozent weniger, ohne dass irgendjemand etwas anders macht als vorher.
Ein Scheduler, der EC2-Instanzen, Auto Scaling Groups und stoppbare RDS-Instanzen abends herunter- und morgens wieder hochfährt, kostet wenige Stunden Arbeit. Bei RDS ist die Sieben-Tage-Grenze zu beachten, nach der eine gestoppte Instanz automatisch wieder startet; hier passt eine pausierbare Aurora-Serverless-Konfiguration oft besser. Die Einsparung läuft danach jeden Monat von allein.
Überdimensionierte Instanzklassen
Instanzen werden bei der ersten Einrichtung großzügig gewählt, weil niemand zu Beginn weiß, was der Workload wirklich braucht. Das ist vernünftig. Was fehlt, ist der zweite Blick, Monate später, wenn die echten Metriken vorliegen.
Compute Optimizer und die CloudWatch-Metriken zeigen schnell, welche Instanzen dauerhaft bei 10 Prozent CPU laufen. Eine Stufe kleiner, oder ein Wechsel auf eine modernere Generation, senkt die Rechnung sofort. Graviton-basierte Instanzen sind hier oft die größte einzelne Verbesserung, sofern der Workload ARM unterstützt.
Verwaiste Ressourcen
Der Klassiker zum Schluss, weil er in fast jedem gewachsenen Konto auftaucht: Ressourcen, die niemand mehr braucht und für die trotzdem jeden Monat bezahlt wird. EBS-Volumes, die nach dem Löschen einer Instanz nicht mehr angehängt sind, laufen als Storage weiter, ohne dass irgendetwas darauf zugreift. EBS-Snapshots sammeln sich über Jahre, automatisiert erstellt, nie aufgeräumt. Nicht genutzte Elastic IPs werden stundenweise berechnet, seit 2024 ohnehin alle öffentlichen IPv4-Adressen. Dazu Load Balancer ohne Targets und alte AMIs samt der Snapshots dahinter. Einzeln Centbeträge, in der Summe ein stiller Posten, der nur wächst. Ein Skript, das verwaiste Ressourcen regelmäßig meldet, findet das in Minuten.
Das ist Architektur, kein Couponing
Auffällig an dieser Liste ist, was nicht darauf steht: Reserved Instances und Savings Plans.
Beide haben ihren Platz, aber sie sind die zweite Maßnahme, nicht die erste. Ein Savings Plan senkt den Preis pro Einheit. Er senkt nicht die Menge. Wer sich auf einen Verbrauch festlegt, der zu 30 Prozent aus Verschwendung besteht, friert diese Verschwendung für ein bis drei Jahre ein und bekommt einen Rabatt darauf. Das fühlt sich nach Sparen an und ist trotzdem die teurere Variante.
Die Reihenfolge ist deshalb klar: erst die Nutzung bereinigen, dann die bereinigte Grundlast mit Commitments absichern. Wer umgekehrt vorgeht, optimiert den Preis eines Problems, statt das Problem zu lösen.
Genau hier liegt der Punkt, der FinOps von reiner Kostenjagd unterscheidet. Die Stellen aus der Liste oben sind keine Tarif-Fragen, sondern Architektur- und Lifecycle-Entscheidungen. Und sie haben einen angenehmen Nebeneffekt: Fast alle lassen sich beheben, ohne eine einzige produktive Zeile Code anzufassen. Ein VPC Endpoint, eine Lifecycle-Policy, ein Scheduler, eine geänderte Task-Definition. Das ist Infrastruktur, nicht Applikationslogik. Ich habe Teams dabei begleitet, auf diesem Weg vier- bis fünfstellige Beträge monatlich einzusparen, ohne dass sich an der Funktion ihrer Systeme etwas geändert hat.
Wann sich das nicht lohnt
Weil sonst der Eindruck entsteht, hier sei jeder Fix immer richtig: Das ist er nicht.
FinOps lohnt sich, wenn die wiederkehrende Ersparnis die einmaligen Kosten fürs Finden und Beheben klar übersteigt, inklusive der Pflege des Fixes danach. Unterhalb dieser Linie lässt man es. Bei einem kleinen Konto, in der Phase vor dem Product-Market-Fit, oder wenn die Entwicklerstunde teurer ist als der Posten, den sie einspart, ist Kostenoptimierung selbst die Verschwendung. Dasselbe gilt, wenn ein Fix Komplexität oder Betriebsrisiko einführt, das in keinem Verhältnis zur Ersparnis steht, oder wenn das fragliche System ohnehin in einem Quartal neu gebaut wird. Dann optimiert man etwas, das bald verschwindet.
Die ehrliche Antwort ist also nicht „immer sparen“, sondern „wissen, wo die Linie liegt“. Die meisten reifen Setups liegen deutlich darüber. Aber die Frage gehört gestellt, bevor man anfängt.
Geben Sie den Kosten ein Dashboard
Der Titel dieses Textes ist auch die Lösung. Architekturkosten haben kein Dashboard, also gibt man ihnen eins.
Der erste Schritt sind Cost Allocation Tags, konsequent genutzt. Ohne Tags ist eine AWS-Rechnung eine Summe pro Service über das gesamte Konto. Mit Tags nach Team, Umgebung und Service wird sichtbar, wo das Geld hingeht. Allein die Aufschlüsselung nach Umgebung deckt die 24/7-Stage-Systeme sofort auf. Wer es genauer braucht, aktiviert den Cost and Usage Report und wertet ihn mit Athena aus. Damit lassen sich Fragen beantworten, die der Cost Explorer nicht beantwortet, etwa wie viel NAT-Datenverarbeitung auf S3-Traffic entfällt oder welche Log-Gruppen die Ingestion treiben.
Der zweite Schritt ist, das laufend zu halten. Cost Anomaly Detection fängt neue Ausreißer ab, bevor sie acht Monate lang laufen. Und das Wirksamste kostet gar nichts: die Kosten als feste Größe in den Architecture-Review aufnehmen, gleichberechtigt neben Latenz und Fehlerquote. Eine einmalige Aufräumaktion bringt Sie auf eine saubere Grundlinie. Die Praxis hält Sie dort.
Schlechte Architektur schickt keine Alerts. Sie kostet einfach weiter, leise, jeden Monat, bis jemand entscheidet, hinzuschauen. Anders als technische Schulden im Applikationscode sind die meisten dieser Probleme Infrastrukturentscheidungen mit klarem, lokalem Fix und ohne Auswirkung auf die Funktion. Das macht FinOps zu einer der wenigen Optimierungen mit hoher Wirkung und niedrigem Risiko.
Bleibt die einzige offene Frage, und sie ist keine technische: Wann haben Sie zuletzt einen Architecture-Review gemacht, nicht aus Pflicht, sondern weil Sie wissen wollten, was wirklich läuft?
Der beste Zeitpunkt dafür war vor zwei Jahren. Der zweitbeste ist jetzt.
