Wie hoch sollte Ihr AWS Savings Plans Commitment sein? Das Dimensionierungsproblem – und wie Sie aufhören zu raten

Die kurze Antwort

Wenn Sie nur eines aus diesem Beitrag mitnehmen: Committen Sie auf Ihre dauerhafte Baseline – die Compute-Kapazität, die wirklich rund um die Uhr läuft – nicht auf die durchschnittliche Woche und nicht auf den Peak. Machen Sie daraus eine Abdeckungs-Policy, die Sie vertreten können (wie viel Ihrer Ausgaben unter Commitment stehen soll, plus eine Obergrenze, die Sie nicht überschreiten), und nähern Sie sich dem Ziel in kleinen Commitment-Schritten an, statt alles mit einem einzigen großen Kauf zu erledigen.

Alles Weitere unten erklärt, warum das die richtige Antwort ist, warum der übliche Prozess sie erschwert – und wie Sie sie kontinuierlich umsetzen, ohne permanent ein Spreadsheet pflegen zu müssen.

Warum "wie viel" wirklich schwierig ist

Beginnen wir mit zwei Begriffen, die oft synonym verwendet werden – und es nicht sollten: Abdeckung (Coverage) und Auslastung (Utilization).

• Abdeckung beschreibt, wie viel Ihrer anrechenbaren On-Demand-Ausgaben unter einem Commitment liegen. Laufen bei Ihnen rund 80 $/Stunde an Savings-Plans-fähigem Compute und 60 $/Stunde davon sind abgedeckt, liegen Sie bei 75 % Abdeckung.
• Auslastung beschreibt, wie viel des gekauften Commitments tatsächlich genutzt wird. Committen Sie 70 $/Stunde und es kommen nur 60 $/Stunde passende Nutzung zusammen, liegen Sie bei ~86 % Auslastung – und zahlen für die ungenutzten 14 % trotzdem den Commitment-Preis.

Und jetzt der unbequeme Teil: Diese beiden Größen bewegen sich in entgegengesetzte Richtungen, sobald Sie an ihnen ziehen. Jagen Sie einer höheren Abdeckung hinterher, kaufen Sie mehr Commitment – und die Auslastung rutscht leichter ab, wenn die Nutzung sinkt. Schützen Sie die Auslastung durch konservative Käufe, bleibt Ihre Abdeckung – und damit Ihre Ersparnis – niedrig. Ein Commitment zu dimensionieren heißt, sich auf dieser Wippe zu positionieren. Die meisten Teams treffen diese Wahl nie explizit; sie reagieren nur.

Dazu kommen die Stellhebel, von denen jeder die Rechnung verändert:

Entscheidung	Optionen	Der Trade-off
Laufzeit	1 Jahr vs. 3 Jahre	3 Jahre bringen einen höheren Rabatt, verdreifachen aber die Bindung, auf die Sie wetten.
Zahlung	No / Partial / All Upfront	Mehr Vorauszahlung bringt einen etwas besseren Preis, bindet aber Liquidität und erhöht den Einsatz, falls Sie falschliegen.
Plan-Typ	Compute SP vs. EC2 Instance SP	Compute SP (bis zu ~66 % Rabatt) ist flexibel über Instanzfamilie, Größe, Region, OS, Tenancy und sogar Fargate/Lambda hinweg. EC2 Instance SP (bis zu ~72 % Rabatt) spart etwas mehr, bindet Sie aber an eine Instanzfamilie in einer Region. Wieder: Flexibilität vs. Rabatt.

Um zu sehen, was diese Entscheidungen wert sind, schauen Sie sich an, was sie mit dem Preis einer einzelnen Instanz machen – dieselbe c6a.8xlarge, eine Region, kalkuliert über alle Compute-Savings-Plan-Laufzeiten und Zahlungsoptionen hinweg (plus On-Demand):

Die Spanne ist enorm: Dieselbe Maschine kostet rund 1,22 $/Stunde On-Demand bis hinunter zu ~0,54 $/Stunde mit einem dreijährigen Compute Savings Plan – eine Differenz von ~56 %, entschieden allein dadurch, wie Sie einkaufen. Und die Abstände sind nicht gleich verteilt: Der Wechsel von einer ein- auf eine dreijährige Laufzeit halbiert den Preis fast, während die Upfront-Wahl (No / Partial / All) nur ein paar Prozent ausmacht. Der Hebel, der wie Kleingedrucktes aussieht – die Laufzeit – ist der, der das Geld wirklich bewegt.

Jede dieser Entscheidungen setzt voraus, dass Sie wissen, wie Ihr Workload über die gesamte Laufzeit aussieht. Bei einem dreijährigen All-Upfront-EC2-Instance-Plan dimensionieren Sie kein Commitment – Sie treffen eine Vorhersage über Ihre Architektur im Jahr 2028. Das ist die eigentliche Schwierigkeit. Die Zahl ist nicht schwer zu berechnen. Die Zukunft, von der sie abhängt, lässt sich schwer vorhersagen.

Die fünf Kräfte, die das Ziel ständig verschieben

Wäre Ihre Nutzung eine flache Linie, wäre das eine Spreadsheet-Übung. Ist sie aber nie. Fünf Kräfte verschieben die "richtige" Zahl immer weiter, nachdem Sie committet haben.

1. Nutzung ist nicht flach. Reale Compute-Ausgaben schwanken von Woche zu Woche – Batch-Jobs, Launches, saisonaler Traffic, das Onboarding eines großen Kunden. Ein Commitment, das auf eine gute Woche dimensioniert ist, wird in einer ruhigen Woche zum Over-Commitment. Dimensionieren Sie auf eine starke Woche mit 70 $/Stunde, während Ihre dauerhafte Baseline eigentlich bei 60 $/Stunde liegt, werden die zusätzlichen 10 $/Stunde in dem Moment, in dem es ruhiger wird, zu ungenutztem Commitment – rund 87.600 $ pro Jahr für Kapazität, die Sie nicht verwenden. Der Rabatt, dem Sie hinterherjagten, ist kleiner als die Verschwendung, die Sie geschaffen haben.

2. Right-Sizing und Migrationen lassen die Baseline schrumpfen. Das ist der Punkt, an dem still und leise am meisten Geld verloren geht. Sie committen auf die heutige Nutzung, dann macht Ihr Team schlicht seinen Job: Es bringt überprovisionierte Instanzen per Right-Sizing auf das richtige Maß, migriert einen Service auf Graviton, refaktoriert einen Monolithen. Ihre Nutzung sinkt – Ihr Commitment nicht. Sie committen auf Ihre Baseline von 60 $/Stunde, dann migriert Ihr Team auf Graviton und die Baseline pendelt sich bei 50 $/Stunde ein. Über Nacht laufen ~10 $/Stunde Commitment ins Leere – bei rund zwei verbleibenden Jahren eines Dreijahresplans etwa 175.000 $, die verloren sind. Sie haben aus Engineering-Sicht alles richtig gemacht und wurden dafür bestraft. Die korrekte Reihenfolge ist die umgekehrte: erst Right-Sizing, dann auf den schlankeren stabilen Zustand committen. Fast niemand macht das, weil Commitment und Right-Sizing in den Backlogs unterschiedlicher Teams leben.

3. Commitments laufen aus – und zwar gebündelt. Ein Savings Plan, den Sie vor einem Jahr gekauft haben, fällt an einem bestimmten Tag weg. Haben Sie mehrere auf einen Schlag gekauft, laufen sie auch auf einen Schlag aus – und Ihre Abdeckung bricht über Nacht ein. Verlängern heißt, die gesamte Dimensionierungsübung erneut durchzuspielen, genau in dem Moment, in dem Sie am wenigsten hinschauen. Verpassen Sie ihn, zahlen Sie für den ausgelaufenen Anteil wieder volle On-Demand-Preise.

4. Ein Abdeckungs-Ziel ist kein Auslastungs-Ergebnis. Sie können 80 % Abdeckung anpeilen und trotzdem bei schlechter Auslastung landen, wenn die Nutzung nach dem Kauf nachlässt. Ziele werden auf Basis der Vergangenheit gesetzt; Auslastung realisiert sich in der Zukunft. Die Lücke dazwischen ist reine Verschwendung – und Sie sehen sie erst, wenn die Rechnung kommt.

5. Die Zeit selbst. Jeder Tag, an dem Sie auf "genug Sicherheit" zum Committen warten, ist ein Tag zu On-Demand-Preisen. Teams schieben Commitments monatelang auf, auf der Jagd nach einer Gewissheit, die nie kommt – und der aufgeschobene Rabatt ist unwiederbringlich verloren. Wie wir es im Beitrag zu den Commitment-Fehlern formuliert haben: Selbst während Migrationen und in unsicheren Phasen ist es besser, einen Teil zu committen, als gar nichts zu committen.

Beachten Sie: Nichts davon sind Planungsfehler. Es ist einfach die Realität. Ihre Infrastruktur soll sich verändern. Das Problem ist nicht, dass sich das Ziel bewegt – sondern dass die meisten Commitment-Prozesse so gebaut sind, als täte es das nicht.

Warum der manuelle Ansatz scheitert

So läuft die Dimensionierung in der Praxis üblicherweise ab.

Einmal pro Quartal öffnet jemand die Savings-Plans-Kaufempfehlung von AWS. AWS blickt auf ein Zeitfenster zurück – wählbar sind 7, 30 oder bis zu 60 Tage – und liefert einen einzigen vorgeschlagenen stündlichen Commitment-Betrag, optimiert auf maximale Ersparnis. Jemand schaut kurz drüber, zieht vielleicht "sicherheitshalber" etwas ab, holt eine Freigabe ein und kauft.

Drei Probleme sind in diesen Ablauf fest eingebaut.

Erstens: Es ist eine einzige Zahl aus einem einzigen Rückblick. Auf maximale Ersparnis optimierte Empfehlungen nehmen an, dass Ihre jüngste Vergangenheit Ihre Zukunft ist, und treiben die Abdeckung hoch. Großartig bei stabiler Nutzung; teuer, sobald sie es nicht ist.

Zweitens: Es ist ein Big-Bang-Kauf. Sie fällen die Commitment-Entscheidung eines ganzen Quartals in einer einzigen Transaktion, an einem einzigen Tag. Liegt dieser Tag zufällig auf dem Höhepunkt einer Nutzungsspitze, haben Sie gerade ein Jahr Commitment an einem Peak verankert.

Drittens: Sie ist bereits veraltet. Bis die Empfehlung geprüft, freigegeben und gekauft ist, sind Tage oder Wochen vergangen und die Nutzung hat sich weiterbewegt. Sie committen nicht auf Ihre aktuelle Realität, sondern auf den Schnappschuss einer Realität, die es schon nicht mehr gibt.

Das tiefere Problem ist der Takt. Die Nutzung ändert sich kontinuierlich; der manuelle Prozess läuft quartalsweise. Sie tasten ein bewegtes Signal viermal im Jahr ab und handeln auf jede Stichprobe Wochen zu spät. Kein noch so akribisches Spreadsheet löst ein Abtastraten-Problem.

Ein besseres Denkmodell: auf die Baseline dimensionieren, dann in Stufen dorthin

Die Lösung besteht in Wahrheit aus zwei getrennten Aufgaben, und es hilft, sie beim Namen zu nennen: Dimensionierung (die richtige Zahl wählen) und Laddering (sicher dorthin kommen). Für beide braucht es ein Umdenken.

Änderung eins – Dimensionierung: an der dauerhaften Baseline verankern. Das ist die Aufgabe, die Zahl zu wählen. Statt zu fragen "Was ist der richtige Dollarbetrag?", entscheiden Sie, wie viel Ihrer anrechenbaren Ausgaben abgedeckt sein soll – verankert an der dauerhaften Baseline, dem Teil, der rund um die Uhr läuft – und der Dollarbetrag ergibt sich daraus. So wird aus einer Schätzung ins Blaue eine Policy, über die Sie fundiert nachdenken können:

• Konservativ (~65 % Abdeckung). Sie schützen die Auslastung und bleiben flexibel. Sie lassen bewusst etwas Ersparnis liegen. Gut für volatile oder sich schnell verändernde Nutzung.
• Ausgewogen (~80 % Abdeckung). Der Standard für die meisten stabilen Produktions-Workloads: nennenswerte Ersparnis mit komfortablem Puffer gegen Einbrüche.
• Aggressiv (~90 % Abdeckung). Maximale Ersparnis, minimaler Puffer. Nur angemessen, wenn Ihre Baseline wirklich stabil und vorhersehbar ist.

Warum nicht einfach immer aggressiv? Weil Abdeckung einen abnehmenden Grenznutzen hat – und der letzte Anteil der gefährliche ist. Der Sockel Ihrer Nutzung – der Teil, der 24/7/365 läuft – lässt sich am sichersten abdecken; dort ist der Rabatt praktisch geschenktes Geld. Je höher Sie die Abdeckung treiben, desto mehr committen Sie auf die variable Spitze Ihrer Nutzung: die Stunden, die nur während Lastspitzen existieren. Genau diese marginalen Ausgaben verschwinden am wahrscheinlichsten – die Abdeckung oberhalb von ~80 % trägt also das meiste Over-Commitment-Risiko und liefert zugleich die unzuverlässigste Ersparnis. Die richtige Strategie ist nicht "alles abdecken", sondern "den stabilen Sockel aggressiv abdecken und die volatile Spitze vorsichtig".

Änderung zwei – Laddering: in kleinen Schritten ans Ziel. Das ist eine andere Aufgabe: nicht was Sie committen, sondern wie Sie dorthin kommen. Statt eines großen Kaufs zerlegen Sie die Distanz zu Ihrem Ziel in eine Serie kleiner, zeitlich gestaffelter Commitments. Laddering löst gleich mehrere der fünf Kräfte auf einmal:

• Kleine, häufige Schritte bedeuten, dass kein einzelner Kauf an einem Peak verankert wird. Sie bauen Ihr Commitment schrittweise auf – nach demselben Prinzip, mit dem Sie per Cost-Averaging gestaffelt in eine Position einsteigen würden.
• Gestaffelte Startdaten bedeuten gestaffelte Abläufe – kein abrupter Abdeckungseinbruch bei der Verlängerung, weil Ihre Pläne nach und nach auslaufen statt alle auf einmal.
• Schrittweises Committen bedeutet, dass Sie stoppen oder verlangsamen können, sobald die Nutzung nachlässt – statt das Over-Commitment ein Jahr später in einem festgezurrten Vertrag zu entdecken.

Halten Sie die beiden Aufgaben aber getrennt. Laddering steuert das Timing – Kaufkonzentration und abrupte Abläufe – nicht die Dimensionierung. Es rettet kein zu aggressives Ziel: Wer langsam auf die falsche Zahl zusteuert, ist am Ende trotzdem over-committed – nur ein paar Wochen später. Erst die Baseline richtig bestimmen, dann per Ladder dorthin.

Der Haken: Auf eine bewegliche Baseline zu dimensionieren, die Abdeckung jede Woche zu prüfen, Abläufe einzukalkulieren und bei Einbrüchen zu pausieren, ist eine wirklich kontinuierliche Aufgabe. Von Hand erledigt ist das eine Teilzeitstelle, die niemand hat. Genau diese Lücke füllt Automatisierung.