Ungenutzte Reservations sind stille Kostenlecks

Was sind AWS Reservations?

Wenn Sie sich für 1 oder 3 Jahre zur Nutzung von AWS-Ressourcen verpflichten und dafür einen deutlichen Rabatt erhalten (in der Regel 30–72 % gegenüber dem On-Demand-Preis), erwerben Sie eine AWS Reservation. Anders als beim On-Demand-Modell, bei dem Sie nur für die tatsächliche Nutzung zahlen, ist eine Reservation eine finanzielle Verpflichtung. Die Kosten fallen an – unabhängig davon, ob Ihre Workloads sie tatsächlich abrufen.

AWS bietet Reservations für eine ganze Reihe von Services:

• Amazon EC2 – Reserved Instances (RIs) für Compute-Workloads
• Amazon RDS – Reserved DB Instances für relationale Datenbanken (MySQL, PostgreSQL, SQL Server, Oracle, MariaDB, Aurora)
• Amazon ElastiCache – Reserved Cache Nodes für Redis- und Memcached-Cluster
• Amazon OpenSearch Service – Reserved Instances für Such- und Analytics-Domains
• Amazon Redshift – Reserved Nodes für Data-Warehousing-Workloads
• Amazon DynamoDB – Reserved Capacity für Lese-/Schreib-Durchsatzeinheiten
• AWS Elemental MediaConvert – Reserved Transcode Slots für Media Processing

Alle diese Services folgen demselben Prinzip: Sie zahlen im Voraus, teilweise im Voraus oder monatlich für reservierte Kapazität, und AWS verrechnet den vergünstigten Tarif, sobald passende Nutzung erkannt wird. Bleibt die Nutzung aus, läuft die Reservation ins Leere – und Sie zahlen trotzdem.

Das Problem: Ungenutzte Reservations sind stille Kostenlecks

Reservations werden zu einem bestimmten Zeitpunkt gekauft – auf Basis dessen, wie Ihre Workloads heute aussehen. Cloud-Umgebungen sind aber dynamisch. Teams skalieren Services herunter, migrieren Workloads, mustern Anwendungen aus oder stellen ihre Architektur um. Was gestern noch perfekt gepasst hat, wird so schnell zum Kostenklotz, ohne dass jemand es bemerkt.

Warum das im großen Maßstab kritisch ist:

Sie merken es nicht immer sofort. AWS liefert im Cost Explorer zwar Auslastungsmetriken, die zeigen aber nur, was passiert ist. Sie stoßen keine automatisierten Workflows an und senden auch keine kontextbezogenen Alerts an das richtige Team.

Der finanzielle Schaden wächst rasant. Eine einzige unterausgelastete r5.4xlarge RDS Reserved Instance zum No-Upfront-Tarif in us-east-1 kann über 5.000 US-Dollar pro Jahr kosten. Läuft sie bei 10 % Auslastung, zahlen Sie effektiv 4.500 US-Dollar für nichts. Multipliziert mit Dutzenden Reservations über mehrere AWS-Accounts und Regionen hinweg landet der Waste schnell im sechsstelligen Bereich.

Aus meiner Arbeit mit Kunden aus den unterschiedlichsten Branchen weiß ich: Das ist eines der häufigsten FinOps-Fehlermuster überhaupt. Teams entdecken unterausgelastete Reservations erst Wochen oder Monate später – und bis dahin hat sich der Waste bereits angesammelt und das Zeitfenster, um die Reservation zu tauschen oder anzupassen, ist womöglich schon geschlossen.

Wie DoiT CloudFlow das Problem löst

DoiT CloudFlow ist eine GenAI-gestützte No-Code-Plattform für FinOps- und CloudOps-Automatisierung – direkt in die DoiT-Konsole integriert. Damit erstellen Sie Workflows (sogenannte Flows), die AWS-APIs abfragen, Daten per bedingter Logik auswerten und Aktionen auslösen: Slack-Benachrichtigungen versenden, E-Mail-Alerts triggern, Freigaben einholen oder weiterführende Automatisierungen starten.

Fürs Monitoring der Reservation-Auslastung liefert CloudFlow etwas, das AWS nativ nicht bietet: einen geplanten, automatisierten Check über mehrere Services hinweg – inklusive integriertem Alerting, und das ganz ohne Custom Development.

Das Template "Identify Underused AWS Reserved Instances Across Services"

DoiT stellt ein einsatzfertiges CloudFlow-Template bereit, das genau für diesen Use Case entwickelt wurde: Identify underused AWS Reserved Instances across services.

Damit erhalten Sie einen komplett vorgefertigten Workflow, den Sie in wenigen Minuten anpassen und veröffentlichen können. So funktioniert es:

Schritt 1: Geplanter Trigger

Der Flow wird per individuellem Zeitplan ausgelöst, zum Beispiel täglich um 9 Uhr oder wöchentlich montags. Sie legen die Frequenz fest, mit der Ihr Team Transparenz über den Zustand seiner Reservations haben möchte. Manuelles Nachhaken entfällt.

Schritt 2: Reserved-Instance-Auslastung bei AWS abfragen

Der Flow ruft die AWS Cost Explorer API auf – konkret die GetReservationUtilization-API – für die AWS-Services, die für Sie relevant sind. So werden die tatsächlichen Auslastungsraten für EC2, RDS, ElastiCache, Redshift, OpenSearch und weitere Reservation-Typen über alle verbundenen AWS-Accounts und Regionen hinweg ermittelt.

Schritt 3: Nach unterausgelasteten Reservations filtern

Ein Filter-Node wertet die Auslastungsdaten aus und isoliert alle Reservations unterhalb Ihres definierten Schwellenwerts. Als Best Practice empfiehlt sich, alles unter 80 % Auslastung zu markieren – diesen Wert betrachtet AWS selbst als gesunde Untergrenze. Sie können den Schwellenwert an die Standards Ihres Unternehmens anpassen.

Schritt 4: Gesund vs. gefährdet

• Liegen alle Reservations im grünen Bereich (auf oder über Ihrem Schwellenwert), kann der Flow das Ergebnis stillschweigend protokollieren.
• Werden unterausgelastete Reservations gefunden, wechselt der Flow in den Alerting-Pfad.

Schritt 5: Die richtigen Personen benachrichtigen

Der Flow verschickt eine Benachrichtigung mit einer Zusammenfassung der unterausgelasteten Reservations – inklusive Service-Typ, Account, Region, Auslastungsrate und finanzieller Auswirkung. Die Zustellung erfolgt wahlweise über:

• Einen Slack-Channel (z. B. #finops-alerts oder einen teamspezifischen Channel)
• E-Mail an das verantwortliche Team oder den FinOps-Practitioner

Einmal veröffentlicht, läuft der Flow planmäßig – und Ihr Team wird automatisch informiert, sobald Reservations unter den Schwellenwert rutschen. Niemand muss mehr daran denken, manuell nachzusehen.

Mehr als Alerting: Reservation-Waste konsequent beseitigen

Benachrichtigungen sind nur der erste Schritt. Mit CloudFlow können Sie noch weiter gehen:

• Freigabe-Workflows: Bevor eine Änderung durchgeführt wird (z. B. Tausch oder Kündigung einer Reservation), lassen Sie sich die Aktion per Slack oder E-Mail durch einen Stakeholder freigeben. So bleibt bei folgenreichen Entscheidungen ein menschliches Kontrollmoment erhalten.
• LLM-gestützte Zusammenfassungen: Nutzen Sie den LLM-Node, um eine verständliche Zusammenfassung der unterausgelasteten Reservations zu erzeugen – so wird die Benachrichtigung auch für nicht-technische Stakeholder sofort greifbar.
• Historisches Tracking: Der Ausführungsverlauf von CloudFlow protokolliert jeden Durchlauf, die ausgewerteten Daten und die versendeten Benachrichtigungen – ideal für Compliance und kontinuierliche Verbesserung.

Fazit

AWS Reservations gehören zu den wirkungsvollsten Werkzeugen der Kostenoptimierung – allerdings nur, wenn sie auch tatsächlich genutzt werden. Unterausgelastete Reservations sind ein stiller und erstaunlich häufiger Kostenfresser, den klassische Monitoring-Tools nicht angemessen abdecken.

Mit DoiT CloudFlow und dem Template "Identify underused AWS Reserved Instances across services" können Sie:

• Die Auslastung von EC2, RDS, ElastiCache, Redshift, OpenSearch und weiteren Services automatisch prüfen
• Eine eigene Schwellenwert-Policy für die Auslastung definieren
• Zeitnahe, kontextbezogene Alerts per Slack oder E-Mail erhalten
• Ihr Team mit nachverfolgten Issues und Freigabe-Workflows in die Verantwortung nehmen
• Das alles ohne Code und in wenigen Minuten

Entdecken Sie Reservation-Waste nicht länger erst im Nachhinein. Richten Sie noch heute Ihren CloudFlow ein und machen Sie das Reservation-Monitoring zu einem proaktiven, automatisierten Bestandteil Ihrer FinOps-Praxis.

Bereit loszulegen? Melden Sie sich in der DoiT-Konsole an, öffnen Sie CloudFlow und starten Sie mit dem Reserved-Instance-Monitoring-Template. Bei Fragen ist unser Team gerne für Sie da.