WAF-COST-080 – Commitment & Reserved Capacity Planning
Beschreibung
Compute-Ressourcen mit dauerhafter Auslastung >= 70% über 30 Tage MÜSSEN durch Reserved Instances
oder Savings Plans abgedeckt sein. Alle persistenten On-Demand-Compute-Ressourcen MÜSSEN den Tag
capacity-commitment tragen, der den Reservierungsstatus dokumentiert.
Spot/Preemptible Instances sind für variable und unterbrechbare Workloads zu bevorzugen.
Rationale
Baseline-Produktions-Workloads dauerhaft auf On-Demand zu betreiben ist eine strukturelle Ineffizienz. Reserved Instances und Savings Plans bieten 30–60% Kosteneinsparung für stabile Workloads. Der häufigste Commitment-Fehler: Keine Reservierungen, weil der Workload als variabel eingeschätzt wird – obwohl er in der Praxis ein stabiles Baseline-Muster hat.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
On-Demand-Aufpreis für Baseline |
30–60% Mehrkosten für Baseline-Workloads ohne Reservierungen – monatlich und strukturell. |
Ungenutzte Reserved Instances |
RIs für Workloads, die geändert oder abgeschaltet wurden, erzeugen Fixkosten ohne Wert. |
Falsches Commitment-Timing |
Long-Term-Reservierungen vor Stabilitätsnachweis: Wenn Workload sich ändert, ist die RI wertlos. |
Commitment-Strategie
Wann reservieren?
-
Auslastung >= 70% über 30 Tage → Reservierungskandidat
-
Erst nach 30 Tagen Baseline-Messung committed werden
-
Compute Savings Plans bevorzugen gegenüber EC2-RIs (mehr Flexibilität beim Rightsizing)
Commitment-Typen
| Typ | Kosteneinsparung | Flexibilität |
|---|---|---|
1yr No-Upfront Reserved |
~30–40% |
Kein Voraus-Commitment; monatlich kündbar innerhalb von 12 Monaten |
1yr All-Upfront Reserved |
~40–50% |
Vollständige Vorauszahlung; keine Flexibilität |
3yr No-Upfront Reserved |
~50–60% |
Längerer Commitment-Zeitraum; höheres Risiko bei Workload-Änderung |
Compute Savings Plan |
~20–40% |
Flexibel über Instanztypen, Familien und Regionen |
Spot/Preemptible |
Bis zu 90% |
Nur für unterbrechbare Workloads; kann jederzeit zurückgenommen werden |
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Alles On-Demand |
Keine Reservierungen; keine Auslastungsmessung. |
2 |
Erste Reservierungen vorhanden |
Einige RIs ohne systematische Auslastungsanalyse. |
3 |
Baseline vollständig reserviert |
Alle Workloads mit >= 70% Auslastung über 30d durch RI/SP abgedeckt; |
4 |
Savings Plans optimiert |
Compute-Savings-Plans statt EC2-RIs; RI-Ablaufdaten-Alerts 90 Tage vorher. |
5 |
ML-gestützte Commitment-Optimierung |
Cloud-Provider-Commitment-Empfehlungen automatisch verarbeitet; Spot-Maximierung. |
Terraform Checks
waf-cost-080.tf.aws.ec2-capacity-commitment-tag
Prüft: EC2-Instanzen müssen ihren Reservierungsstatus als Tag deklarieren.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: capacity-commitment-Tag auf alle Compute-Ressourcen setzen.
Erlaubte Werte: reserved, savings-plan, spot, on-demand, reviewed.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
IaC |
✅ Pflicht |
Terraform Compute-Ressourcen mit |
Config |
✅ Pflicht |
RI/SP-Utilization-Report (quartalsweise, Ziel: >= 80%). |
Process |
Optional |
Quarterly RI-Portfolio-Review-Protokoll mit Ablaufdaten und Coverage-Gaps. |
Config |
Optional |
Savings-Plans-Empfehlungsreport aus AWS Cost Management. |
Regulatorisches Mapping
| Framework | Controls |
|---|---|
ISO 27001:2022 |
A.5.36 – Compliance with policies, rules and standards; A.8.1.1 – Access control strategy; A.8.10 – Information deletion; A.8.24 – Use of cryptography |
ISO 20000-1:2018 |
9.4.1 – Configuration management; 9.4.2 – Configuration records; 10.2.2 – Financial management; 10.2.4 – Budgeting and accounting |
BSI C5:2020 |
COM-01 – Network and service security; COM-02 – Cloud monitoring; GOV-01 – Governance, risk and compliance |
AWS Well-Architected Framework |
Cost Optimization Pillar – Cost allocation tagging; Financial Security – Budgeting and forecasting |
Azure Well-Architected Framework |
Cost management – Tagging; Governance – Resource governance; Cost optimization – Cost allocation |
Google Cloud Architecture Framework |
Organization and folders – Tagging; Billing – Cost allocation; Resource management – Resource hierarchy |
FinOps Foundation |
Core Module – Tagging standards; Management Layer – Cost attribution; Open Module – Financial accountability |
GDPR |
Art. 28 – Processor obligations; Art. 32 – Security of processing (cost of security measures) |
CSRD |
ESRS G1 – Governance – Disclosure of information; ESRS M1 – Materiality – Disclosure of information |
NIST CSF 2.0 |
GV.PO – Policy; FR.AN – Analysis; RP.RP – Recovery planning |
CIS Controls v8 |
CIS 2 – Inventory and Control of Software Assets; CIS 2.1 – Software inventory; CIS 2.2 – Hardware inventory |
TISAX |
Information security – Resource management |
ANSSI SecNumCloud |
Domain – Financial management; Domain – Resource management |
BIO |
BIO – Financieel beheer |
ENS High |
org.2 – Control de gestión; op.exp.1 – Gestión de incidentes |
UK NCSC CAF |
A2 – Financial management; A3 – Resource management |
CMMC 2.0 |
AC.L2-3.1.1 – Access control policy |
IRAP |
ISM – Financial management |
CCCS PBMM |
CM-6 – Configuration management |
MAS TRM |
Ch.6 – Financial management |
ISMAP |
Resource management and cost control |
FISC |
Operational measures – Financial management |