Von Dima Kramskoy — Senior Cloud Architect bei DoiT International
Die Frage, die fast alle falsch stellen
Als ich noch Tickets zur Cloud-Optimierung bearbeitet habe, war das die häufigste Frage von Kunden: "Sollen wir Savings Plans oder Reserved Instances nutzen?" Drei-, viermal pro Woche, von unterschiedlichen Kunden.
Es ist die falsche Frage.
Die richtige Frage lautet: Wie sehen Ihre Workloads in 12 Monaten aus?
Warum dieser Perspektivwechsel entscheidend ist: Wer eine Graviton-Migration plant, verbrennt Geld mit Standard RIs, die den Workloads nicht in neue Instance-Familien folgen können. Ein Team mit einem grundsoliden RDS-Cluster, an dessen Konfiguration sich seit zwei Jahren nichts geändert hat, verschenkt mit Compute Savings Plans bares Geld, wenn ein Standard RI 6–9 Prozentpunkte mehr Rabatt bringt.
Die Entscheidung zwischen SP und RI ist keine Produktfrage. Sie ist eine Frage der architektonischen Richtung. Ihre Commitment-Strategie sollte sich an Ihrer Infrastruktur-Roadmap orientieren — nicht umgekehrt.
Und jetzt die unbequeme Wahrheit: Die meisten Kunden, mit denen ich arbeite, wissen nicht, wie ihre Workloads in 12 Monaten aussehen. Sie wissen nicht, ob sie im nächsten Quartal auf Graviton migrieren, auf Container umstellen oder ihre Compute-Last verdoppeln. Das ist kein Planungsversagen — das ist die Realität. Wenn Sie nicht wissen, wohin die Reise geht, ist genau DAS Ihre Antwort. Unsicherheit = Flexibilität. Wählen Sie mindestens Compute Savings Plans — oder noch besser: Lassen Sie ein Tool das Commitment-Risiko komplett für Sie tragen (dazu am Ende mehr).
Ich zeige Ihnen den Rahmen, den ich mit Enterprise-Kunden nutze — auf den Stand 2025–2026 gebracht.
Schnelle Antwort: Entscheidungs-Flowchart
Bevor wir in die Tiefe gehen, hier der schnelle Pfad:
START: Wie sieht Ihr primärer Compute-Workload aus?│├─ Nur EC2, eine Instance-Familie, 12+ Monate stabil│ └─ → EC2 Instance Savings Plan oder Standard RI│ ├─ Capacity Reservation nötig? → Zonal Standard RI│ └─ Einfacheres Management? → EC2 Instance SP│├─ EC2 über mehrere Instance-Familien hinweg│ └─ → Compute Savings Plan│├─ Graviton-Migration geplant (x86 → arm64)│ └─ → Compute Savings Plan (greift automatisch für neue Familie)│├─ Fargate, Lambda oder Serverless-first│ └─ → Compute Savings Plan (einziger Typ, der das abdeckt)│├─ RDS / Aurora / Datenbank-Layer│ └─ Stabile Konfiguration, max. Rabatt? → Standard RI (bis 69 %)│ └─ Multi-Engine, Gen 7+, Flexibilität? → Database SP (bis 35 %)│└─ Aktive Re-Architektur oder Migration weg von AWS └─ → Nicht committen. On-Demand/Spot nutzen, bis stabil.Schneller Vergleich
| Typ | Max. Rabatt | Flexibilität | Geeignet für |
|---|---|---|---|
| Compute SP | Bis 66 % | Beliebige Region, Familie, OS, Service | Modernisierende Organisationen, Serverless, Multi-Region |
| EC2 Instance SP | Bis 72 % | Beliebige Größe/OS innerhalb fester Familie + Region | Stabile EC2-Familie, einfaches Management |
| Standard RI | Bis 72–75 % | Fester Typ + Region (Größenflexibilität bei Regional RI) | Hochstabile Workloads, Capacity Reservation |
| Convertible RI | Bis 54–58 % | Tauschbare Familie/OS (gleiche Region) | Legacy-Flexibilitätsbedarf — weitgehend durch SPs abgelöst |
| Database SP | Bis 35 % | Beliebige berechtigte DB-Engine (nur Gen 7+) | Multi-Engine-DB-Landschaften, Aurora Serverless |
Was sich 2025–2026 geändert hat
Vier wesentliche Verschiebungen seit meinem letzten Kostenoptimierungs-Review:
1. Database Savings Plans gestartet (Dezember 2025)
Die wichtigste FinOps-Ankündigung der re:Invent 2025. Database Savings Plans decken 10 Services ab — Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS und OpenSearch.
Der Haken: nur 1-Jahres-Laufzeiten (keine 3 Jahre), ausschließlich No Upfront, und es sind Gen-7+-Instances erforderlich (db.r7g, db.m7g). Der maximale Rabatt liegt bei rund 35 % — deutlich unter den 69 %, die mit Standard RDS RIs möglich sind. Diese SPs sind also kein Ersatz für DB RIs — sie sind eine Flexibilitätsoption für Organisationen mit vielfältigen, sich entwickelnden Datenbanklandschaften.
2. Sharing-Beschränkungen für RI/SP (Juni 2025)
AWS hat MSPs und Resellern untersagt, RI-/SP-Rabatte über mehrere Endkunden hinweg zu teilen. Wer über einen Partner einkauft, dessen Commitments sind jetzt auf die eigene Nutzung beschränkt. Direkte Enterprise-Käufer: weitgehend nicht betroffen.
3. Group Sharing Feature — GA (November 2025)
Dieses Feature ist weitgehend unter dem Radar geblieben, löst aber einen echten Pain Point. Sie können jetzt exakt steuern, welche Accounts in Ihrer Organisation von geteilten Commitments profitieren — mit zwei Modi:
- Prioritized Group Sharing: Das Commitment wird zuerst auf eine festgelegte Gruppe angewendet und fließt erst dann in die übrige Organisation.
- Restricted Group Sharing: Vollständige Isolation — nur die festgelegte Gruppe profitiert.
Damit ist das "das falsche Team profitiert von unserem RI"-Problem, das Consolidated Billing jahrelang plagte, endlich gelöst. Gruppen werden über Cost Categories definiert. Wer eine Multi-BU-Organisation mit Chargeback-Modellen betreibt, für den ändert das die Spielregeln.
4. RIs sind NICHT abgekündigt
Trotz wiederkehrender Spekulationen werden Reserved Instances weiterhin vollständig unterstützt. Die AWS-Preisseiten werden aktiv gepflegt (zuletzt aktualisiert im Mai 2026), Cost Explorer generiert weiterhin RI-Empfehlungen, und der RI Marketplace ist weiterhin aktiv. AWS bevorzugt Savings Plans klar in Neuentwicklung und Dokumentation — aber RIs verschwinden nicht.
Noch ein Hinweis: Savings Plans mit Commitments über 100 $/Stunde können nicht zurückgegeben werden. Unter 100 $/Stunde haben Sie ein 7-Tage-Fenster innerhalb desselben Kalendermonats, maximal 10 Rückgaben pro Jahr. Im Enterprise-Maßstab sind diese Commitments permanent. Planen Sie entsprechend.
Deep Dive: Compute SP vs. EC2 SP vs. Standard RI vs. Convertible RI
Hier der vollständige Vergleich, den ich mir gewünscht hätte, als ich diese Entscheidungen treffen musste:
| Dimension | Compute SP | EC2 Instance SP | Standard RI | Convertible RI |
|---|---|---|---|---|
| Max. Rabatt | 66 % | 72 % | 72–75 % | 54–58 % |
| Commitment-Basis | $/Stunde (beliebige Compute) | $/Stunde (Familie + Region) | Instance-Typ + Region + OS + Tenancy | Instance-Familie + Region |
| Instance-Familie | Beliebig — greift automatisch | Pro Plan festgelegt | Festgelegt | Tauschbar |
| Instance-Größe | Beliebig — greift automatisch | Beliebig — greift automatisch | Flexibel (Regional RI) | Flexibel |
| OS-Flexibilität | Beliebig | Beliebig | Festgelegt | Tauschbar |
| Region | Regionsübergreifend ✅ | Feste Region | Feste Region | Feste Region |
| Lambda/Fargate | ✅ | ❌ | ❌ | ❌ |
| Capacity Reservation | ❌ | ❌ | ✅ (Zonal RI) | ❌ |
| Weiterverkaufbar | ❌ | ❌ | ✅ (RI Marketplace*) | ❌ |
| Kündbar | Begrenzt (≤100 $/h, 7 Tage) | Begrenzt | ❌ | ❌ |
| Verwaltungsaufwand | Niedrig | Niedrig | Hoch | Mittel |
*EDP-Kunden dürfen nicht über den RI Marketplace verkaufen.
Reihenfolge der Rabattanwendung (wichtig)
AWS wendet Rabatte in dieser Reihenfolge an:
- Reserved Instances zuerst (auf passende Nutzung)
- EC2 Instance Savings Plans als Zweites
- Compute Savings Plans zuletzt (mit dem breitesten Anwendungsbereich)
Innerhalb jeder Stufe wird zuerst die Nutzung mit dem höchsten Einsparpotenzial abgedeckt. Sie können also alle drei problemlos kombinieren — AWS optimiert die Anwendung automatisch.
Workload-Portabilität: Wann Flexibilität mehr zählt als Rabatt
Die Rabattlücke zwischen Compute SP (66 %) und EC2 Instance SP (72 %) beträgt rund 6 Prozentpunkte. Bei typischen Enterprise-Konditionen (1 Jahr, No Upfront) schrumpft sie auf 2–4 Punkte. Lassen Sie mich zeigen, wann sich dieser "Flexibilitätsaufschlag" eindeutig lohnt.
Graviton-Migration
Umstieg von x86 (m5, c5, r5) auf Graviton (m7g, c7g, r7g):
- Compute SP: Reibungslos. Der Rabatt greift automatisch für Graviton-Instances, sobald Sie sie starten.
- EC2 Instance SP: Bricht. m5 ≠ m7g — unterschiedliche Instance-Familie.
- Standard RI: Für neue Instances komplett unbrauchbar. Totes Commitment.
- Convertible RI: Erfordert manuellen Tausch zu gleichem oder höherem Wert und bleibt regionsgebunden.
Wenn Sie auf dem Weg zur Graviton-Migration sind (und das sollten Sie sein — 20–40 % besseres Preis-Leistungs-Verhältnis), sind Compute SPs strukturell überlegen.
Containerisierung / Wechsel zu Serverless
Umstieg von EC2 auf ECS/Fargate oder Lambda:
- Compute SP: Deckt Fargate und Lambda automatisch ab. Ihr Rabatt wandert mit.
- Alles andere: Null Abdeckung für Container- oder Serverless-Compute.
Regionsübergreifende Expansion
Eröffnung einer neuen Region oder Konsolidierung von 4 auf 2 Regionen:
- Compute SP: Der Rabatt gilt global über alle Regionen.
- Alle anderen: Regionsgebunden. Konsolidierung macht Ihre Commitments wertlos.
Die Rechnung
Bei 5 Mio. $ jährlichen Compute-Ausgaben kostet eine Lücke von 6 Prozentpunkten über 3 Jahre rund 300.000 $. Klingt erheblich — bis Sie merken, dass eine gescheiterte Graviton-Migration (weil Sie sich den Wechsel weg von festgelegten RIs nicht leisten können) Sie 20–40 % Performance-Gewinn über Ihre gesamte Flotte kostet. Der Flexibilitätsaufschlag ist eine Versicherung, und zwar eine günstige.
Die Anti-Patterns (was passiert, wenn Sie es falsch machen)
In über 10 Jahren Cloud-Kostenoptimierung habe ich gesehen, wie diese Fehler Organisationen Millionen gekostet haben. Hier die fünf teuersten:
Anti-Pattern 1: Auf den Peak statt auf die Baseline committen
Der Fehler: Commitments auf Basis der maximal beobachteten Nutzung kaufen.
Was passiert: Sie committen 50 $/Stunde, weil das Ihr Montagmorgen-Peak ist. Ihre dauerhafte Baseline liegt bei 35 $/Stunde. Sie nutzen Ihr Commitment zu 70 % aus — die anderen 30 % sind reine Verschwendung.
Die Kosten: Bei einem 50-$/Stunde-Commit ergeben 30 % Waste 131.000 $ pro Jahr, die verpuffen.
Die Lösung: Committen Sie auf 70–80 % Ihrer dauerhaften Untergrenze (mit 60–90 Tagen Daten). Spitzen decken Sie mit Spot und On-Demand ab.
Anti-Pattern 2: Standard RIs für Workloads, die kurz vor der Migration stehen
Der Fehler: 3-Jahres-Standard-RIs für eine m5-Flotte kaufen, obwohl eine Graviton-Migration auf der Roadmap steht.
Was passiert: Nach sechs Monaten sind Sie bereit für m7g. Ihre Standard RIs können nicht mitziehen. Sie sind nicht konvertierbar. Als EDP-Kunde können Sie sie auch nicht über den Marketplace verkaufen. Sie zahlen für Instances, die Sie gar nicht mehr betreiben.
Die Kosten: Ein totes 3-Jahres-RI auf r5.4xlarge: rund 278 $/Monat Commitment, das 30 Monate lang null Nutzen bringt = 8.340 $ Verschwendung pro Instance. Skalieren Sie das über eine Flotte.
Die Lösung: Wenn innerhalb des Commitment-Fensters irgendeine architektonische Änderung geplant ist — Compute SPs nutzen.
Anti-Pattern 3: Commitments stillschweigend auslaufen lassen
Der Fehler: Kein Ablauf-Monitoring, kein Renewal-Queueing.
Was passiert: Eine Charge RIs läuft an einem Dienstag aus. Niemand merkt es bis zur Monatsendabrechnung. Ihr effektiver Tarif springt von 278 $/Monat auf 736 $/Monat pro r5.4xlarge — eine Kostensteigerung von über 62 % über Nacht.
Die Kosten: Eine Flotte von 20 Instances, die nur einen Monat lang auf On-Demand zurückfällt: rund 9.160 $ unerwartete Mehrkosten.
Die Lösung: AWS-Budgets-Ablaufwarnungen + vorgemerkte Savings-Plan-Käufe vor dem Ablaufdatum.
Anti-Pattern 4: Non-EC2-Compute ignorieren
Der Fehler: Nur auf EC2 committen, während 40 % oder mehr der Compute-Ausgaben in Lambda, Fargate oder EKS liegen.
Was passiert: Erhebliche Serverless-/Container-Ausgaben laufen weiter zu vollen On-Demand-Tarifen. Organisationen, die nur ihre EC2-Commitments optimieren, glauben, sie seien "fertig" — und lassen bei ihren am schnellsten wachsenden Workloads 20–30 % Einsparungen liegen.
Die Kosten: 200.000 $/Jahr Lambda + Fargate auf On-Demand, wo ein Compute SP 20–66 % sparen würde = 40.000–132.000 $/Jahr entgangene Ersparnisse.
Die Lösung: ALLE berechtigten Services prüfen. Ein einziger Compute SP deckt EC2, Lambda und Fargate gleichzeitig ab.
Anti-Pattern 5: Commitment mitten in der Re-Architektur
Der Fehler: Commitments kaufen, während Sie Right-Sizing, Re-Platforming oder eine Migration durchführen.
Was passiert: Sie committen heute 80 $/Stunde. In den nächsten 6 Monaten senkt die Optimierung Ihre Baseline auf 55 $/Stunde. Für den Rest Ihrer Laufzeit sind Sie auf 25 $/Stunde Waste festgenagelt.
Die Kosten: 25 $/Stunde × 8.760 verbleibende Stunden einer 1-Jahres-Laufzeit = 219.000 $ totes Commitment.
Die Lösung: Erst stabilisieren, dann committen. Nutzen Sie gestaffelte Commitments passend zu Ihrem Sicherheitsgrad — kleine Commitments während der Migration, größere, sobald sich die Nutzungsmuster festigen.
Entscheidungsrahmen
Das ist die Tabelle für den Screenshot:
| Wenn Ihr Workload so aussieht … | Wählen Sie | Weil |
|---|---|---|
| Stabile EC2-Flotte, einzelne Familie, keine Änderungen für 12+ Monate geplant | EC2 Instance SP oder Standard RI | Maximaler Rabatt (72–75 %) bei geringem Risiko toter Commitments |
| EC2-Flotte mit geplanter Graviton-Migration innerhalb von 12 Monaten | Compute SP | Greift automatisch für neue Instance-Familie, ohne Eingreifen |
| Multi-Region-Architektur oder geplante Regionserweiterung | Compute SP | Einziger Commitment-Typ, der regionsübergreifend funktioniert |
| Wachsende Lambda-/Fargate-Ausgaben (>20 % der Compute) | Compute SP | Einziger Typ, der Serverless- und Container-Compute abdeckt |
| RDS-/Aurora-Cluster, gleiche Konfiguration seit 18+ Monaten | Standard RI | Tiefster DB-Rabatt (bis 69 %) für nachweislich stabile Datenbanken |
| Mehrere DB-Engines, Gen-7+-Instances, sich entwickelnde DB-Landschaft | Database SP | Flexibilität über 10 Services, deckt Aurora Serverless ab |
| Garantierte Kapazität für Compliance/SLA erforderlich | Zonal Standard RI | Einziger Commitment-Typ mit Capacity Reservation |
| Aktive Re-Architektur, Migration läuft | Nicht committen | Warten, bis sich die Nutzung stabilisiert; On-Demand/Spot nutzen |
Die mehrstufige Strategie (was ich den meisten Organisationen empfehle)
Setzen Sie nicht auf einen einzigen Typ. Kombinieren Sie sie in Schichten:
- Layer 1 — Compute SPs (60–80 % der Baseline): Decken Sie Ihre minimale Compute-Untergrenze mit maximaler Flexibilität ab.
- Layer 2 — EC2 Instance SPs: Legen Sie sie obendrauf für Familien, bei denen Sie sicher sind (sichert zusätzliche 6 Prozentpunkte Rabatt).
- Layer 3 — Standard RIs: Für hochstabile Data-Tier-Workloads und Kapazitätsbedarf.
- Layer 4 — On-Demand/Spot: Variable und unsichere Workloads ohne Commitment lassen.
Starten Sie mit 1-Jahres-Laufzeiten, um Muster zu validieren. Nach 12 Monaten stabiler Nutzungsdaten ergänzen Sie 3-Jahres-Laufzeiten für Ihre erprobte Baseline (15–22 Prozentpunkte tieferer Rabatt).
Wie DoiT das automatisiert
Erinnern Sie sich, was ich über Unsicherheit gesagt habe? Die meisten Kunden wissen nicht, wie ihre Workloads in 12 Monaten aussehen. Genau dafür wurde FlexSave for Compute gebaut.
Der Pitch in einem Satz: Sie bekommen die Rabattraten eines 1-Jahres-Savings-Plans, ohne selbst zu committen. DoiT trägt das Risiko.
Das macht es im Detail:
- Überwacht Ihre On-Demand-Nutzung — analysiert, was läuft, was stabil ist, was sich verändert.
- Wendet automatisch optimale Rabattmechanismen an — deckt berechtigte workloads ab, die nicht bereits durch Ihre eigenen RIs/SPs abgedeckt sind.
- Passt sich laufend an — Migration zu Graviton? Skalierung nach unten? Wechsel zu Fargate? FlexSave passt sich an, ohne dass Sie eine Tabelle anfassen müssen.
- Kein Commitment von Ihrer Seite — DoiT trägt das Commitment-Risiko. Sie bekommen den Rabatt. Jederzeit kündbar.
- Deckt den gesamten Compute-Stack ab — EC2, ECS, EKS, Fargate, Lambda, SageMaker (nicht nur EC2).
Für Datenbanken: Die neuen Database Savings Plans von AWS (Dez. 2025) sind Ihre beste Wahl für RDS und Aurora. FlexSave konzentriert sich auf Compute — dort, wo Unsicherheit und Flexibilitätsbedarf am größten sind.
Für den Überblick über Ihr gesamtes Commitment-Portfolio liefert DoiT Cloud Analytics Auslastung, Abdeckung und Waste-Metriken an einem Ort — damit Sie jederzeit wissen, ob Ihre Strategie aufgeht.
Die Kombination löst beide Probleme: FlexSave kümmert sich um die "Ich weiß nicht, was als Nächstes kommt"-Ausführung, Cloud Analytics liefert den Überblick. Unsicherheit ist kein Problem, wenn Ihr Tooling sich mit Ihnen weiterentwickelt.
TL;DR
Compute SPs sind für die meisten Organisationen die Standardwahl — der Flexibilitätsaufschlag (2–4 Prozentpunkte bei typischen Konditionen) lohnt sich fast immer für Teams, bei denen irgendeine architektonische Veränderung auf der Roadmap steht.
Standard RIs gewinnen weiterhin bei hochstabilen workloads — Datenbank-Layer, Compliance-getriebene Capacity Reservations und workloads mit 18+ Monaten nachgewiesener Stabilität.
Database Savings Plans (neu im Dez. 2025) sind eine Flexibilitäts-, keine Rabattwahl — 35 % gegenüber 69 % bei Standard RIs. Wählen Sie sie für Multi-Engine-, Gen-7+-Landschaften.
Kombinieren Sie Ihre Commitments in Schichten — Compute SP als Basis, EC2 Instance SP für Familien, bei denen Sie sicher sind, Standard RIs für stabile Datenbanken, On-Demand für alles andere.
Niemals während laufender Migration committen — erst stabilisieren, dann committen. Die Kosten toter Commitments übersteigen immer die Kosten des Wartens.
Die richtige Commitment-Strategie zielt nicht auf maximalen Rabatt — sie passt das Commitment an Ihre architektonische Richtung an.
Bereit, das nicht länger manuell zu managen? Buchen Sie eine Demo und sehen Sie, wie FlexSave Ihre AWS-Commitments automatisch optimiert.
Dima Kramskoy ist Senior Cloud Architect bei DoiT International, mit über 20 Jahren in der Softwareentwicklung, 10 AWS-Zertifizierungen und AWS Community Builder (2026). Er ist auf FinOps und Cloud-Kostenoptimierung für Enterprise-Organisationen spezialisiert.