Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Schluss mit dem Aufwand beim Cloud-Commitment-Management

By Craig LowellJul 19, 20234 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

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 %

  1. März 2025

AWS

EC2 RI

1 Jahr

US East-1

M7g

28 %

  1. November 2023

AWS

EC2 RI

1 Jahr

US West-2

M7g

28 %

  1. November 2023

AWS

EC2 RI

1 Jahr

US East

T3

29 %

  1. Februar 2024

AWS

EC2 RI

1 Jahr

US West

T3

29 %

  1. 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.