Database Omkostningsoptimering i 2026: Sådan Reducerer Du RDS, Aurora, DynamoDB og Cosmos DB Regninger
Sådan reducerer du database-omkostninger 40-70% på Amazon RDS, Aurora, DynamoDB, Azure SQL, Cosmos DB og BigQuery i 2026. Praktiske eksempler med autoscaling, reserved capacity, I/O-Optimized storage og en case hvor vi skar $180.000/måned med 62%.
Database-omkostningsoptimering handler i 2026 om at matche throughput-model til arbejdsbelastning: skift Amazon Aurora til I/O-Optimized hvis I/O overstiger 25% af regningen, brug DynamoDB provisioned med autoscaling når trafikken er forudsigelig, aktivér Cosmos DB autoscale for spidsbelastninger, og køb BigQuery-kapacitetsreservationer når on-demand overstiger $2.000/måned. På tværs af de større multi-cloud-projekter jeg har arbejdet med, ligger den typiske besparelse et sted mellem 40% og 70% (og næsten altid uden ændringer i applikationskoden).
Aurora I/O-Optimized eliminerer I/O-gebyrer og bliver billigere end standard når I/O udgør mere end ~25% af Aurora-omkostningerne.
DynamoDB on-demand koster ca. 6,25× per request sammenlignet med provisioned kapacitet. Skift til provisioned med autoscaling ved forudsigelig trafik over 20% udnyttelse.
Cosmos DB autoscale skalerer mellem 10% og 100% af max RU/s og eliminerer overprovisionering ved variable belastninger.
BigQuery Editions med kapacitetsreservationer giver op til 40% rabat mod on-demand ved konstant slot-forbrug.
Read replicas, snapshot-lifecycle og gp3 EBS-migrering giver næsten altid 10-20% ekstra reduktion oveni instans-optimering.
Reserved Instances og Savings Plans på RDS/Aurora giver 30-72% rabat. Kombineres bedst med rigtig instansstørrelse for maksimal effekt.
Hvorfor databaser dominerer cloud-regningen
I mine seneste seks FinOps-engagementer har databaser stået for et sted mellem 28% og 41% af den samlede cloud-regning. Større end compute i to af tilfældene. Årsagen er ikke, at teams overspenderer bevidst. Det er, at database-services har mange dimensioner der debiteres uafhængigt: instans-timer, provisioned IOPS, storage, backups, snapshots, cross-region replication, request units, og (for warehouse-produkter) on-demand query-scanning. Én forkert konfigureret dimension kan fordoble regningen uden nogen får det at se.
Et konkret eksempel: Et Aurora PostgreSQL-cluster med moderat write-belastning brugte $18.400/måned. 47% var I/O-charges. Skift til Aurora I/O-Optimized halverede den samlede omkostning på fjorten dage. Ingen kodeændringer, ingen migrering. Bare et konfigurationsvalg der ikke eksisterede før 2023, men som stadig ikke er standard i nye clusters. Det er præcis den slags optimering vi går efter i dette dokument.
Ud over de rene prisreduktioner er databasen typisk den arkitektur-komponent hvor forkerte tidlige valg koster mest at rette op senere. Vælger man DynamoDB on-demand tidligt "for at være sikker", forbliver det ofte kørende i produktion i årevis. Vælger man Cosmos DB manual throughput på 50.000 RU/s "for aldrig at få throttling", kører det på 8% udnyttelse i weekender. Målet er ikke at ramme perfekt fra dag ét. Målet er at måle månedligt og justere.
Sådan reducerer du Amazon RDS og Aurora-omkostninger
Amazon RDS og Aurora er ofte den enkeltstørste post inden for database-kategorien på AWS. Optimering falder i fire greb, der stort set altid kan kombineres.
1. Skift til Aurora I/O-Optimized når det giver mening
Aurora har siden 2023 haft to storage-modeller: Standard (billig storage + betaling per I/O) og I/O-Optimized (25% dyrere storage + 30% dyrere instanser, men ingen I/O-gebyrer). Ifølge AWS' egen beregning bliver I/O-Optimized billigere når I/O-omkostninger overstiger ca. 25% af den samlede Aurora-post. Kontrollér det med Cost Explorer:
# AWS CLI: pull last 30 days of Aurora usage split by usage type
aws ce get-cost-and-usage \
--time-period Start=2026-07-08,End=2026-08-07 \
--granularity MONTHLY \
--metrics UnblendedCost \
--group-by Type=DIMENSION,Key=USAGE_TYPE \
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
--query 'ResultsByTime[0].Groups[?contains(Keys[0], `Aurora`)].[Keys[0],Metrics.UnblendedCost.Amount]' \
--output table
Filtrer på usage-typer der indeholder IO-Requests. Er summen >25% af det totale Aurora-tal, skift storage-typen. Skiftet er online og kræver ikke downtime.
2. Migrer gp2 til gp3 for RDS storage
Standard-EBS-typen for RDS er stadig gp2 for ældre databaser, men gp3 er både billigere ($0,08 vs $0,115 per GB-måned i us-east-1) og lader dig provisionere IOPS uafhængigt af størrelse. På en 4 TB RDS Postgres reducerede vi lageromkostningen fra $471 til $327/måned med ét enkelt modify-instance kald. Ingen ændring i IOPS-ydelse.
3. Køb Reserved Instances eller Savings Plans
RDS Reserved Instances giver 30-65% rabat på et års binding, op til 72% på tre år. Aurora dækkes nu også af Compute Savings Plans (siden 2024), med den fordel at Savings Plans også dækker Lambda og Fargate, så commitmentet er mere fleksibelt. Se vores detaljerede sammenligning i Savings Plans vs Reserved Instances i 2026 for hvornår man vælger hvad.
4. Right-sizing baseret på faktiske metrics
Brug CloudWatch CPUUtilization, DatabaseConnections og FreeableMemory over 30 dage. Er 95. percentilen for CPU under 40% og memory-forbruget under 60%, downsize én størrelse. På en flåde af 22 RDS-instanser vi analyserede i marts 2026, var 14 overprovisioneret. Samlet besparelse: $9.700/måned.
DynamoDB: On-demand vs Provisioned kapacitet i 2026
DynamoDB er stedet hvor jeg oftest ser folk brænde penge unødigt. Standardvalget "on-demand" er brugervenligt men dyrt: on-demand-priser er ca. 6,25× højere per read/write end provisioned kapacitet. Break-even ligger omkring 20% udnyttelse af provisioned kapacitet, og over det bliver provisioned billigere.
Regnestykket på ren dansk
Én write request unit (WRU) koster $1,4269 per million on-demand vs $0,000742 per WCU-time provisioned. En tabel der modtager 500 writes/sekund:
Provisioned med autoscaling (50-1000 WCU): ~$350/måned
Det er en 5-7× forskel. Ifølge DynamoDB's officielle prissætning er on-demand relevant til uforudsigelig eller ny trafik. For alt over 3-6 måneders produktionshistorik: skift til provisioned.
Ærligt talt: konfigurér altid autoscaling før du skifter billing mode. Jeg fik selv en tabel throttlet i 20 minutter tidligt i min karriere fordi jeg trykkede på update-table først og satte scaling-policyen bagefter. Rækkefølgen betyder alt.
Reserved Capacity for stabile workloads
DynamoDB Reserved Capacity giver yderligere 53% (1-årig) eller 76% (3-årig) rabat oveni provisioned. Vi kombinerer typisk: køb reserved capacity for baseline (fx 60% af gennemsnittet), lad autoscaling håndtere resten. Kontrollér også at du bruger TTL til at slette gamle rækker automatisk. Hver GB storage koster $0,25/måned i standard-klassen, og en tabel med 4 TB gammel data koster $1.000/måned bare i storage.
Azure SQL Database: Serverless, Elastic Pools og Reserved Capacity
Azure SQL Database har tre købsmodeller (DTU, vCore, Hyperscale) og fire compute-tiers (Provisioned, Serverless, Hyperscale, Elastic Pool). Valget mellem dem er den største enkeltbeslutning for omkostningerne.
vCore Serverless til variabel belastning
vCore Serverless auto-pauser efter 1 times inaktivitet og debiterer kun storage under pause (~$0,115/GB-måned). For dev/test og lav-trafik-apps er besparelsen 60-85%. En advarsel: første query efter en pause tager 30-60 sekunder på cold start. Acceptabelt for interne værktøjer, ikke for kundevendte apps.
Elastic Pools når du har mange små databaser
Har du 15+ databaser med ikke-korrelerede spidser (fx per-tenant SaaS), giver Elastic Pools 40-70% besparelse ved at dele DTU/vCore-kapacitet. Regnestykket: 20 databaser × S2 Standard ($75/måned) = $1.500. Same load på en Standard Pool med 200 eDTUs = $445/måned. Break-even ligger omkring 4-5 databaser.
Reserved Capacity
Azure Reserved Capacity for SQL Database giver 33% (1-årig) eller 55% (3-årig) rabat på vCore-priser. Kombinér med Azure Hybrid Benefit (BYOL af eksisterende SQL Server-licenser) for endnu 30-40% ekstra. Totalen kan overstige 80% rabat mod PAYG-priser. Se den officielle Azure SQL Reserved Capacity-dokumentation for hvilke regioner og tiers der understøttes.
Cosmos DB: Autoscale, Serverless og RU/s tuning
Cosmos DB debiterer i Request Units per sekund (RU/s). Provisioneret throughput koster $5,84 per 100 RU/s per måned. En container provisioneret til 10.000 RU/s koster $584/måned uanset om den bruges eller ej. Det er her regningen løber løbsk.
Skift til Autoscale hvor det giver mening
Autoscale skalerer mellem 10% og 100% af max RU/s og koster 50% mere per RU end fixed provisioning, men kun for de RU'er der faktisk bruges. Ved en workload med gennemsnitlig 3.000 RU/s og spidser til 10.000:
Fixed provisioned 10.000 RU/s: $584/måned
Autoscale 1.000-10.000 RU/s: ~$262/måned (baseret på 30% gennemsnitlig udnyttelse)
Break-even for autoscale er omkring 65% udnyttelse. Over det er fixed billigere. Under det vinder autoscale altid.
Serverless for helt uregelmæssige workloads
Cosmos DB Serverless koster $0,279 per million RU forbrugt. Ingen provisioning, ingen minimums-kapacitet. Break-even mod autoscale ligger omkring 700.000 RU/dag. Over det bliver serverless dyrere.
Reducer RU-forbruget i selve query'en
// BAD: full container scan, 500-2000 RUs per query
const badQuery = "SELECT * FROM c WHERE c.status = 'active'";
// GOOD: partition-keyed with projection, 2.5-8 RUs per query
const goodQuery = {
query: "SELECT c.id, c.name, c.updated_at FROM c WHERE c.tenantId = @tid AND c.status = @s",
parameters: [
{ name: "@tid", value: tenantId },
{ name: "@s", value: "active" }
]
};
Kør altid queries med partition key i WHERE-klausulen, projekt kun de kolonner du bruger, og aktivér integrated cache (via dedicated gateway) for repeterede reads. Det kan skære 90% af RU-forbruget for read-tunge workloads.
Google Cloud SQL, Spanner og BigQuery kapacitetsslot
På Google Cloud er de tre store database-omkostningsposter Cloud SQL (Postgres/MySQL/SQL Server), Spanner (globalt distribueret) og BigQuery (analytics warehouse). Hver har sin egen optimeringsmodel.
Cloud SQL: Committed Use Discounts og Enterprise Plus
Cloud SQL 1-årig CUD giver 25%, 3-årig giver 52%. Enterprise Plus edition (lanceret 2023) er 3× hurtigere til read-tunge workloads men koster kun 60% mere. Det kan retfærdiggøre downsize af antal read replicas. På en flåde med 6 read replicas kunne vi skære til 2 med samme latency ved at skifte til Enterprise Plus. Netto-besparelse: 34%.
Spanner: reducer PU/nodes uden for arbejdstid
Spanner debiterer per Processing Unit (PU): 1000 PU = 1 node ≈ $0,90/time = $657/måned. For interne apps kan man automatisere reduktion fra 1000 PU til 100 PU efter kl. 18: 90% besparelse for de 14 timer/døgn hvor systemet er inaktivt.
BigQuery: skift fra on-demand til Editions
BigQuery on-demand koster $6,25 per TB scannet. Ved konstant analytisk brug bliver kapacitetsreservationer (Editions) billigere fra ca. $2.000/måned. Standard Edition slots: $0,04 per slot-time, Enterprise: $0,06, Enterprise Plus: $0,10. Med commitments på 1 eller 3 år ligger rabatten på 20-40%. Se de eksakte tal i BigQuery's officielle prisside.
To hurtige BigQuery-greb der altid virker:
Partitioning: partition tables på ingest-tid eller event-tid. Reducerer scanning med 90%+ for tidsfiltrerede queries.
Materialized views: for hyppige aggregeringer koster de storage men eliminerer scan-omkostningen ved læsning.
Backup, snapshots og read replicas: den skjulte database-regning
Efter man har optimeret compute og storage på selve databasen, gemmer der sig ofte 10-20% ekstra i den perifære infrastruktur.
Snapshots og backups
RDS automated backups er gratis op til størrelsen af databasen. Manuelle snapshots debiteres per GB-måned. Jeg har set kunder med 4.000+ manuelle snapshots fra ad-hoc test-restores i 2019. Totalpris: $12.000/måned. Ryd op med en DeleteDBSnapshot-loop over snapshots ældre end 90 dage der ikke er tagget keep=true.
Read replicas
En read replica koster typisk 100% af primary-instansen. Har du 3 replicas, koster databasen 4×. Auditér om alle 3 er nødvendige, eller om connection pooling (RDS Proxy, PgBouncer) kan reducere behovet. Skift også til mindre instanstyper på replicas hvis de kun håndterer read-only reporting.
Cross-region replication
Cross-region storage-replikation koster både storage (2×) og data transfer (~$0,02/GB). Verificér om DR-strategien faktisk kræver active cross-region replication, eller om point-in-time restore fra snapshots til en anden region er tilstrækkeligt for RPO/RTO. For en dybere analyse af cross-region data transfer-omkostninger, se vores guide til reducere data transfer og egress-gebyrer.
Case: Vi skar en $180.000/måned database-regning med 62%
SaaS-kunde, ~800 tenants, tri-cloud (AWS 60%, Azure 30%, GCP 10%). Database-regningen udgjorde 34% af den samlede cloud-omkostning: $181.400/måned. Efter 8 uger var den nede på $68.900. Fordelt således:
Vigtigste erfaring: 62% samlet besparelse kom ikke fra én enkelt optimering, men fra otte lag der hver især bidrog med 4-16%. Right-sizing af selve database-instansen var faktisk ikke i top-3. De store gevinster lå i throughput-model og storage-type. Så prioritér altid at måle først, optimér efter data.
For en bredere kontekst omkring hvordan denne slags optimering skal indpasses i en tag-baseret allokeringsmodel, se vores Cloud Tagging Strategi i 2026. Uden ordentlig tagging kan du ikke identificere hvilke tenants eller teams der driver database-omkostningerne.
Ofte stillede spørgsmål
Hvornår er Aurora I/O-Optimized billigere end Aurora Standard?
Når I/O-gebyrer overstiger cirka 25% af den samlede Aurora-omkostning. Storage bliver 25% dyrere og instanser 30% dyrere med I/O-Optimized, men til gengæld bortfalder alle I/O-charges. Kontrollér Cost Explorer for aktuelle I/O-omkostninger før skift.
Er DynamoDB on-demand altid dyrere end provisioned kapacitet?
Ikke altid, men næsten altid ved forudsigelig trafik. On-demand er ca. 6,25× dyrere per request end provisioned. Break-even ligger omkring 15-20% udnyttelse. Hvis din tabel er over det, er provisioned med autoscaling billigere.
Hvordan reducerer jeg Cosmos DB RU-omkostninger?
Skift til autoscale ved variabel belastning under 65% udnyttelse, brug altid partition key i queries, projicér kun nødvendige kolonner, aktivér integrated cache for read-tunge workloads, og log RequestCharge for at identificere top-omkostningsqueries. En kombination giver typisk 40-70% reduktion.
Hvornår er BigQuery Editions billigere end on-demand?
Når on-demand-forbruget overstiger cirka $2.000/måned ved konstant analytisk brug. Standard Edition med 500 slots ($0,04/slot-time) koster ca. $14.600/måned uden commitment, men matcher scanning-volumen der ellers ville koste $18.000+ on-demand. Med 1-årigt commitment tilføjes yderligere 20% rabat.
Kan Aurora Serverless v2 skalere ned til nul?
Ja, siden oktober 2024 understøtter Aurora Serverless v2 scale-to-zero i understøttede regioner. Før den ændring var minimum 0,5 ACU (~$43/måned per idle cluster). Aktivér funktionen eksplicit via cluster-konfigurationen. Den er ikke slået til som standard for eksisterende clusters.
Sådan skærer du data transfer- og egress-omkostninger med 60-80% på AWS, Azure og GCP. Praktisk guide til VPC Endpoints, CDN-strategier, NAT Gateway-fælder, multi-cloud overførsler og zero-egress alternativer som Cloudflare R2.
Lær at vælge mellem Savings Plans, Reserved Instances og CUDs på tværs af AWS, Azure og GCP. Med CLI-eksempler, beregningsformler og en lagdelt strategi der kan spare dig op til 50% på din cloud compute-regning.
Lær hvordan du reducerer din cloud storage-regning med op til 80% på tværs af AWS S3, Azure Blob og Google Cloud Storage. Komplet guide med lifecycle-politikker, auto-tiering, egress-besparelser og praktiske kodeeksempler.
