Reserved Instances (RI's) en Savings Plans zijn de twee grote commitment-modellen van AWS — en eerlijk gezegd, de keuze tussen die twee kan je organisatie tienduizenden euro's per jaar schelen. In 2026 is dat verschil belangrijker dan ooit. Met de opmars van Graviton4, steeds complexere workloads en multi-region setups zie ik nog altijd teams die de verkeerde optie aanklikken (vaak vanuit oude reflexen uit 2019). Deze gids legt precies uit welke optie meer bespaart op basis van jouw workload, met concrete rekenvoorbeelden, dekkingsstrategieën en wat scripts om het hele proces te automatiseren.
Reserved Instances vs Savings Plans: De Snelle Vergelijking
Beide modellen geven kortingen tot ongeveer 72% ten opzichte van On-Demand prijzen, in ruil voor een commitment van 1 of 3 jaar. Het cruciale verschil zit 'm in flexibiliteit en toepasbaarheid:
- Reserved Instances — Commitment op specifieke instance families in een specifieke regio. Hoogste korting voor stabiele workloads, maar bar weinig flexibiliteit.
- Compute Savings Plans — Commitment op een dollarbedrag per uur dat geldt voor EC2, Fargate en Lambda in elke regio, elke family en elke OS. Maximale flexibiliteit.
- EC2 Instance Savings Plans — Commitment op een dollarbedrag per uur binnen één specifieke EC2 instance family in één regio. Hogere korting dan Compute Savings Plans, maar weer minder flexibel.
Korting per type in 2026
| Model | 1-jaar (no upfront) | 3-jaar (all upfront) | Flexibiliteit |
|---|---|---|---|
| Standard RI | ~40% | ~62% | Laag |
| Convertible RI | ~31% | ~54% | Medium |
| EC2 Instance Savings Plan | ~40% | ~62% | Medium |
| Compute Savings Plan | ~27% | ~50% | Hoog |
Wanneer Kies je Reserved Instances?
Sinds AWS Convertible RI's stapsgewijs heeft afgebouwd en in 2024 stopte met het uitgeven van nieuwe Convertible RI's voor sommige families, zijn Standard RI's vooral nog relevant voor één scenario: RDS, ElastiCache, OpenSearch en Redshift. Savings Plans dekken die managed database services namelijk nog steeds niet. Punt. Voor deze diensten zijn Reserved Instances dus simpelweg je enige commitment-optie.
RDS Reserved Instance voorbeeld
Stel je hebt een db.r6g.2xlarge Multi-AZ in eu-west-1 die 24/7 draait:
- On-Demand: ~$1,008/uur × 8.760 = $8.830/jaar
- 3-year RI All Upfront: ~$3.350 totaal = $1.117/jaar (effectief 87% korting)
- Besparing: ~$7.713 per database per jaar
Heb je tien van die databases draaien? Dan praten we over bijna $80k per jaar die je laat liggen door dit níet te doen. Best pittig.
Wanneer Kies je Savings Plans?
Voor alles wat met compute te maken heeft — EC2, Fargate, Lambda — zijn Savings Plans in 2026 bijna altijd de betere keuze. De reden? Workloads veranderen. Je migreert van x86 naar Graviton, schaalt regio's in en uit, of verschuift werk tussen EC2 en Fargate. Savings Plans volgen die veranderingen automatisch.
Hoe Savings Plans precies werken
Je commit aan een dollarbedrag per uur (bijvoorbeeld $10/uur). AWS past je commitment dan automatisch toe op de eligible uses met de hoogste kortingspercentages eerst:
- Eerst op EC2 (hoogste discount tier)
- Daarna op Fargate
- Tot slot op Lambda
Verbruik je in een uur méér dan je commitment? Dan betaal je het meerdere tegen On-Demand prijzen. Verbruik je minder? Dan verlies je het ongebruikte deel. Je betaalt nooit minder dan je commitment — daar moet je gewoon goed van bewust zijn.
Praktisch voorbeeld: gemengde workload
Een SaaS-platform draait:
- 20×
m6i.xlargewebservers in eu-west-1 (~$2,80/uur On-Demand basis) - 5×
c6i.2xlargeworkers in eu-central-1 - Fargate-clusters voor batch processing (~$3/uur gemiddeld)
- Lambda functions (~$0,50/uur gemiddeld)
Met een 3-jaar Compute Savings Plan No Upfront op $5,50/uur dek je 80% van de base-load over alle services in beide regio's, met één enkele commitment. Een equivalent in Reserved Instances zou minstens vier aparte RI-aankopen vereisen — zonder enige garantie dat ze nog relevant zijn als je over een halfjaar besluit naar Graviton te migreren.
Dekkingsstrategie: De 70/20/10 Regel
Een van de meest voorkomende fouten? Overcommitten. Onder druk om te besparen kopen FinOps-teams commitments voor 100% van hun verbruik, om vervolgens te ontdekken dat seizoensschommelingen of architectuurwijzigingen het werkelijke verbruik flink omlaag trekken. De industriestandaard voor 2026:
- 70% — Dek af met 3-jaar Compute Savings Plans (hoogste korting, laagste risico voor stabiele baseline)
- 20% — Dek af met 1-jaar Compute Savings Plans (voor groei en gemiddelde workload-fluctuatie)
- 10% — Laat staan op On-Demand of Spot (voor onverwachte pieken en flexibiliteit)
Coverage analyseren in CloudWatch en Cost Explorer
aws ce get-savings-plans-coverage \
--time-period Start=2026-04-01,End=2026-05-01 \
--granularity DAILY \
--metrics SpendCoveredBySavingsPlans OnDemandCost \
--filter '{"Dimensions":{"Key":"REGION","Values":["eu-west-1"]}}'De ideale coverage ratio ligt tussen de 70-85%. Onder de 70% laat je geld liggen, boven de 85% loop je risico op waste door overcommitment. Simpel.
Stap-voor-stap: Commitments Inkopen in 2026
Stap 1 — Analyseer 90 dagen historie
Open Cost Explorer en filter op je rekentaken. Kijk naar uurpieken, niet alleen het maandgemiddelde (een fout die ik vroeger ook regelmatig maakte). Een lookback van 60-90 dagen geeft een realistisch beeld; 30 dagen is gewoon te kort om seizoenseffecten te vangen.
Stap 2 — Bereken je commitment-baseline
Gebruik onderstaand Python-script om je veilige commitment-niveau te berekenen op basis van het 70e percentiel van het uurlijks verbruik:
import boto3
import numpy as np
from datetime import datetime, timedelta
ce = boto3.client('ce')
end = datetime.utcnow().date()
start = end - timedelta(days=90)
response = ce.get_cost_and_usage(
TimePeriod={'Start': str(start), 'End': str(end)},
Granularity='HOURLY',
Metrics=['UnblendedCost'],
Filter={
'Dimensions': {
'Key': 'SERVICE',
'Values': ['Amazon Elastic Compute Cloud - Compute',
'AWS Lambda',
'Amazon Elastic Container Service']
}
}
)
hourly_costs = [float(r['Total']['UnblendedCost']['Amount'])
for r in response['ResultsByTime']]
baseline_p70 = np.percentile(hourly_costs, 70)
print(f"Aanbevolen Compute Savings Plan commitment: ${baseline_p70:.2f}/uur")
print(f"Geschatte besparing (3-jaar): ${baseline_p70 * 8760 * 3 * 0.50:,.0f}")Stap 3 — Kies een betalingsmodel
All Upfront geeft de hoogste effectieve korting (~5-7% extra ten opzichte van No Upfront), maar No Upfront houdt je werkkapitaal lekker flexibel. Partial Upfront zit ertussenin. Voor de meeste organisaties is No Upfront de juiste keuze: het marginale rendement van 5% korting weegt zelden op tegen de cashflow-impact, vooral niet als je nog groeit.
Stap 4 — Implementeer in tranches
Koop nooit één grote Savings Plan op één datum. Verdeel je commitments in tranches van bijvoorbeeld 25% per maand, gespreid over een kwartaal. Dit voorkomt dat al je commitments tegelijk vervallen en geeft je flexibiliteit om bij te sturen als je workload verschuift.
Reserved Instances en Savings Plans Combineren
De optimale 2026-strategie voor de meeste enterprises is een gelaagde aanpak:
- Koop RDS Reserved Instances voor je database-baseline (1-3 jaar)
- Voeg een 3-jaar Compute Savings Plan toe voor je compute-baseline (70% coverage)
- Voeg een 1-jaar Compute Savings Plan toe voor groei (15-20% extra coverage)
- Gebruik Spot Instances voor batch en fault-tolerant workloads
- Laat 10% op On-Demand voor pieken
Voorbeeld besparing: $500K cloud spend
| Component | On-Demand | Met commitments | Besparing |
|---|---|---|---|
| EC2 (70% RI/SP) | $300.000 | $140.000 | $160.000 |
| RDS (90% RI) | $80.000 | $32.000 | $48.000 |
| Fargate (Compute SP) | $60.000 | $36.000 | $24.000 |
| Lambda (Compute SP) | $20.000 | $13.000 | $7.000 |
| Overig (On-Demand) | $40.000 | $40.000 | $0 |
| Totaal | $500.000 | $261.000 | $239.000 (48%) |
Bijna de helft van je rekening, zonder dat er ook maar één regel applicatiecode hoeft te veranderen. Dat is waarom dit onderwerp er écht toe doet.
Vergelijkbare Modellen in Azure en GCP
Azure: Reservations vs Savings Plan for Compute
Azure introduceerde in 2022 een Savings Plan for Compute model dat sterk lijkt op AWS Compute Savings Plans. Azure Reservations daarentegen werken meer als AWS Standard RI's. In 2026 is de keuze voor Azure-workloads:
- Savings Plan for Compute: voor flexibele compute (VM's in verschillende regions/sizes)
- Reservations: voor SQL Database, Cosmos DB, Synapse en andere managed services
GCP: Committed Use Discounts (CUDs)
GCP biedt twee CUD-typen: Resource-based CUDs (vergelijkbaar met RI's, voor specifieke machine types per regio) en Spend-based CUDs (vergelijkbaar met Compute Savings Plans, voor een dollarbedrag per uur op Compute Engine en Cloud Run). In 2026 dekken Flex CUDs nu ook Cloud Run en GKE Autopilot — een hele welkome uitbreiding, vooral als je serverless-first werkt.
Veelvoorkomende Fouten en Hoe Ze te Vermijden
Fout 1: Standard RI's kopen voor compute
Tenzij je een hele specifieke reden hebt (zoals capacity reservation), zijn Compute Savings Plans bijna altijd beter. De flexibiliteit is dat kleine verschil in maximale korting méér dan waard.
Fout 2: 100% dekking nastreven
Je betaalt gewoon voor ongebruikte commitments. Houd 10-20% van je workload op On-Demand of Spot — die buffer is geen verspilling, dat is verzekering.
Fout 3: Linked accounts negeren
In AWS Organizations stromen onbenutte commitments automatisch naar andere accounts. Maar als je RIs/SPs koopt in een lege management account, mis je deze pooling. Koop dus altijd in een account met daadwerkelijk verbruik, óf in het management account met "RI sharing" enabled.
Fout 4: Niet automatiseren
Gebruik tools zoals AWS Compute Optimizer en third-party FinOps platformen (ProsperOps, Vantage, Spot.io) voor continue commitment-optimalisatie. Handmatig commitment management werkt simpelweg niet meer op enterprise-schaal in 2026. Je verliest tijd én geld.
Veelgestelde Vragen
Wat is beter: Reserved Instances of Savings Plans?
Voor EC2, Fargate en Lambda zijn Compute Savings Plans in 2026 bijna altijd beter vanwege de flexibiliteit. Voor RDS, ElastiCache, Redshift en OpenSearch moet je Reserved Instances gebruiken, omdat Savings Plans deze services nu eenmaal niet dekken.
Kan ik Reserved Instances en Savings Plans tegelijk hebben?
Ja, en dat is juist de aanbevolen strategie. RI's worden eerst toegepast, daarna Savings Plans. Door beide te combineren dek je managed services (RI) én compute flexibel (SP) optimaal af.
Wat gebeurt er als ik mijn Savings Plan niet volledig benut?
Je betaalt nog steeds het volledige commitment-bedrag per uur, ook als je verbruik lager ligt. Daarom is een coverage ratio van 70-85% optimaal — onder of boven dat gemiddelde liggen risico's én kansen.
Hoe lang duurt het voordat Savings Plans actief zijn?
Compute Savings Plans worden meestal binnen enkele minuten geactiveerd na aankoop. Reserved Instances kunnen tot 30 minuten duren. Beide worden geprorateerd vanaf het moment van activering.
Kan ik Savings Plans annuleren of verkopen?
Nee, Savings Plans zijn niet annuleerbaar en niet overdraagbaar. Standard Reserved Instances kun je wél verkopen op de Reserved Instance Marketplace, mits ze gekocht zijn in een geschikt account-type. Juist daarom is voorzichtig dimensioneren zo cruciaal.
Conclusie
In 2026 is de keuze tussen Reserved Instances en Savings Plans bijna altijd geen "of/of", maar "en/en". Gebruik RI's voor managed services waar Savings Plans niet werken, en zet Compute Savings Plans in voor al je flexibele compute. Pas de 70/20/10-regel toe, automatiseer je analyse, en koop in tranches. Met deze aanpak realiseer je 40-55% structurele besparing op je cloud-rekening — zonder operationele risico's of nachtelijke paniektelefoontjes.