Cloud Database Kosten Besparen (2026)

Waarom zijn clouddatabases zo duur — en hoe breng je de kosten omlaag?

Laten we eerlijk zijn: databases zijn vrijwel altijd de grootste kostenpost op je cloudfactuur. Onderzoek van BCG laat zien dat organisaties gemiddeld 30% van hun cloudbudget verspillen door gebrek aan gestructureerd kostenbeheer. En bij databases is dat probleem vaak nog groter — overprovisioning, dev/test-omgevingen die 24/7 aanstaan zonder dat iemand ze gebruikt, en kortingsprogramma's waar niemand naar omkijkt.

Herkenbaar? Dan is dit artikel voor jou.

In deze gids laat ik je zien hoe je de kosten van Amazon RDS, Azure SQL Database en Google Cloud SQL met 30 tot 50% kunt verlagen — zonder dat je prestaties hoeft in te leveren. We behandelen de nieuwste kortingsprogramma's van 2026 (waaronder de nieuwe AWS Database Savings Plans) en ik geef je concrete codevoorbeelden die je direct kunt toepassen.

Right-sizing: de basis van elke besparing

De meest voorkomende oorzaak van hoge databasekosten? Overprovisioning. Teams kiezen vaak een instancetype op basis van piekcapaciteit, terwijl het gemiddelde CPU-gebruik ver onder de 40% ligt. Dat is zoiets als een busje huren om boodschappen te doen.

Door je instances af te stemmen op het werkelijke gebruik kun je 20 tot 40% besparen. Dat klinkt misschien simpel, maar in de praktijk vergeten teams dit regelmatig te evalueren.

AWS RDS: analyseer met Performance Insights en CloudWatch

Gebruik AWS Performance Insights om je CPU-, geheugen- en I/O-belasting te monitoren. Zoek specifiek naar instances met minder dan 30% gemiddeld CPU-gebruik over de afgelopen 30 dagen — dit zijn je kandidaten voor downsizing.

# Gemiddeld CPU-gebruik per RDS-instance over 30 dagen ophalen
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=mijn-productie-db \
  --start-time $(date -u -d "30 days ago" +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 86400 \
  --statistics Average \
  --output table

Voor niet-productie workloads zijn burstable instances zoals de T-serie (bijv. db.t4g.medium) het overwegen waard. Die kosten tot 60% minder dan general purpose instances en zijn prima voor ontwikkel- en testomgevingen.

Azure SQL: DTU vs. vCore-model

Azure SQL biedt twee inkoopmodellen en de keuze maakt nogal wat uit voor je rekening. Het DTU-model combineert compute, opslag en I/O in bundels, terwijl het vCore-model je onafhankelijk controle geeft over elk onderdeel. Controleer regelmatig je resource-gebruik via Azure Monitor:

# Azure SQL performance metrics opvragen via CLI
az monitor metrics list \
  --resource "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Sql/servers/{server}/databases/{db}" \
  --metric "cpu_percent" "dtu_consumption_percent" "storage_percent" \
  --interval PT1H \
  --start-time 2026-02-13T00:00:00Z \
  --end-time 2026-03-13T00:00:00Z \
  --output table

Google Cloud SQL: Active Assist-aanbevelingen

Google maakt het je wat makkelijker. Cloud SQL biedt via Active Assist automatische aanbevelingen voor right-sizing. Het systeem analyseert je CPU- en geheugengebruik en doet suggesties voor een kleinere (of grotere) machinetypeconfiguratie. Je vindt dit in de Cloud Console onder SQL > Instances > Insights.

AWS Database Savings Plans vs. Reserved Instances (2026)

In 2026 heb je bij AWS twee belangrijke kortingsprogramma's voor databases: de traditionele RDS Reserved Instances en de nieuwe Database Savings Plans (gelanceerd op re:Invent 2025). Beide hebben hun plek, maar de verschillen zijn groot.

Vergelijking in een oogopslag

Kenmerk	RDS Reserved Instances	Database Savings Plans
Maximale korting	Tot 69%	Tot 35%
Flexibiliteit	Laag (gebonden aan specifieke configuratie)	Hoog (cross-engine, cross-regio)
Looptijd	1 of 3 jaar	1 of 3 jaar
Dekking	Alleen RDS	RDS, Aurora, DocumentDB (11 diensten)
Instance-wijzigingen	Beperkt (alleen converteerbare RI's)	Vrij schakelen tussen families en regio's

De beste strategie: combineer beide

Eerlijk gezegd is de optimale aanpak bijna altijd layering: dek je stabiele baseline af met Reserved Instances voor de maximale korting, en gebruik Database Savings Plans voor de resterende variabele belasting. Gebruik 30 tot 90 dagen aan Cost Explorer-data om je baseline $/uur te bepalen.

# Analyseer je RDS-bestedingspatroon voor de afgelopen 90 dagen
aws ce get-cost-and-usage \
  --time-period Start=2025-12-13,End=2026-03-13 \
  --granularity DAILY \
  --metrics "UnblendedCost" \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --output json

Belangrijk: je kunt voor dezelfde workload niet zowel een Reserved Instance als een Database Savings Plan gebruiken. Maar je kunt wel een RI voor de ene workload en een Savings Plan voor een andere kopen — dat is precies waar layering om draait.

Let op: rightsize altijd voordat je een commitment aangaat. Ik heb teams gezien die eerst een 3-jarige RI kochten en daarna pas ontdekten dat ze twee maten kleiner konden. Dan betaal je voor capaciteit die je niet meer nodig hebt — en je zit er jarenlang aan vast.

Graviton-migratie: snelste AWS-besparing

Als ik één tip mag geven voor snelle besparingen op AWS: migreer naar Graviton. De nieuwste generatie is de r8g/m8g-familie (Graviton4), uitgerold begin 2026.

Graviton3 (r7g): tot 30% betere prestaties en 27% betere prijs/prestatie-verhouding ten opzichte van Graviton2
Graviton4 (r8g): tot 40% betere prestaties en 29% betere prijs/prestatie-verhouding ten opzichte van Graviton3

Een voorbeeld dat ik vaak tegenkom: teams draaien een db.r6g.2xlarge ($0,92/uur) terwijl een db.r7g.xlarge ($0,52/uur) de workload prima aankan. Dat is een besparing van $290 per maand per instance. Vermenigvuldig dat met een handvol databases en je praat al snel over duizenden euro's per jaar.

Migratie is eenvoudiger dan je denkt

Bij RDS is de overstap naar Graviton net zo simpel als het wijzigen van het instancetype. RDS draait dezelfde software op beide architecturen. Gebruik een Blue/Green Deployment voor een risicoloze migratie:

# Stap 1: Maak een Blue/Green Deployment
aws rds create-blue-green-deployment \
  --blue-green-deployment-name mijn-graviton-migratie \
  --source "arn:aws:rds:eu-west-1:123456789012:db:mijn-productie-db" \
  --target-db-instance-class db.r8g.xlarge

# Stap 2: Controleer de green-omgeving
aws rds describe-blue-green-deployments \
  --blue-green-deployment-identifier mijn-graviton-migratie

# Stap 3: Schakel over naar de green-omgeving (na validatie)
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier mijn-graviton-migratie

Azure SQL: serverless, Elastic Pools en Hybrid Benefit

Azure heeft drie krachtige mechanismen om je databasekosten omlaag te brengen. Laten we ze stuk voor stuk doorlopen.

Serverless compute-tier

De serverless tier schaalt automatisch op basis van de werkbelasting en factureert per seconde per vCore. Geen activiteit? Dan wordt de database gepauzeerd en betaal je alleen voor opslag. Dit is ideaal voor:

Ontwikkel- en testomgevingen
SaaS-applicaties met onvoorspelbare belasting
Seizoensgebonden applicaties

Prijzen starten vanaf $0,000145 per vCore-seconde. Wel goed om te weten: bij serverless zijn Reserved Capacity en Azure Hybrid Benefit niet beschikbaar. Dat is een bewuste trade-off.

Elastic Pools

Beheer je meerdere databases met wisselende belastingspatronen? Dan zijn Elastic Pools bijna altijd de kostenefficiëntere keuze. In plaats van piekbelasting per database apart te betalen, deel je resources via een gemeenschappelijke pool.

Combineer dit met Reserved Capacity (tot 33% korting) en Azure Hybrid Benefit (tot 55% korting op compute) voor een totale besparing van tot 80%. Ja, je leest het goed — 80%.

# Elastic Pool aanmaken via Azure CLI
az sql elastic-pool create \
  --resource-group mijn-resourcegroep \
  --server mijn-sql-server \
  --name mijn-elastic-pool \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 4 \
  --db-max-capacity 2 \
  --db-min-capacity 0.5

# Database toevoegen aan de Elastic Pool
az sql db update \
  --resource-group mijn-resourcegroep \
  --server mijn-sql-server \
  --name mijn-database \
  --elastic-pool mijn-elastic-pool

Azure Hybrid Benefit

Heb je bestaande SQL Server-licenties met actieve Software Assurance? Dan kun je met Azure Hybrid Benefit tot 55% besparen op compute-kosten. Dit werkt voor zowel Elastic Pools als provisioned single databases (maar niet voor serverless). Het is gratis geld dat veel organisaties laten liggen.

Google Cloud SQL: Committed Use Discounts

Google Cloud SQL biedt Committed Use Discounts (CUD's) die automatisch worden toegepast op al je Cloud SQL-gebruik in een regio:

1-jarige commitment: 25% korting op on-demand prijzen
3-jarige commitment: 52% korting op on-demand prijzen

CUD's gelden voor CPU- en geheugengebruik van alle Cloud SQL-instances in de regio. Ze gelden niet voor opslag, netwerk of licenties. Het mooie is dat de korting automatisch wordt toegepast op je geaggregeerde gebruik — je hoeft geen handmatige aanpassingen te doen.

# Cloud SQL instance-gebruik en kosten bekijken via gcloud
gcloud sql instances list --format="table(name, databaseVersion, settings.tier, state, region)"

# Gedetailleerde metrics ophalen
gcloud monitoring time-series list \
  --filter='metric.type="cloudsql.googleapis.com/database/cpu/utilization" AND resource.labels.database_id="mijn-project:mijn-instance"' \
  --interval-start-time=$(date -u -d "30 days ago" +%Y-%m-%dT%H:%M:%SZ) \
  --interval-end-time=$(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --format=json

Tip: kies voor de Enterprise-editie in plaats van Enterprise Plus als je geen extreme beschikbaarheid of prestaties nodig hebt. Het prijsverschil is aanzienlijk, terwijl Enterprise voor de meeste workloads ruimschoots voldoet.

Query-optimalisatie: bespaar zonder te downsizen

Voordat je geld uitgeeft aan grotere instances — of zelfs maar gaat nadenken over kortingsprogramma's — optimaliseer eerst je queries. Inefficiënte queries zijn verantwoordelijk voor een verrassend groot deel van het overmatige CPU- en geheugengebruik. De top 5% van queries veroorzaakt vaak 80% van de databasebelasting.

Praktische stappen

Vermijd SELECT *: haal alleen de kolommen op die je nodig hebt. Het klinkt als basiskennis, maar je zou versteld staan hoe vaak dit in productie voorkomt.
Voeg ontbrekende indexen toe: analyseer de slow query log en voeg indexen toe op veelgebruikte WHERE- en JOIN-kolommen
Gebruik EXPLAIN: analyseer het queryplan om full table scans en inefficiënte joins te detecteren
Beperk resultaten: gebruik LIMIT en paginering in plaats van alle rijen op te halen
Elimineer N+1 queries: gebruik JOINs of batch-ophaalacties in plaats van losse queries in een loop

-- Voorbeeld: slow query detectie in PostgreSQL (RDS of Cloud SQL)
SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes'
  AND state != 'idle'
ORDER BY duration DESC;

Een enkele geoptimaliseerde query kan meer besparen dan het upgraden van een complete instance. En het kost je niets extra — alleen wat tijd en aandacht.

Dev/test-omgevingen: stop met 24/7 draaien

Dit is eerlijk gezegd een van de makkelijkste besparingen die je kunt doorvoeren. Veel organisaties draaien ontwikkel-, test- en staging-omgevingen op dezelfde prestatietier als productie, 24 uur per dag, 7 dagen per week. Dat terwijl niemand op zaterdagnacht aan het testen is (hopelijk).

Door automatische planning in te stellen kun je niet-productie instances uitschakelen 's avonds en in het weekend — een besparing van meer dan 60% op dev/test-kosten.

AWS: automatisch starten en stoppen

# RDS-instance stoppen (max 7 dagen, daarna herstart automatisch)
aws rds stop-db-instance --db-instance-identifier mijn-dev-db

# RDS-instance starten
aws rds start-db-instance --db-instance-identifier mijn-dev-db

Gebruik AWS Lambda met EventBridge om dit volgens een schema te automatiseren. Of gebruik AWS Instance Scheduler als je liever een kant-en-klare oplossing hebt.

Azure: automatische pauzering met serverless

Bij Azure SQL Serverless wordt de database automatisch gepauzeerd na een configureerbare inactieve periode (minimaal 1 uur). Je betaalt dan alleen opslag. Dit is de ideale oplossing voor dev/test-databases die slechts enkele uren per dag actief zijn.

Monitoring en kostenalerts instellen

Goed, je hebt je instances geoptimaliseerd en de juiste kortingsprogramma's gekozen. Maar hoe zorg je dat het zo blijft? Effectief kostenbeheer vereist continu inzicht. Stel alerts in bij elk platform om verrassingen op je factuur te voorkomen.

AWS: budget en alarm instellen

# AWS Budget aanmaken voor RDS-uitgaven
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"RDS-Maandbudget","BudgetLimit":{"Amount":"500","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST","CostFilters":{"Service":["Amazon Relational Database Service"]}}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"[email protected]"}]}]'

Azure: Cost Management alerts

# Azure budget met alert instellen
az consumption budget create \
  --budget-name "SQL-Maandbudget" \
  --amount 500 \
  --time-grain Monthly \
  --start-date 2026-03-01 \
  --end-date 2027-03-01 \
  --resource-group mijn-resourcegroep \
  --category Cost

Google Cloud: budgetalerts

# GCP budget instellen via gcloud
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Cloud-SQL-Budget" \
  --budget-amount=500 \
  --threshold-rules-from-file=thresholds.json

Plan wekelijkse reviews van je databasekosten. Serieus — trends en anomalieën zijn véél makkelijker te detecteren wanneer je regelmatig kijkt in plaats van alleen bij de maandelijkse factuur.

Checklist: cloud database kosten optimalisatie

Om het overzichtelijk te houden, hier een checklist die je systematisch kunt aflopen:

Inventariseer: maak een overzicht van alle database-instances, hun grootte en gemiddeld gebruik
Identificeer idle instances: verwijder of consolideer databases met minder dan 5% CPU-gebruik
Right-size actieve instances: downsize instances met een gemiddeld gebruik onder de 30%
Migreer naar Graviton (AWS): schakel over naar r7g of r8g voor betere prijs/prestatie
Optimaliseer queries: analyseer slow query logs en voeg ontbrekende indexen toe
Plan dev/test-omgevingen: schakel niet-productie instances uit buiten werkuren
Evalueer kortingsprogramma's: koop Reserved Instances, Savings Plans of CUD's voor stabiele workloads
Overweeg serverless: gebruik Azure SQL Serverless of Aurora Serverless voor onvoorspelbare workloads
Stel budgetalerts in: configureer alerts bij 80% van je maandbudget
Review maandelijks: plan terugkerende kostenreviews en pas aan waar nodig

Veelgestelde vragen

Wat is de snelste manier om mijn clouddatabasekosten te verlagen?

Begin met het identificeren en verwijderen (of stoppen) van ongebruikte en idle database-instances. Veel organisaties hebben dev/test-databases die 24/7 draaien zonder dat iemand ze actief gebruikt. Daarnaast levert het overschakelen naar Graviton-instances bij AWS een directe kostenverlaging op van 20 tot 40%, met minimale inspanning.

Kan ik AWS Reserved Instances en Database Savings Plans combineren?

Niet voor dezelfde workload, nee. Je kunt echter wel een Reserved Instance kopen voor de ene workload en een Database Savings Plan voor een andere. De optimale strategie is je stabiele baseline afdekken met Reserved Instances (tot 69% korting) en de variabele belasting opvangen met Database Savings Plans (tot 35% korting, maar met meer flexibiliteit).

Is het veilig om van x86 naar Graviton te migreren bij RDS?

Ja, absoluut. Bij RDS is de migratie naar Graviton eenvoudig en veilig. RDS draait exact dezelfde software op beide architecturen — je wijzigt simpelweg het instancetype via een modify-operatie of een Blue/Green Deployment. Graviton4-instances (r8g) zijn beschikbaar voor Aurora PostgreSQL, Aurora MySQL, RDS for PostgreSQL, RDS for MySQL en RDS for MariaDB.

Wanneer kies ik Azure SQL Serverless in plaats van Elastic Pools?

Kies serverless wanneer je een enkele database hebt met onregelmatig en onvoorspelbaar gebruik, waarbij de database uren of dagen inactief kan zijn. Kies Elastic Pools wanneer je meerdere databases beheert met wisselende belastingspatronen die kunnen profiteren van gedeelde resources — vooral in combinatie met Reserved Capacity en Azure Hybrid Benefit voor maximale korting.

Hoeveel kan ik besparen met Google Cloud SQL Committed Use Discounts?

Google Cloud SQL CUD's bieden 25% korting bij een 1-jarige commitment en 52% korting bij een 3-jarige commitment. De kortingen gelden voor CPU- en geheugengebruik en worden automatisch toegepast op al je Cloud SQL-instances in een regio. Ze gelden niet voor opslag, netwerk of licentiekosten.