AWS-Kosten: die häufigsten Geldgräber und wie man sie findet

Die AWS-Rechnung wächst selten, weil jemand eine teure Fehlentscheidung trifft. Sie wächst, weil ein Dutzend kleiner Lecks niemandem gehört. Ein NAT Gateway hier, ein vergessenes Volume da, eine Flotte auf On-Demand, die seit zwei Jahren dieselbe Last fährt. Jedes einzelne Leck ist zu klein, um aufzufallen. Zusammen sind sie der Grund, warum die Rechnung jeden Monat ein Stück höher ist.

FinOps ist keine Software, die man kauft, sondern eine Gewohnheit, die man etabliert. Die nativen AWS-Werkzeuge reichen für den Anfang völlig. Dieser Artikel ist die Landkarte der häufigsten Geldgräber, mit konkreten Fundstellen und einer Checkliste, die ein Team direkt durchgehen kann. Gedacht für den Mittelstand, der ein bis drei Accounts fährt, nicht für eine Hyperscaler-FinOps-Abteilung.

Was er nicht ist: eine Anleitung, jede letzte Nachkommastelle zu jagen. Drei bis vier Kategorien machen meist den Großteil der Ersparnis aus, der Rest ist Feinarbeit. Alle Pricing-Werte sind Stand Juni 2026 für us-east-1, eu-central-1 weicht leicht ab. Für die eigene Region gilt immer der AWS Pricing Calculator.

Der NAT Gateway, der stille Klassiker

Der NAT Gateway ist der Posten, der in fast jedem Audit auftaucht. Er kostet rund 0,045 USD pro Stunde, allein fürs Bereitstehen, also etwa 33 USD pro Monat pro Gateway. Dazu kommen 0,045 USD pro verarbeitetem GB, und obendrauf noch die normalen Data-Transfer-Kosten. Bei einem Multi-AZ-Setup mit einem Gateway pro Availability Zone ist man schnell bei drei Gateways, bevor irgendein Byte geflossen ist.

Der häufigste vermeidbare Fehler: Traffic zu S3 und DynamoDB läuft über den NAT, obwohl ein Gateway-VPC-Endpoint genau dafür gratis ist. Kein Stundenpreis, keine Datengebühr. Ein Gateway-Endpoint für S3 ist ein paar Zeilen Terraform und nimmt den vielleicht größten Brocken aus der NAT-Datengebühr:

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-central-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Für andere AWS-Services gibt es Interface-Endpoints über PrivateLink. Die kosten zwar eine Stunden- und Datengebühr, sparen aber die NAT-Datengebühr für chatty Service-Calls, etwa zu ECR, Secrets Manager oder den ganzen Pull-Traffic eines Container-Deployments. Seit Ende 2025 gibt es zusätzlich den Regional NAT Gateway, der pro AZ pro Stunde abgerechnet wird und die Rechnung für manche Multi-AZ-Topologien verschiebt.

Wo man hinschaut: Im Cost Explorer nach dem Usage Type filtern, der "NatGateway-Bytes" enthält. Wer wissen will, welche Workloads den NAT volllaufen lassen, nimmt die VPC Flow Logs und sucht die Top-Talker.

Idle und verwaiste Ressourcen

Nicht angehängte Volumes und alte Snapshots

Ein EBS-Volume läuft weiter, auch wenn die EC2-Instance, an der es hing, längst gelöscht ist. 100 GB gp3 sind rund 8 USD pro Monat, die niemand mehr nutzt. In einem Account, der ein paar Jahre gewachsen ist, finden sich davon oft Dutzende. Der Sweep dauert eine Minute:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}" \
  --output table

status=available heißt: an nichts angehängt. Jedes Volume in dieser Liste ist ein Kandidat zum Löschen, nach einem Snapshot zur Sicherheit. Apropos Snapshots: die sind inkrementell, aber sie häufen sich. Ohne eine Lifecycle-Policy über den Data Lifecycle Manager wächst der Snapshot-Berg endlos, weil jeder ihn anlegt und keiner aufräumt.

Load Balancer, Elastic IPs und der IPv4-Preis

Ein Application Load Balancer ohne registrierte Targets kostet trotzdem die Stundengebühr plus seine LCU. Ein Relikt aus einem abgeschalteten Projekt, das niemand bemerkt. Dasselbe gilt für Elastic IPs, und hier hat sich die Rechnung verschärft: Seit dem 1. Februar 2024 kostet jede öffentliche IPv4-Adresse 0,005 USD pro Stunde, rund 3,60 USD pro Monat. Und zwar nicht nur die ungenutzten, sondern jede, auch die an einer laufenden Instance. Bei einer größeren Flotte ist das ein realer Posten. Ungenutzte EIPs findet man so:

aws ec2 describe-addresses \
  --query "Addresses[?AssociationId==null].{IP:PublicIp,AllocationId:AllocationId}" \
  --output table

Dev-Umgebungen rund um die Uhr

Der größte versteckte Posten im Mittelstand sind Dev- und Staging-Umgebungen, die 24/7 laufen, obwohl sie nur zur Arbeitszeit jemand anfasst. Eine Nicht-Produktions-Flotte, die abends und am Wochenende schläft, läuft grob 50 von 168 Wochenstunden. Das ist eine Ersparnis von rund zwei Dritteln auf diesen Teil der Rechnung, mit einem simplen Scheduler, der die Instances und RDS-Datenbanken nachts herunterfährt. Niemand braucht eine Staging-Datenbank um drei Uhr morgens.

Right-Sizing, der größte Hebel

Right-Sizing ist der größte Hebel und gleichzeitig der unbequemste, weil er Disziplin verlangt statt eines einmaligen Klicks. Das Muster ist überall gleich: Instances werden bei der Einführung großzügig dimensioniert und danach nie wieder angefasst. Eine m5.xlarge, die seit einem Jahr bei 8 Prozent CPU dümpelt, verbrennt jeden Monat Geld, ohne dass es jemand sieht.

Cost Optimization Hub und Compute Optimizer

AWS liefert die Analyse frei Haus. Der Compute Optimizer wertet die tatsächliche Auslastung von EC2, RDS und Lambda aus und schlägt kleinere oder modernere Instances vor. Der Cost Optimization Hub bündelt diese Empfehlungen über alle Accounts und Regionen in einer Sicht, mit 18 Recommendation-Typen, darunter Right-Sizing, Idle-Detection, Graviton-Migration sowie Savings-Plans- und RI-Vorschläge. Den Lookback kann man auf 14, 32 oder 93 Tage stellen. Ich nehme die 93 Tage, weil ein kurzes Fenster jede saisonale Spitze verschluckt.

Die Vorsicht dabei: Right-Sizing braucht echte Lookback-Daten und Headroom für Lastspitzen, nicht den Mittelwert eines ruhigen Wochenendes. Wer auf den Durchschnitt optimiert, produziert den nächsten Incident.

Graviton-Migration

Der unterschätzte Teil der Empfehlungen ist die Migration auf Graviton. Die ARM-basierten Instances sind je nach Familie 20 bis 25 Prozent günstiger bei gleicher oder besserer Leistung, die neueren Graviton4-Familien liefern noch mehr Preis-Leistung. Für PHP, Node und die meisten Web-Workloads ist der Wechsel unkritisch, es ist im Wesentlichen ein Image-Rebuild für ARM. Wer ohnehin auf Fargate ist, stellt die Architektur in der Task-Definition um und baut das Image für ARM, fertig.

Steady-State auf On-Demand

On-Demand ist für variable und unvorhersagbare Last die richtige Wahl. Für eine Baseline, die seit Monaten stabil läuft, ist es die teuerste Option, die AWS anbietet. Wer eine konstante Grundlast komplett auf On-Demand fährt, verschenkt je nach Commit zwischen 30 und 70 Prozent.

Savings Plans richtig schichten

Compute Savings Plans sind der flexible Default. Man bindet einen Stunden-Commit, etwa 10 USD pro Stunde, und bekommt dafür einen Rabatt, der über Region, Instance-Familie, Größe, Betriebssystem und sogar Fargate und Lambda hinweg gilt. Diese Flexibilität ist der Grund, warum ich sie den starreren EC2 Instance Savings Plans und Reserved Instances vorziehe, auch wenn die einen etwas höheren Rabatt bieten. RIs lohnen sich nur für wirklich fixe Workloads, die sich garantiert nicht ändern.

Die Faustregel ist einfach und wichtig: die stabile Baseline mit Savings Plans abdecken, die Spitze auf On-Demand laufen lassen. Nie 100 Prozent committen. Wer seine gesamte Kapazität bindet, bestraft jede Laständerung und jeden Architektur-Umbau, weil der Commit weiterläuft, egal was passiert. Siebzig bis achtzig Prozent der Baseline ist ein gesunder Wert.

Spot für Unterbrechbares

Für unterbrechbare Workloads ist Spot bis zu 70 Prozent günstiger als On-Demand. Das passt perfekt zu den Queue-Workern aus dem Fargate-Artikel, zu Batch-Jobs und zu CI-Runnern. Wichtig ist nur, dass die Workloads eine Unterbrechung vertragen, also idempotent sind und ihre Arbeit nach einem Abbruch wieder aufnehmen können. Den Web-Service mit Nutzer-Traffic lässt man auf On-Demand oder Savings Plans.

Storage-Verschwendung

gp2 statt gp3

Das nächstliegende Geschenk in fast jedem Account: gp2-Volumes, die noch auf gp2 laufen. gp3 kostet 0,08 statt 0,10 USD pro GB-Monat, das sind 20 Prozent weniger, und bringt 3000 IOPS und 125 MB/s Durchsatz gratis mit, also oft mehr Leistung als das alte gp2. Die Migration läuft ohne Downtime, AWS modifiziert das Volume im laufenden Betrieb:

aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3

Die gp2-Kandidaten findet man mit demselben describe-volumes, gefiltert auf volume-type=gp2. Es gibt selten einen Grund, das nicht sofort zu machen.

S3 ohne Lifecycle

Daten, die niemand mehr liest, liegen oft auf S3 Standard und kosten den vollen Preis. Lifecycle-Regeln verschieben sie automatisch nach Infrequent Access und später nach Glacier, oder man nutzt S3 Intelligent-Tiering, das die Klasse anhand des Zugriffsmusters selbst wählt. Ein stiller Posten, den fast jeder hat, sind abgebrochene Multipart-Uploads: Fragmente, die nie zu Ende geladen wurden, nie aufgeräumt werden und trotzdem Speicher kosten. Eine Lifecycle-Regel räumt beides:

{
  "Rules": [
    {
      "ID": "tiering-and-cleanup",
      "Status": "Enabled",
      "Filter": {},
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Data Transfer, der unsichtbare Posten

Data Transfer ist der Posten, den fast niemand im Blick hat, weil er in keiner Architektur-Diskussion auftaucht. Der Internet-Egress ist gestaffelt: die ersten 100 GB pro Monat sind frei, aggregiert über alle Services, danach kostet das nächste Terabyte-Paket 0,09 USD pro GB und fällt mit dem Volumen.

Der interessantere Posten ist der interne Traffic. Inter-AZ-Traffic kostet 0,01 USD pro GB, und zwar pro Richtung. Eine geschwätzige Multi-AZ-App, deren Services über Availability Zones hinweg ständig miteinander reden, zahlt das in beide Richtungen. Das klingt nach wenig, summiert sich bei datenintensiven Workloads aber zu einem überraschend großen Block. Cross-Region-Replikation, oft aus Bequemlichkeit eingeschaltet, ist noch teurer. Und der NAT-Egress ist ein Doppelschlag: Traffic über den NAT zahlt die NAT-Datengebühr plus die Egress-Gebühr.

Wo man hinschaut: im Cost Explorer nach Usage Type gruppieren und nach den Posten suchen, die "DataTransfer" enthalten. Die Zahlen sind oft höher als erwartet, gerade bei Apps mit viel interner Kommunikation.

Observability, die sich selbst frisst

Observability kostet, und ab einem gewissen Punkt frisst sie sich selbst. CloudWatch berechnet die Ingestion und die Speicherung von Logs, und Debug-Logs in Produktion mit unbegrenzter Retention sind ein stiller Dauerposten. Jede Custom Metric kostet ebenfalls, und eine ausufernde Metrik-Strategie summiert sich schneller, als man denkt.

Die richtige Balance ist genug Observability, um Incidents zu sehen, aber nicht so viel, dass die Beobachtung teurer wird als das Beobachtete. Eine vernünftige Log-Retention, Debug-Level nur temporär, und ein Blick auf die Zahl der Custom Metrics reichen meist. Dieser Punkt bekommt im kommenden Artikel zu Observability in Produktion mehr Raum.

Tagging, die wichtigste unspektakuläre Maßnahme

Man kann nicht optimieren, was man nicht zuordnen kann. Ohne konsequente Cost-Allocation-Tags ist jede Optimierung Raten, weil die Rechnung eine einzige große Zahl bleibt, statt sich nach Team, Projekt und Umgebung aufzuschlüsseln. Tagging ist die langweiligste Maßnahme in diesem Artikel und die wichtigste.

Praktisch heißt das: Cost-Allocation-Tags in der Billing-Konsole aktivieren, eine schlanke Tag-Policy festlegen (Environment, Team, Project, Owner reichen für den Anfang) und das Tagging per Tag Policy oder Service Control Policy erzwingen, damit niemand untaggte Ressourcen anlegt. Erst danach zeigen Cost Explorer und Budgets die Kosten pro Team, und aus der Sammelrechnung wird eine handhabbare Sicht.

Der eigentliche Punkt ist organisatorisch, nicht technisch: Ein Geldgrab ohne Owner wird nie gestopft. Tagging schafft Verantwortung, nicht nur ein Reporting. Wenn ein Team seine eigenen Kosten sieht, ändert sich das Verhalten von allein.

Die Audit-Checkliste

Die folgende Checkliste deckt die acht Kategorien ab. Ein Team kann sie an einem Nachmittag durchgehen und hat danach eine Liste konkreter Maßnahmen, nach Aufwand sortiert.

Das ist die freie Variante. Die ausführliche Version gibt es als AWS Cost-Optimization Audit Kit: die Checkliste als PDF mit 60-Minuten-Anleitung plus Spreadsheet-Kalkulator, der pro Kategorie die konkrete Ersparnis hochrechnet.

So läuft ein Audit ab

Die Reihenfolge macht den Unterschied zwischen einem Audit und einem Stochern. Zuerst der Cost Explorer für den Überblick, wo das Geld überhaupt hingeht. Dann der Cost Optimization Hub für die quantifizierten Empfehlungen. Dann die Tags, um die Kosten zuzuordnen. Dann die CLI-Sweeps für die verwaisten Ressourcen, die in keiner Empfehlung auftauchen. Und erst danach wird nach Impact und Aufwand priorisiert.

Die Quick Wins zuerst: gp2 zu gp3, ungenutzte Elastic IPs, idle Load Balancer, verwaiste Volumes. Wenig Aufwand, sofortige Wirkung, und sie schaffen das Vertrauen für die größeren Schritte. Die dicken Bretter danach: Right-Sizing, die Savings-Plans-Strategie, die NAT-Architektur. Mehr Aufwand, aber auch der größere Teil der Ersparnis.

Eine Sache noch, die regelmäßig schiefgeht: Einmal aufräumen reicht nicht. Die Rechnung wächst sofort weiter, sobald das nächste Team eine Instance vergisst. Ein Quartals-Review hält sie sauber, und mit Tags und aktiviertem Cost Optimization Hub dauert er beim zweiten Mal nur noch einen Bruchteil.

Was die Geschäftsführung fragen sollte

Man muss kein AWS-Architekt sein, um die richtigen Fragen zu stellen. Drei reichen, um zu erkennen, ob die Kosten überhaupt gemanagt werden. Wie viel Prozent unserer Compute-Rechnung ist durch Savings Plans abgedeckt? Wann lief das letzte Right-Sizing? Haben wir Tags, die uns die Kosten pro Team zeigen? Wenn die Antworten "weiß nicht", "noch nie" und "nein" lauten, liegt die Ersparnis fast garantiert im zweistelligen Prozentbereich.

Das 80/20 gilt auch hier. Drei bis vier Kategorien machen meist den Großteil aus, und es lohnt sich nicht, das Team wochenlang die letzten Prozente jagen zu lassen. Wann jemand von außen sinnvoll ist, hängt an zwei Dingen: ob intern jemand die Zeit und das FinOps-Wissen hat, und wie groß die Rechnung ist. Bei einer fünfstelligen Monatsrechnung zahlt sich ein gezielter Audit in der Regel um ein Vielfaches zurück, einfach weil die gefundenen Posten Monat für Monat weiterlaufen würden.

Anti-Patterns

Optimieren ohne Tags. Raten statt Messen. Ohne Zuordnung weiß niemand, welcher Posten zu welchem Team gehört, und nichts wird je gestopft.

100 Prozent auf Savings Plans committen. Nimmt die Flexibilität und bestraft jede Laständerung. Die Spitze gehört auf On-Demand und Spot.

Right-Sizing auf den Mittelwert. Ignoriert Lastspitzen und produziert den nächsten Incident. Immer mit Headroom.

Einmal aufräumen und nie wieder. Die Rechnung wächst sofort weiter. FinOps ist ein Quartals-Rhythmus, kein Projekt.

Dev-Umgebungen 24/7. Der größte vermeidbare Posten im Mittelstand. Ein Scheduler spart hier grob zwei Drittel.

NAT für S3-Traffic. Bezahlt pro GB, was über einen Gateway-Endpoint gratis wäre.

Kosten-Tooling kaufen, bevor die Hausaufgaben gemacht sind. Die nativen AWS-Werkzeuge reichen für den Anfang. Ein Drittanbieter-Tool lohnt sich erst, wenn Tagging und Basis-Disziplin stehen.

Fazit

Die AWS-Rechnung ist kein Schicksal, sondern die Summe vieler kleiner, behebbarer Entscheidungen. Die meisten Geldgräber in diesem Artikel sind in einem Nachmittag findbar und in einer Woche zur Hälfte gestopft. Der NAT, der unnötig S3-Traffic schluckt, die Flotte ohne Savings Plans, die gp2-Volumes, die verwaisten Ressourcen: alles konkret, alles messbar, alles behebbar.

Was bleibt, ist die Gewohnheit. Tags, damit man sieht, wohin das Geld fließt. Ein Quartals-Review, damit die Rechnung nicht wieder davonläuft. Savings Plans auf der Baseline, damit die Grundlast nicht zum vollen Preis läuft. Das ist weniger Arbeit, als die meisten denken, und es ist der Unterschied zwischen einer Rechnung, die man versteht, und einer, die einfach jeden Monat höher wird.

Wächst Ihre AWS-Rechnung schneller als Ihre Last, und niemand hat die Zeit, dem nachzugehen? Kontaktieren Sie mich für einen technischen FinOps-Audit, der die Geldgräber in zwei bis drei Tagen findet und nach Aufwand und Wirkung priorisiert.

Die Self-Service-Variante gibt es fertig zum Download: das AWS Cost-Optimization Audit Kit mit Checkliste, 60-Minuten-Anleitung und Spreadsheet-Kalkulator — kostenlos, direkt über das Formular unter diesem Artikel oder auf der Ressourcen-Seite.