Wer seine Commitment-Strategie automatisiert, senkt Risiken und nimmt sich selbst Arbeit ab.

Für Digital Natives ist die Public-Cloud-Infrastruktur zugleich Rückgrat des Tech-Stacks und größter Kostenblock im Betriebsbudget. Sie muss daher laufend überwacht werden, damit die Kosten zu den übergeordneten Geschäftszielen passen. FinOps-Teams, die diese Kosten steuern und die abteilungsübergreifende Zusammenarbeit zwischen Engineering, Finance und Product fördern, suchen deshalb fortlaufend nach Wegen, Cloud-Kosten zu optimieren und Ausgaben zu senken, wo immer es möglich ist.
Eine der gängigsten Methoden zur Kostenoptimierung in der Public Cloud sind volumenbasierte Rabatte – die sogenannten Commitments: Der Cloud-Anbieter gewährt einen reduzierten Preis im Gegenzug für die Zusage, eine bestimmte Menge an Ressourcen über einen festgelegten Zeitraum zu nutzen. Bei AWS gibt es diese Commitments entweder als Reserved Instances oder als Savings Plans. Werfen Sie einen Blick auf die Tabelle unten oder lesen Sie mehr zu den Unterschieden zwischen diesen Plänen.

So unterschiedlich die Commitment-Typen der einzelnen Cloud-Anbieter im Detail auch sind: Bei den Laufzeiten gibt es einen der wenigen gemeinsamen Standards. Solche Vereinbarungen werden fast immer mit einer Laufzeit von 1 oder 3 Jahren angeboten – mit unterschiedlich hohen Rabatten, je nach Laufzeit und Spielraum, der für die workloads im Rahmen der Vereinbarung erlaubt ist. Ein 3-Jahres-Commitment bringt zum Beispiel immer einen höheren Rabatt (~60–70 %) als ein 1-Jahres-Commitment (~25–35 %), und ein Plan, der den Wechsel von Regionen oder Maschinentypen zulässt, spart in der Regel weniger ein als einer, der Sie festlegt.
Da operative Flexibilität und Spielraum für die Engineers gegen Kostenmanagement und übergeordnete Geschäftsziele abgewogen werden müssen, setzt selbst ein einigermaßen etabliertes Unternehmen kaum je auf nur einen Commitment-Typ. Die meisten Commitment-Portfolios sind auf die jeweiligen Anforderungen und die Wachstumsphase des Unternehmens zugeschnitten und bestehen aus einer Mischung von 1- und 3-Jahres-Verträgen über verschiedene Teams, Regionen, Maschinentypen und mehr.
So könnte das beispielsweise bei einem fiktiven Unternehmen auf AWS aussehen, das den US-Markt bedient:
Cloud-Anbieter
Plantyp
Laufzeit
Region
Maschinenfamilie
Rabatt
Ablaufdatum
AWS
Compute SP
3 Jahre
Variabel
Variabel
63 %
- März 2025
AWS
EC2 RI
1 Jahr
US East-1
M7g
28 %
- November 2023
AWS
EC2 RI
1 Jahr
US West-2
M7g
28 %
- November 2023
AWS
EC2 RI
1 Jahr
US East
T3
29 %
- Februar 2024
AWS
EC2 RI
1 Jahr
US West
T3
29 %
- Februar 2024
In diesem Beispiel hat Company X im März 2022 einen einfachen Compute Savings Plan abgeschlossen, um die Mindestmenge an Compute abzudecken, die das Unternehmen für die nächsten drei Jahre erwartete. Als die workloads im Laufe des Jahres wuchsen und das 3-Jahres-Commitment nicht mehr ausreichte, entschied sich das Unternehmen für die Maschinenfamilie M7g und kaufte an beiden Küsten zusätzliche 1-Jahres-Reserved-Instances, um die zusätzlichen workloads abzudecken. Wenige Monate später wiederholte sich das Ganze, als ein neues Projekt T3-Maschinen erforderte.
Das ist eine gängige Strategie, wenn der Cloud-Footprint eines Unternehmens wächst (sofern es das Risiko von Commitment-Käufen überhaupt eingehen will). Im Einsatz ist dann ein Mix aus 1- und 3-Jahres-Commitments mit unterschiedlichen Rabattstufen, Laufzeiten und Ablaufterminen, die alle regelmäßig überwacht und gepflegt werden müssen. Nur so lässt sich sicherstellen, dass die prognostizierte Nutzung und die Ausgaben weder über- noch unterschritten werden und am Laufzeitende fundiert entschieden werden kann, ob ein Commitment verlängert oder ausgelaufen wird. Dass das eine erhebliche Belastung für jede Organisation bedeutet, versteht sich von selbst – unabhängig davon, ob der Prozess bereits durch eine etablierte FinOps-Praxis im Tagesgeschäft verankert ist oder nicht.
Den Prozess vereinfachen
DoiT Flexsave™ wurde dafür gebaut, das Commitment-Management zu vereinfachen und zu automatisieren. Flexsave analysiert die laufenden Compute-Ausgaben, erkennt workloads, die noch nicht durch bestehende Commitments (z. B. SPs, RIs, Spot oder Enterprise Discount Programs) abgedeckt sind, und wendet auf diese On-Demand-workloads automatisch einen Rabatt in Höhe eines 1-Jahres-Commitments an.
Sobald ein Unternehmen Flexsave in seiner AWS-Umgebung aktiviert, bekommt es dieselben Rabattsätze wie zuvor mit seinen 1-Jahres-Commitments. Heißt konkret: Bestehende 1-Jahres-Pläne können einfach auslaufen – Flexsave übernimmt nahtlos.
Im fiktiven Beispiel oben könnte Company X 80 % seiner Commitments auslaufen lassen. Damit würde nicht nur das FinOps-Team (oder wer auch immer Commitments und Nutzung im Blick behält) entlastet – auch die Engineers gewinnen wieder Spielraum, sich jenseits der zuvor festgelegten Maschinenfamilien und Regionen zu bewegen.
Am Ende sieht die Commitment-Abdeckung von Company X dann ungefähr so aus:

Wenn Sie mehr über Commitment-Management erfahren und Ihre FinOps-Praxis mit DoiT ausbauen möchten, laden Sie das Cloud Compute Commitment Handbook herunter.