AWS Cloud-Kosten reduzieren: 15 Tipps für niedrigere AWS-Kosten

Wer Amazon Web Services nutzt, kennt das Problem: Die Cloud lässt sich schnell skalieren – die Kosten skalieren allerdings genauso schnell mit.

Ein Entwickler benötigt kurzfristig einen leistungsfähigen Server. Eine Testumgebung wird aufgebaut. Für ein Projekt entsteht ein Kubernetes-Cluster. Eine Datenbank wird vorsichtshalber größer dimensioniert. Vor einem Update wird noch schnell ein Snapshot erstellt. Monate später ist das Projekt längst beendet, doch Teile der Infrastruktur existieren weiterhin.

AWS berechnet zuverlässig weiter.

Das Problem liegt deshalb häufig nicht darin, dass einzelne AWS-Services grundsätzlich zu teuer sind. Viel häufiger bezahlen Unternehmen für Ressourcen, die zu groß dimensioniert sind, nicht mehr benötigt werden oder rund um die Uhr laufen, obwohl sie nur wenige Stunden pro Tag genutzt werden.

Genau deshalb sollte die Reduktion von AWS Cloud-Kosten nicht mit pauschalen Sparvorgaben beginnen. Sinnvoller ist ein strukturierter Cloud-Cost-Audit. Die zentrale Frage lautet: Welche AWS-Ressourcen bezahlen wir – und welchen wirtschaftlichen Nutzen erhalten wir dafür?

Die folgenden 15 Maßnahmen zeigen, wo Unternehmen besonders häufig Einsparpotenziale finden und wie sich AWS-Kosten reduzieren lassen, ohne Stabilität, Sicherheit oder Performance unnötig zu gefährden.

Warum AWS-Kosten häufig unbemerkt steigen

Die Stärke der Cloud ist gleichzeitig eine ihrer größten Kostenfallen. Neue Infrastruktur kann innerhalb weniger Minuten bereitgestellt werden. Dafür braucht es keine Bestellung eines physischen Servers, keine Installation in einem Rechenzentrum und häufig nicht einmal einen separaten Freigabeprozess.

Aus technischer Sicht ist das ein enormer Vorteil. Aus kaufmännischer Sicht entsteht jedoch ein Problem: Das Erstellen einer Ressource ist einfacher als das spätere Aufräumen.

So sammeln sich über Monate und Jahre sogenannte Cloud-Kostenleichen an. Dazu gehören beispielsweise nicht mehr benötigte Load Balancer, alte Snapshots, ungenutzte NAT Gateways, verwaiste VPC Endpoints oder leere Kubernetes-Cluster.

Daneben existiert eine zweite große Kostenkategorie: Overprovisioning. Viele Systeme werden bewusst mit Sicherheitsreserven dimensioniert. Das ist bei der Einführung einer Anwendung durchaus nachvollziehbar. Problematisch wird es erst, wenn nach sechs oder zwölf Monaten niemand mehr überprüft, ob diese Reserve tatsächlich benötigt wird.

Wer AWS-Kosten nachhaltig reduzieren möchte, sollte deshalb regelmäßig vier Fragen beantworten:

• Welche Ressourcen sind überdimensioniert?
• Welche Ressourcen werden gar nicht mehr benötigt?
• Welche Ressourcen müssen wirklich rund um die Uhr laufen?
• Für welche planbare Nutzung bezahlen wir noch den On-Demand-Preis?

Damit kommen wir zu den 15 wichtigsten Maßnahmen.

1. EC2-Instanzen verkleinern und Rightsizing konsequent nutzen

Amazon EC2 gehört bei vielen Unternehmen zu den größten AWS-Kostenblöcken. Gleichzeitig liegt hier häufig erhebliches Einsparpotenzial.

Das typische Problem: Eine Anwendung erhält zum Start beispielsweise acht vCPUs und 32 GB RAM, weil das Entwicklungsteam ausreichend Reserven einplanen möchte. In der Realität liegt die CPU-Auslastung anschließend über Monate bei einem Bruchteil der vorhandenen Kapazität.

Das Unternehmen bezahlt bildlich gesprochen für einen Ferrari und fährt damit dauerhaft 30 km/h.

AWS Compute Optimizer kann EC2-Ressourcen analysieren und Empfehlungen für passendere Instance-Typen aussprechen. Für eine seriöse Bewertung sollte allerdings nicht nur die durchschnittliche CPU-Auslastung betrachtet werden. Entscheidend sind insbesondere Spitzenlasten, Arbeitsspeicher, Netzwerk, Disk-I/O und zyklische Lastverläufe.

Als Prüfzeitraum sind mindestens rund 30 Tage sinnvoll. Bei saisonalen oder monatlich schwankenden Workloads sollte die Analyse länger laufen. Besonders wichtig ist die maximale CPU-Auslastung: Wird die Anzahl der CPUs halbiert, kann sich die prozentuale CPU-Auslastung grob verdoppeln. Eine Instanz mit bislang 20 Prozent Peak kann nach dem Downsizing also immer noch ausreichend Reserven besitzen.

Ein sinnvoller Ansatz kann beispielsweise sein:

• 8 vCPU / 32 GB RAM
• auf 4 vCPU / 32 GB RAM reduzieren,
• sofern CPU-Kapazität offensichtlich nicht benötigt wird, der Speicherbedarf aber bestehen bleibt.

Nach jeder Änderung sollten Performance, Latenz, Fehlerquoten und Spitzenlast überwacht werden. Rightsizing ist kein einmaliges Projekt. Lastprofile ändern sich, Anwendungen wachsen oder verlieren Nutzer, und neue Instance-Generationen können bessere Preis-Leistungs-Verhältnisse bieten.

Für einen Kosten-Audit sollte deshalb zunächst geprüft werden, welche Instanzen der Compute Optimizer als overprovisioned einstuft. Anschließend werden CloudWatch-Metriken und der technische Owner herangezogen. Das Ziel lautet nicht, die kleinstmögliche Instanz zu wählen, sondern die günstigste Instanz, die den erforderlichen Leistungsrahmen zuverlässig erfüllt.

2. Zu viele NAT Gateways konsolidieren

NAT Gateways ermöglichen Systemen in privaten Subnetzen den Zugang zu externen Diensten, ohne diese Systeme selbst direkt aus dem Internet erreichbar zu machen.

In produktiven Systemen kann es sinnvoll sein, mehrere NAT Gateways über verschiedene Availability Zones zu betreiben. Dadurch lässt sich die Ausfallsicherheit erhöhen. Die gleiche Architektur wird allerdings häufig ungeprüft auf Development-, Test- oder Staging-Umgebungen übertragen.

So entstehen beispielsweise drei NAT Gateways für eine Entwicklungsumgebung, obwohl diese Umgebung überhaupt keine Multi-AZ-Hochverfügbarkeit benötigt. Das Problem: NAT Gateways verursachen sowohl zeitabhängige Kosten als auch Kosten für verarbeitete Daten.

Im ersten Schritt sollte deshalb im AWS Cost Explorer untersucht werden, welche Accounts besonders hohe NAT-Gateway-Kosten beziehungsweise Running Hours verursachen. Anschließend sollte gemeinsam mit DevOps geklärt werden: Benötigt diese Umgebung wirklich mehrere NAT Gateways?

Bei unkritischen Non-Production-Systemen kann möglicherweise aus einer Architektur mit drei NAT Gateways eine Architektur mit nur einem Gateway werden. Besonders auffällig sind mehrere Gateways innerhalb derselben Availability Zone. Diese verursachen zusätzliche Fixkosten, ohne automatisch einen entsprechenden Hochverfügbarkeitsvorteil zu erzeugen.

Wichtig ist die Risikoabwägung. Produktionssysteme mit harten Verfügbarkeitsanforderungen sollten nicht aus reinem Kostendruck in eine Single-Point-of-Failure-Architektur gedrängt werden. Für Dev, Test oder kurzlebige Staging-Systeme kann die Situation dagegen völlig anders aussehen.

Eine gute FinOps-Regel lautet deshalb: Hochverfügbarkeit muss zur Kritikalität des Workloads passen. Wer dieselbe Redundanz für alle Umgebungen baut, zahlt häufig unnötig für Ausfallsicherheit, die geschäftlich gar nicht benötigt wird.

3. Ungenutzte NAT Gateways vollständig löschen

Noch interessanter als die Konsolidierung aktiver NAT Gateways sind NAT Gateways, die überhaupt nicht mehr genutzt werden.

Typischer Ablauf: Eine Anwendung wird entwickelt. Für die Anwendung wird ein NAT Gateway eingerichtet. Das Projekt wird eingestellt. Die Anwendung und verschiedene Compute-Ressourcen werden gelöscht. Das NAT Gateway bleibt bestehen. AWS berechnet die Ressource weiterhin.

Zur Prüfung kann in Amazon CloudWatch beispielsweise die Metrik BytesOutToDestination über einen längeren Zeitraum analysiert werden. Praktisch kein Datenverkehr über mehrere Wochen ist ein deutliches Warnsignal.

Das bedeutet allerdings nicht, dass ein Gateway sofort gelöscht werden sollte. Vielleicht wird es für einen monatlichen Prozess, eine selten ausgeführte Integration oder als bewusst vorgehaltene Infrastruktur benötigt.

Deshalb gilt eine klare Reihenfolge:

• Nutzung und Traffic prüfen.
• Owner identifizieren.
• Geschäftlichen oder technischen Zweck bestätigen.
• Abhängigkeiten prüfen.
• Erst anschließend löschen.

Wird ein NAT Gateway entfernt, sollte außerdem geprüft werden, ob die damit verbundene Elastic IP weiterhin benötigt wird. Häufig zeigt sich bei der Analyse einer vergessenen Ressource, dass mehrere weitere Kostenpositionen am gleichen Altprojekt hängen.

Für größere AWS-Landschaften lohnt es sich, diese Prüfung zu automatisieren. Ein regelmäßiger Report über NAT Gateways mit minimalem Traffic, fehlendem Owner-Tag oder ungewöhnlich langer Laufzeit kann die Suche nach Kostenleichen erheblich beschleunigen.

4. Alte und ungenutzte VPC Endpoints identifizieren

VPC Endpoints ermöglichen private Verbindungen zwischen einer VPC und unterstützten AWS-Services. Technisch sind sie häufig sinnvoll. Das bedeutet jedoch nicht, dass jeder einmal angelegte Endpoint dauerhaft benötigt wird.

Besonders Interface Endpoints können laufende Kosten verursachen. Bei Projekten, die über Jahre wachsen, entstehen dadurch schnell verwaiste Ressourcen.

Ein typischer Fall: Vor zwei Jahren wird eine Anwendung entwickelt. Dafür wird ein Interface Endpoint erstellt. Die Anwendung wird später abgeschaltet. Der Endpoint bleibt bestehen.

Im AWS VPC Dashboard sollte deshalb regelmäßig überprüft werden, welche Endpoints existieren, welchem Service sie zugeordnet sind und ob tatsächlich noch Traffic verarbeitet wird. CloudWatch-Metriken wie BytesProcessed können dabei helfen.

Wichtig ist allerdings ein Detail: Ein vollständig ungenutzter Endpoint kann unter Umständen keine aussagekräftigen aktuellen Trafficdaten mehr liefern. Deshalb sollten Inventar, technische Abhängigkeiten und historische Nutzung gemeinsam analysiert werden.

Ein sinnvoller Audit-Prozess besteht darin, alle Interface Endpoints zu exportieren und um Informationen zu Account, Region, VPC, Service, Owner, Projekt, Erstellungsdatum und beobachtetem Traffic zu ergänzen. Endpoints ohne klaren Owner und ohne erkennbare Nutzung werden anschließend mit den zuständigen Teams besprochen.

Auch hier gilt: nicht blind löschen. Erst Owner und technische Abhängigkeiten identifizieren. Gerade zentrale Sicherheits-, Logging- oder Management-Services können weniger offensichtlich genutzt werden als klassische Applikationskomponenten.

5. Alte RDS-Snapshots bereinigen

Snapshots sind sinnvoll. Vergessene Snapshots sind teuer.

Vor Datenbankänderungen oder Updates erstellen Teams häufig manuelle Amazon-RDS-Snapshots. Nach einem erfolgreichen Update wird die Sicherung irgendwann nicht mehr benötigt – aber niemand löscht sie.

Das Entscheidende: Manuelle RDS-Snapshots können dauerhaft bestehen bleiben. Über Jahre kann dadurch immer mehr Speicher aufgebaut werden.

Geprüft werden sollte unter AWS → RDS → Snapshots → Manual. Sortieren Sie nach Alter und Größe. Besonders interessant sind Snapshots, die mehrere Jahre alt sind, deren ursprüngliche Datenbank möglicherweise gar nicht mehr existiert und für die niemand mehr einen geschäftlichen oder technischen Zweck nennen kann.

Bevor gelöscht wird, müssen Compliance, gesetzliche Aufbewahrungspflichten, Disaster-Recovery-Anforderungen und interne Backup-Richtlinien berücksichtigt werden. Außerdem verursacht nicht automatisch jeder alte Snapshot zusätzliche Kosten. Bestimmte Backup-Kapazitäten können bereits Bestandteil des jeweiligen RDS-Modells sein. Deshalb sollte zuerst geprüft werden, welche tatsächlichen Backup-Kosten im AWS Cost Explorer entstehen.

Die richtige Regel lautet nicht „alte Snapshots löschen“, sondern „Snapshots ohne nachweisbaren Zweck löschen“.

Hilfreich ist eine definierte Retention Policy. Beispielsweise können manuelle Snapshots nach Kategorien wie kurzfristiges Change-Backup, Monatsbackup, Jahresbackup oder regulatorisches Backup klassifiziert werden. Jede Kategorie erhält einen Owner und eine maximale Aufbewahrungsdauer.

So wird aus sporadischem Aufräumen ein kontrollierter Prozess. Gleichzeitig sinkt das Risiko, versehentlich Backups zu entfernen, die für Recovery oder Compliance tatsächlich benötigt werden.

6. Leere EKS- und Kubernetes-Cluster löschen

Amazon Elastic Kubernetes Service, kurz EKS, ist für moderne Cloud-Architekturen enorm leistungsfähig. Gleichzeitig entstehen gerade in Kubernetes-Umgebungen häufig Infrastrukturreste.

Ein Entwickler baut für ein neues Projekt einen eigenen Cluster auf. Das Projekt endet. Anwendungen und Nodes werden entfernt. Der eigentliche EKS-Cluster bleibt jedoch bestehen.

Bei einem AWS-Kosten-Audit sollten deshalb sämtliche EKS-Cluster inventarisiert werden. Prüfen Sie unter anderem:

• Existieren Node Groups?
• Existieren Fargate Profiles?
• Existieren selbstverwaltete EC2-Nodes?
• Gibt es noch aktive Workloads?
• Gibt es einen dokumentierten Owner und Business Purpose?

Ein Cluster ohne relevante Compute-Ressourcen ist ein starkes Warnsignal.

Nach der Löschung des Clusters ist die Arbeit allerdings noch nicht beendet. Prüfen Sie auch zugehörige Load Balancer, IP-Adressen, Security Groups, Volumes und andere Storage-Ressourcen. Eine stillgelegte Entwicklungsumgebung hinterlässt häufig nicht eine einzige Kostenleiche, sondern gleich mehrere.

Zusätzlich lohnt es sich, Namespaces und Workloads innerhalb aktiver Cluster zu analysieren. Ein EKS-Cluster kann sinnvoll und produktiv sein, während einzelne alte Namespaces, persistent Volumes oder Load Balancer darin längst nicht mehr benötigt werden.

Für Unternehmen mit vielen Kubernetes-Teams ist deshalb eine Kombination aus FinOps und Plattform-Governance sinnvoll: standardisierte Tags oder Labels, automatische Lebensdauerregeln für temporäre Umgebungen und klare Verantwortlichkeiten pro Cluster und Namespace.

7. RDS-Datenbanken richtig dimensionieren

Was für EC2 gilt, gilt ebenfalls für Datenbanken.

Eine RDS-Instanz wird zu Beginn einer Anwendung häufig großzügig dimensioniert. Später stellt sich heraus, dass CPU und Arbeitsspeicher nur zu einem kleinen Teil ausgelastet sind. Bei Datenbanken können die finanziellen Auswirkungen besonders relevant sein.

Die Analyse sollte zunächst im AWS Cost Explorer beginnen: Welche Datenbanken verursachen die höchsten Kosten? Anschließend werden in CloudWatch unter anderem CPUUtilization und FreeableMemory untersucht.

Für Datenbanken empfiehlt sich ein längerer Analysezeitraum als bei vielen anderen Ressourcen. Quartalsabschlüsse, Monatsläufe, Reporting-Jobs oder saisonale Peaks dürfen nicht übersehen werden. Etwa 90 Tage sind häufig ein sinnvoller Ausgangspunkt.

Ist die CPU selbst bei Lastspitzen niedrig und gleichzeitig dauerhaft viel Arbeitsspeicher verfügbar, kann ein Downsizing der RDS Instance Class sinnvoll sein.

Dabei sollte deutlich konservativer vorgegangen werden als bei einem unwichtigen Development-Server. Zu berücksichtigen sind unter anderem Lastspitzen, Read Replicas, Multi-AZ-Konfigurationen, I/O, Storage-Typ, Connections und vorhandene Reserved Instances beziehungsweise andere Commitments.

Eine theoretisch günstigere Instance spart wenig, wenn dadurch bereits bezahlte Reservierungen ungenutzt bleiben. Ebenso darf ein Downsizing nicht dazu führen, dass Datenbanklatenz oder Failover-Zeiten unvertretbar steigen.

Ein guter Ansatz ist ein kontrollierter Change mit definierten Erfolgskriterien: CPU, FreeableMemory, Read/Write Latency, Database Connections und Applikationslatenz werden vor und nach der Änderung verglichen. So wird aus einer Kostenidee eine belastbare technische Entscheidung.

8. Nicht mehr benötigte VPN-Verbindungen abschalten

Site-to-Site-VPN-Verbindungen werden häufig eingerichtet, um AWS mit Unternehmensstandorten oder eigenen Rechenzentren zu verbinden.

Auch hier entsteht ein klassisches Legacy-Problem. Das alte Rechenzentrum wurde längst abgeschaltet. Die VPN-Verbindung in AWS existiert weiterhin. Oder der Tunnel ist technisch vorhanden, transportiert jedoch praktisch keine Daten mehr.

Unter AWS → VPC → Site-to-Site VPN Connections lassen sich bestehende Verbindungen identifizieren. CloudWatch-Metriken wie TunnelState sowie TunnelDataIn und TunnelDataOut helfen bei der Bewertung.

Ein Tunnel, der seit Wochen nicht aktiv war, ist verdächtig. Ein aktiver Tunnel ohne nennenswerten Traffic ebenfalls.

Bevor die Verbindung gelöscht wird, muss allerdings geklärt werden, ob sie beispielsweise bewusst als Disaster-Recovery-Verbindung vorgehalten wird. Ein Betrachtungszeitraum von rund 30 Tagen kann ein guter Startpunkt sein, bei sehr selten genutzten Notfallverbindungen ist jedoch zusätzliche Dokumentation erforderlich.

Wird eine obsolete VPN-Verbindung entfernt, sollten auch zugehörige Gateways und weitere Netzwerkkomponenten überprüft werden.

Aus Governance-Sicht sollte jede langfristig vorgehaltene Verbindung einen dokumentierten Zweck besitzen. Eine DR-Verbindung darf wenig Traffic haben – dann sollte aber klar vermerkt sein, warum sie existiert, wann sie zuletzt getestet wurde und wer die technische Verantwortung trägt.

9. Ungenutzte Load Balancer löschen

Load Balancer verteilen Anfragen auf verschiedene Backend-Systeme. Eine Anwendung wird abgeschaltet – der Load Balancer bleibt.

Das passiert beispielsweise nach Migrationen, abgeschlossenen Blue-Green-Deployments oder beim Entfernen alter Entwicklungsumgebungen.

Die Prüfung ist vergleichsweise einfach: AWS → EC2 → Load Balancers. Anschließend untersuchen Sie:

• Existieren Listener?
• Existieren Target Groups?
• Sind den Target Groups überhaupt noch Targets zugeordnet?
• Gibt es Requests oder verarbeitete Bytes?
• Ist ein aktiver DNS-Eintrag mit dem Load Balancer verbunden?

Ein Load Balancer ohne Listener ist ein starkes Warnsignal. Dasselbe gilt für einen Load Balancer mit Listener, aber ohne Backend-Targets.

In diesen Fällen braucht es teilweise nicht einmal eine umfangreiche historische Trafficanalyse. Bereits die Architektur zeigt, dass keine reguläre Weiterleitung stattfinden kann. Trotzdem sollte auch hier der verantwortliche Owner bestätigen, dass die Ressource tatsächlich nicht mehr benötigt wird.

Danach kann sie entfernt werden. Prüfen Sie im Anschluss zugehörige Target Groups, Security Groups, Zertifikate und DNS-Einträge. Gerade nach Migrationen bleiben oft mehrere abhängige Ressourcen übrig.

Für größere Umgebungen kann ein monatlicher Report über Load Balancer ohne Targets, ohne Requests oder ohne Owner-Tag zu den effektivsten Hygiene-Checks gehören.

10. ElastiCache richtig dimensionieren

Amazon ElastiCache wird beispielsweise mit Redis oder Memcached genutzt, um häufig benötigte Daten besonders schnell bereitzustellen.

Auch Cache-Systeme werden gerne mit großzügigen Sicherheitsreserven aufgebaut. Anschließend überprüft jahrelang niemand, ob diese Kapazität tatsächlich gebraucht wird.

Für einen Kostencheck sind vor allem zwei Größen interessant: Arbeitsspeicher und CPU. CloudWatch stellt hierfür unter anderem FreeableMemory bereit. Bei Redis sollte insbesondere EngineCPUUtilization berücksichtigt werden, weil eine pauschale Betrachtung gewöhnlicher CPU-Metriken irreführend sein kann.

Wenn dauerhaft ein großer Teil des Arbeitsspeichers frei bleibt und auch CPU-Spitzen überschaubar sind, sollte geprüft werden, ob eine kleinere Node-Größe ausreicht.

Nach dem Downsizing muss die Performance selbstverständlich beobachtet werden. Auch Cache Hit Rate, Evictions, Connections, Netzwerkdurchsatz und Replikationsverhalten können relevant sein.

Bei Redis-Clustern sollte außerdem geprüft werden, ob Anzahl und Größe der Shards zur realen Nutzung passen. Ein Cluster kann überdimensioniert sein, obwohl einzelne Nodes nicht offensichtlich leer wirken.

Auch bestehende Reservations beziehungsweise Commitments sollten vor der Änderung berücksichtigt werden. Die wirtschaftlich beste Konfiguration entsteht aus Nutzung, Performance und Einkaufskonditionen zusammen.

11. Development- und Testsysteme außerhalb der Arbeitszeit abschalten

Eine der einfachsten Fragen bei der AWS-Kostenoptimierung lautet: Warum läuft eine Entwicklungsumgebung nachts um drei Uhr? Und warum läuft sie am Sonntag?

Viele Development-, QA-, Schulungs- und Testsysteme werden nur während klassischer Arbeitszeiten benötigt, laufen aber 168 Stunden pro Woche.

Mit automatisierten Zeitplänen können EC2- und RDS-Ressourcen außerhalb definierter Nutzungsfenster gestoppt und zu Arbeitsbeginn wieder gestartet werden. Eine Umgebung, die beispielsweise nur an fünf Werktagen jeweils zehn Stunden benötigt wird, läuft dadurch statt 168 nur etwa 50 Stunden pro Woche.

Natürlich eignet sich das nicht für jedes System. Produktionssysteme, 24/7-Testplattformen, internationale Teams oder nächtliche Batch-Prozesse benötigen möglicherweise durchgehende Verfügbarkeit.

Für klassische interne Dev- und Testressourcen ist Scheduling jedoch einer der schnellsten Hebel. Besonders effektiv wird die Maßnahme, wenn ein Unternehmen Ressourcen konsequent taggt und Start-/Stop-Regeln automatisiert.

Dann wird Abschalten vom manuellen Sparprojekt zum Standardprozess. Ergänzend können Entwickler eine einfache Möglichkeit erhalten, eine Umgebung für Sonderfälle temporär zu verlängern.

Der größte organisatorische Vorteil: Niemand muss jeden Abend daran denken, eine Instanz auszuschalten. Die Kostenkontrolle wird Teil der Plattform und nicht vom guten Willen einzelner Mitarbeiter abhängig.

12. Savings Plans und Reserved Capacity für planbare Grundlast einsetzen

Rightsizing reduziert die benötigte Kapazität. Der nächste Schritt besteht darin, die verbleibende Kapazität möglichst günstig einzukaufen.

Wer vorhersehbare AWS-Compute-Nutzung dauerhaft zum On-Demand-Tarif bezahlt, lässt möglicherweise erhebliches Einsparpotenzial liegen.

AWS Savings Plans ermöglichen reduzierte Preise im Gegenzug für ein festgelegtes Nutzungs- beziehungsweise Ausgaben-Commitment über ein oder drei Jahre. Abhängig von Modell und Laufzeit können gegenüber On-Demand-Preisen erhebliche Rabatte entstehen.

Der entscheidende Punkt lautet allerdings: Erst optimieren, dann committen.

Wer zunächst eine massiv überdimensionierte Infrastruktur für drei Jahre reserviert und anschließend Rightsizing betreibt, kann sich selbst in eine ungünstige Kostenstruktur einschließen.

Die sinnvollere Reihenfolge lautet:

• Transparenz herstellen.
• Ungenutzte Ressourcen entfernen.
• Rightsizing durchführen.
• Grundlast bestimmen.
• Erst danach Savings Plans beziehungsweise passende Reservations abschließen.

Der AWS Cost Explorer stellt hierfür Empfehlungen auf Basis historischer Nutzung bereit. Wichtig ist, verschiedene Szenarien mit konservativen Annahmen zu betrachten. Ein Unternehmen sollte nicht die maximale theoretische Abdeckung anstreben, wenn das Geschäft stark schwankt oder in den nächsten Monaten Migrationen geplant sind.

Commitments sind kein Ersatz für Kostenoptimierung. Sie sind die letzte Einkaufsschicht auf einer bereits effizienten Infrastruktur.

13. S3-Speicherkosten mit Lifecycle-Regeln und Intelligent-Tiering reduzieren

Storage wirkt im Vergleich zu großen EC2- oder RDS-Instanzen häufig günstig. Das Problem entsteht durch die Menge.

Terabytes oder Petabytes an Daten können über Jahre wachsen, obwohl ein großer Teil kaum noch abgerufen wird. Nicht jede Datei muss dauerhaft in S3 Standard liegen.

Amazon stellt unterschiedliche Storage Classes für verschiedene Zugriffsmuster bereit. Besonders interessant ist S3 Intelligent-Tiering bei unbekannten oder wechselnden Zugriffsmustern. Dabei werden Objekte anhand ihres Zugriffsverhaltens automatisiert in günstigere Zugriffsebenen verschoben.

Zusätzlich können Unternehmen Lifecycle Policies verwenden, um Daten nach definierten Zeiträumen zu verschieben oder zu löschen.

Typische Kandidaten sind:

• alte Logs,
• historische Exporte,
• Backups,
• abgeschlossene Datenprojekte,
• temporäre Uploads,
• alte Versionen von Objekten.

Wichtig ist, Abrufkosten, Mindestaufbewahrungszeiten und tatsächliche Nutzungsmuster zu berücksichtigen.

Darüber hinaus sollte geprüft werden, ob Versioning unbeabsichtigt große Mengen alter Objektversionen hält. Auch unvollständige Multipart Uploads können unnötigen Speicher belegen. Lifecycle-Regeln können solche Altbestände automatisiert aufräumen.

Cloud-Speicheroptimierung bedeutet nicht, Daten möglichst billig abzulegen. Sie bedeutet, für jede Datenklasse die wirtschaftlich passende Speicherklasse und Aufbewahrungsdauer zu wählen.

14. AWS Graviton als Alternative zu x86 prüfen

Eine weitere Möglichkeit zur Reduktion von Compute-Kosten ist nicht nur die Größe einer Instance zu verändern, sondern die zugrunde liegende Prozessorarchitektur zu hinterfragen.

AWS Graviton basiert auf ARM-Prozessoren, die von AWS speziell für Cloud-Workloads entwickelt wurden. Für geeignete Workloads können Graviton-Instanzen ein besseres Preis-Leistungs-Verhältnis bieten als vergleichbare x86-Varianten.

Eine Migration ist allerdings kein reiner Preisvergleich. Die Anwendung, Container Images, Libraries und Abhängigkeiten müssen ARM-kompatibel sein. Deshalb sollte vor einer breiten Migration ein Benchmark durchgeführt werden.

Ein sinnvoller Ansatz:

• Geeigneten Workload auswählen.
• Graviton-Testumgebung aufsetzen.
• Anwendung und Dependencies auf ARM-Kompatibilität prüfen.
• Performance und Stabilität vergleichen.
• Kosten pro Transaktion, Request oder Batch messen.
• Erst anschließend skalieren.

Besonders bei großen EC2-, Container- oder Kubernetes-Flotten können bereits relativ kleine prozentuale Verbesserungen erhebliche absolute Einsparungen erzeugen.

Graviton sollte deshalb nicht als isoliertes Migrationsprojekt betrachtet werden. Idealerweise wird die Architekturprüfung mit Rightsizing kombiniert. So kann beispielsweise nicht nur von x86 auf ARM, sondern gleichzeitig auf eine passendere Instance-Größe oder neuere Generation gewechselt werden.

15. Netzwerk- und Datentransferkosten systematisch optimieren

Ein Kostenbereich wird bei AWS besonders häufig unterschätzt: Datentransfer.

Architekturen können technisch funktionieren und trotzdem unnötig teuren Netzwerkverkehr erzeugen.

Ein klassisches Beispiel ist Traffic aus privaten Subnetzen zu Amazon S3 oder DynamoDB, der über ein NAT Gateway geleitet wird. Für diese Services können Gateway VPC Endpoints eingesetzt werden, sodass relevanter Traffic ohne NAT Gateway auskommt.

Bei großen Datenvolumen kann das erheblich sein.

Auch Availability-Zone-übergreifender Traffic sollte untersucht werden. Wenn ein Workload regelmäßig große Datenmengen zwischen Availability Zones bewegt, kann die Platzierung von Compute, Datenbank, Cache und NAT Gateway einen messbaren Kosteneffekt haben.

Bei öffentlich ausgelieferten Inhalten kann zusätzlich Amazon CloudFront relevant sein. Caching reduziert die Anzahl der Requests, die überhaupt beim Ursprung ankommen, und kann die Verteilung großer Datenmengen effizienter machen.

Für einen Audit empfiehlt sich eine Kostenmatrix: Welche Anwendungen erzeugen besonders hohe Data-Transfer-, NAT-, Inter-AZ- oder Internet-Egress-Kosten? Danach wird geprüft, ob Architektur, Caching, Endpoints, Kompression, Region-Placement oder Datenlokalität verbessert werden können.

Deshalb sollte ein AWS-Kosten-Audit nie ausschließlich Compute und Storage betrachten. Die Netzwerkarchitektur gehört zwingend dazu.

Welche AWS-Kosten sollte man zuerst optimieren?

Nicht jede Optimierung ist gleich wichtig.

Ein guter Cloud-Cost-Audit beginnt deshalb nicht mit 500 kleinen Einzelpositionen, sondern mit den größten Kostenblöcken.

Öffnen Sie zunächst den AWS Cost Explorer und beantworten Sie drei Fragen:

• Welche Services verursachen die höchsten monatlichen Kosten?
• Welche Accounts beziehungsweise Business Units verursachen diese Kosten?
• Welche Kosten sind in den vergangenen drei bis zwölf Monaten besonders stark gestiegen?

Anschließend priorisieren Sie.

Eine 30-prozentige Einsparung auf einem Service mit 100 Euro Monatskosten ist wirtschaftlich weniger relevant als fünf Prozent auf einer Infrastruktur mit 100.000 Euro Monatskosten.

Der beste FinOps-Prozess kombiniert deshalb zwei Ansätze: Top-down betrachten Sie zunächst die größten Rechnungspositionen. Bottom-up suchen Sie anschließend innerhalb dieser Services nach einzelnen ineffizienten Ressourcen.

So lässt sich vermeiden, dass hochqualifizierte Cloud Engineers tagelang Ressourcen im Cent-Bereich optimieren.

Zusätzlich sollte jede Maßnahme anhand von drei Dimensionen bewertet werden: monetäres Potenzial, technisches Risiko und Umsetzungsaufwand. Maßnahmen mit hohem Potenzial, geringem Risiko und geringem Aufwand gehören an die Spitze der Roadmap.

AWS-Kostenoptimierung darf kein einmaliges Projekt sein

Der vielleicht wichtigste Punkt kommt nach den 15 Maßnahmen.

Cloud-Kosten wachsen nach.

Selbst eine perfekt aufgeräumte AWS-Umgebung kann zwölf Monate später wieder überdimensioniert sein. Neue Projekte entstehen. Entwickler erstellen Ressourcen. Lastprofile verändern sich. Systeme werden migriert. Teams wechseln. Alte Infrastruktur verliert ihren Owner.

Deshalb braucht AWS-Kostenoptimierung einen wiederkehrenden Prozess.

Sinnvoll sind beispielsweise monatliche Cost Reviews, klare Resource Owner, einheitliches Tagging, Budgets und Alerts sowie regelmäßige Rightsizing-Reviews.

Besonders wertvoll ist eine einfache Regel: Keine relevante AWS-Ressource ohne nachvollziehbaren Owner und Business Purpose.

Kann niemand erklären, wem eine Ressource gehört und warum sie benötigt wird, ist sie zumindest ein Kandidat für eine genauere Prüfung.

FinOps funktioniert am besten, wenn Finance, Engineering und Management gemeinsam auf dieselben Daten schauen. Engineering versteht die technische Kritikalität, Finance kennt die Kostentreiber, und Management kann Prioritäten sowie Risikobereitschaft vorgeben.

So wird AWS-Kostenoptimierung nicht zur Sparaktion gegen die IT, sondern zu einer gemeinsamen Steuerungsaufgabe.

Häufig gestellte Fragen zur Reduktion von AWS-Kosten

Wie kann man AWS-Kosten am schnellsten reduzieren?

Der schnellste Einstieg besteht häufig darin, ungenutzte Ressourcen zu entfernen und Non-Production-Systeme außerhalb ihrer Nutzungszeiten abzuschalten. Anschließend sollten besonders teure EC2-, RDS- und ElastiCache-Ressourcen auf Überdimensionierung untersucht werden.

Wie finde ich überdimensionierte EC2-Instanzen?

AWS Compute Optimizer und CloudWatch liefern dafür wichtige Daten. Betrachten Sie nicht nur Durchschnittswerte, sondern Spitzenlasten, RAM, Netzwerk und einen ausreichend langen Zeitraum. Bei zyklischen Workloads sollten Monats- oder Quartalsmuster berücksichtigt werden.

Sind Savings Plans immer sinnvoll?

Nein. Ein Commitment lohnt sich nur für ausreichend stabile und vorhersehbare Nutzung. Außerdem sollte Rightsizing möglichst vor dem Abschluss langfristiger Commitments erfolgen. Andernfalls reserviert ein Unternehmen möglicherweise Kapazität, die es eigentlich gar nicht benötigt.

Sollte man alte AWS-Ressourcen automatisch löschen?

Nicht ohne Schutzmechanismen. Fehlender Traffic allein beweist nicht immer, dass eine Ressource überflüssig ist. Disaster-Recovery-Systeme, Monatsprozesse oder Compliance-Anforderungen können lange Phasen ohne Nutzung erklären. Deshalb sollten Owner, Abhängigkeiten und geschäftlicher Zweck geprüft werden.

Welche AWS-Services bieten besonders häufig Einsparpotenzial?

Das hängt von der Architektur ab. Häufig relevante Bereiche sind EC2, RDS, EKS, ElastiCache, S3, NAT Gateways, Datenübertragung, Load Balancer sowie ungenutzte Netzwerk- und Backup-Ressourcen.

Wie oft sollte ein AWS Cost Audit durchgeführt werden?

Bei größeren Cloud-Umgebungen sollte Kostenmanagement kontinuierlich erfolgen. Zusätzlich kann ein tiefergehender Audit beispielsweise quartalsweise sinnvoll sein. Gerade schnell wachsende Organisationen sollten Kostenentwicklungen deutlich häufiger überwachen.

Fazit: AWS Cloud-Kosten reduzieren heißt Infrastruktur konsequent hinterfragen

AWS-Kosten lassen sich selten mit einer einzigen Maßnahme dauerhaft reduzieren.

Die größten Einsparungen entstehen durch die Kombination verschiedener Hebel.

EC2- und RDS-Systeme werden auf die tatsächlich benötigte Kapazität verkleinert. Ungenutzte NAT Gateways, VPC Endpoints, Snapshots, Kubernetes-Cluster, VPNs und Load Balancer verschwinden. Development-Systeme laufen nur dann, wenn sie tatsächlich gebraucht werden. S3-Daten landen in der passenden Storage Class. Geeignete Workloads wechseln auf Graviton. Planbare Grundlast wird über Savings Plans oder andere Commitment-Modelle günstiger eingekauft. Und Netzwerk- sowie Datentransferkosten werden genauso konsequent analysiert wie Compute-Kosten.

Der wichtigste Grundsatz bleibt dabei einfach: Bezahlen Sie nicht für theoretisch verfügbare Cloud-Ressourcen. Bezahlen Sie für Infrastruktur, die Ihr Unternehmen tatsächlich benötigt.

Wer diese Frage regelmäßig und datenbasiert stellt, kann AWS-Kosten nicht nur kurzfristig senken, sondern dauerhaft kontrollieren.

Quellen und fachliche Basis

Fachliche Basis: das vom Nutzer bereitgestellte Dokument „Cloud.docx“ mit den ursprünglichen zehn Audit-Maßnahmen. Ergänzende AWS-Quellen:

• AWS Compute Optimizer – EC2 rightsizing
• AWS NAT Gateway pricing
• Instance Scheduler on AWS
• AWS Savings Plans
• Amazon S3 Intelligent-Tiering
• AWS Graviton
• VPC Gateway Endpoints
• Amazon CloudFront