Jak snížit náklady na cloudové databáze o 30–70 % v roce 2026

Úvod: Databáze jako tichý žrout cloudového rozpočtu

V naší sérii o optimalizaci cloudových nákladů jsme si prošli Kubernetes, AI/ML workloady, serverless funkce i cloudové úložiště. Dnes se zaměříme na oblast, která – upřímně řečeno – překvapivě často uniká pozornosti: databáze. A to i přesto, že bývají jednou z největších položek na cloudové faktuře.

Databáze běží pořád. Rostou pomalu, ale jistě, a jejich náklady se špatně odhadují. Na rozdíl od stateless infrastruktury, kde škálování docela hezky kopíruje provoz, databáze tiše bobtnají na pozadí. Podle analýzy FinOps Foundation tvoří databázové služby u řady organizací 30–40 % celkového cloudového rozpočtu – a přitom až 82 % firem s cloudovými workloady zbytečně utrácí právě kvůli špatné viditelnosti do databázových zdrojů. Když se nad tím zamyslíte, je to dost alarmující číslo.

Rok 2026 ale přinesl novinky, které tohle celé mění. AWS spustil Database Savings Plans, Google Cloud rozšířil Committed Use Discounts na BigQuery a instance Graviton4 nabízejí o 40 % vyšší výkon za nižší cenu. Tak pojďme na to – podíváme se, jak těchto novinek využít a stáhnout náklady na databáze o 30–70 %.

AWS Database Savings Plans: Revoluce v databázových slevách

V prosinci 2025 na re:Invent představil AWS Database Savings Plans – první opravdu flexibilní slevový model pro databáze. FinOps komunita na něco takového čekala skoro šest let. A stojí to za to.

Co přesně nabízejí

Funguje to jednoduše: zavážete se k fixní hodinové útratě (v $/hod) a za to dostanete slevy 12–35 % oproti on-demand cenám. Žádná záloha předem. A oproti Reserved Instances je tu zásadní rozdíl – slevy se automaticky aplikují napříč:

• Databázovými enginy – Aurora, RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server), DynamoDB
• Typy instancí – můžete přecházet mezi db.r7g a db.r8g bez ztráty slevy
• Regiony – přesunete workload z EU (Ireland) do US (Ohio) a sleva vám zůstane
• Deployment modely – provisioned instance i serverless

Celkově pokrývají 14 AWS databázových služeb včetně Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream a AWS DMS.

Database Savings Plans vs. Reserved Instances

Vlastnost	Database Savings Plans	Reserved Instances
Maximální sleva	Až 35 %	Až 69–77 %
Délka závazku	Pouze 1 rok	1 nebo 3 roky
Flexibilita enginu	Ano – napříč enginy	Ne – fixní engine
Flexibilita regionu	Ano	Ne
Podpora serverless	Ano (Aurora Serverless v2, DynamoDB on-demand)	Ne
Kombinace s RI	Ne na stejném workloadu	–

Praktické doporučení: Database Savings Plans se hodí hlavně pro proměnlivé nebo modernizující se workloady. Reserved Instances si nechte pro stabilní produkční databáze, kde víte, že se instance class nezmění 1–3 roky – ta sleva (až 69 %) je prostě výrazně vyšší.

Jak správně nakoupit Database Savings Plans

AWS nabízí dva nástroje, které vám s nákupem pomohou:

1. Savings Plans Recommendations – analyzuje vaši historickou spotřebu a navrhne optimální výši závazku
2. Savings Plan Purchase Analyzer – simuluje různé částky a ukáže vám výsledné úspory, pokrytí a využití

Doporučuju konzervativní přístup. Začněte závazkem na 70–80 % vaší konzistentní baseline spotřeby, postupně přidávejte menší inkrementální nákupy a pravidelně sledujte využití. Lepší je koupit méně a dokoupit, než se zavázat k částce, kterou nevyužijete.

# Zobrazení aktuálních doporučení pro Database Savings Plans přes AWS CLI
aws savingsplans get-savings-plans-purchase-recommendation \
  --savings-plan-type "SageMakerSavingsPlans" \
  --term-in-years "ONE_YEAR" \
  --payment-option "NO_UPFRONT" \
  --lookback-period-in-days "SIXTY_DAYS"

# Výpis existujících Savings Plans a jejich využití
aws savingsplans describe-savings-plans \
  --query "SavingsPlans[?SavingsPlansType=='DatabaseSavingsPlans'].[SavingsPlansId,State,Commitment,Utilization]" \
  --output table

Right-sizing databází s AWS Compute Optimizer

Asi to znáte – databázový tým tráví hodiny procházením CloudWatch metrik, aby zjistil, jestli jsou instance správně dimenzované. A většinou stejně zvolí tu bezpečnou cestu: nadprůměrně velkou instanci. Výsledek? Plýtvání. AWS Compute Optimizer tohle celé automatizuje.

Podporované databáze

V roce 2026 Compute Optimizer podporuje doporučení pro:

• Amazon RDS for MySQL
• Amazon RDS for PostgreSQL
• Amazon Aurora MySQL-Compatible Edition
• Amazon Aurora PostgreSQL-Compatible Edition

Jak funguje analýza

Compute Optimizer automaticky analyzuje CloudWatch metriky – CPU utilizaci, network throughput, počet připojení – a na základě toho generuje doporučení. Pokud navíc aktivujete RDS Performance Insights, dostanete přesnější výsledky, protože se analyzují i pokročilé metriky jako DBLoad a out-of-memory countery.

Instance klasifikuje do tří kategorií:

• Optimized – správně dimenzovaná, nic řešit nemusíte
• Over-provisioned – nadměrná kapacita, tady se dá ušetřit
• Under-provisioned – nedostatečné zdroje, pozor na výkon

Jeden důležitý detail: Compute Optimizer nikdy nedoporučí snížení paměti. Proč? Protože výkon databáze je na dostupné RAM kriticky závislý – tohle je prostě performance-first přístup. Doporučení se obnovují denně a vyžadují minimálně 30 hodin CloudWatch dat.

# Export doporučení pro RDS instance do S3
aws compute-optimizer export-rds-database-recommendations \
  --s3-destination-config bucket=muj-bucket,keyPrefix=rds-recommendations \
  --file-format Csv

# Zobrazení doporučení pro konkrétní RDS instanci
aws compute-optimizer get-rds-database-recommendations \
  --filters name=Finding,values=Overprovisioned \
  --query "rdsDBRecommendations[].{Instance:resourceArn,Current:currentDBInstanceClass,Recommended:effectiveRecommendationPreferences}" \
  --output table

Úspory z right-sizingu v praxi

Týmy, které implementují doporučení Compute Optimizer, typicky ušetří 20–40 % na databázových instancích. Postup je přitom docela přímočarý:

1. Eliminujte idle a nepoužívané databáze (dev/test prostředí, staré prototypy – ty se vždycky najdou)
2. Right-sizujte zbývající instance podle doporučení
3. Teprve potom nakupujte commitment slevy (RI nebo Savings Plans) na ten optimalizovaný baseline

Tohle pořadí je důležité. Nemá smysl kupovat Reserved Instances na předimenzované instance – nejdřív optimalizujte, pak commitujte.

Aurora I/O-Optimized: Úspora 30–40 % pro I/O náročné workloady

Tady se mi líbí jednoduchost celé věci. Aurora I/O-Optimized je čistě cenová změna – výkon, latence a throughput vaší databáze zůstávají naprosto stejné. Prostě místo platby za každý milion I/O operací platíte vyšší paušální sazbu za storage, ale veškeré I/O máte v ceně.

Kdy se vyplatí přepnout

Rozhodnutí je čistě matematické. Pokud vaše I/O náklady tvoří víc než přibližně 25 % celkového Aurora spendingu, I/O-Optimized vám pravděpodobně ušetří peníze. Pro databáze s intenzivním čtením a zápisem – e-commerce, IoT, analytika – bývají úspory 30–40 %.

# Zjištění aktuálních I/O nákladů Aurora clusteru přes AWS Cost Explorer API
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --filter '{"And": [{"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Relational Database Service"]}}, {"Dimensions": {"Key": "USAGE_TYPE", "Values": ["Aurora:StorageIOUsage"]}}]}' \
  --query "ResultsByTime[0].Total.UnblendedCost"

Přepnutí provedete jednoduše v AWS konzoli nebo přes CLI – bez prostojů a bez migrace dat. A kdyby se to nevyplatilo? Můžete se kdykoliv vrátit zpět.

Graviton4 instance: O 40 % vyšší výkon za nižší cenu

Instance založené na AWS Graviton4 (rodiny r8g, m8g) byly spuštěny koncem roku 2025 a začátkem roku 2026 se rozšířily do dalších regionů. Čísla mluví za sebe:

• Až 40 % vyšší výkon oproti Graviton3
• Až 29 % lepší poměr cena/výkon oproti ekvivalentním Graviton3 instancím
• Plná kompatibilita s Aurora MySQL, Aurora PostgreSQL, RDS MySQL a RDS PostgreSQL

Graviton-based Aurora instance poskytují zhruba 20 % lepší poměr cena/výkon oproti x86 alternativám. Pokud nemáte specifický důvod pro x86 (proprietární software, nějaká ISA závislost), prostě defaultujte na Graviton. Není důvod to nedělat.

# Migrace RDS instance na Graviton4 (r8g rodinu)
aws rds modify-db-instance \
  --db-instance-identifier moje-produkci-db \
  --db-instance-class db.r8g.xlarge \
  --apply-immediately

# Ověření dostupných Graviton4 instance tříd pro Aurora
aws rds describe-orderable-db-instance-options \
  --engine aurora-postgresql \
  --query "OrderableDBInstanceOptions[?contains(DBInstanceClass, 'r8g')].[DBInstanceClass,AvailabilityZones[0].Name]" \
  --output table

Azure SQL: Kombinace Reserved Capacity a Hybrid Benefit

Azure nabízí pro databáze jeden z nejsilnějších stacků slev ze všech tří velkých cloudů – pokud ovšem umíte jednotlivé vrstvy správně naskládat na sebe.

Reserved Capacity

Azure SQL Database reserved capacity vám ušetří až 33 % oproti licence-included cenám. Stačí předplatit výpočetní kapacitu na 1 nebo 3 roky. Funguje to pro single databases, elastic pools i managed instances.

Azure Hybrid Benefit

Máte existující Windows Server nebo SQL Server licence se Software Assurance? Pak je můžete využít v Azure přes Hybrid Benefit. Samotný Hybrid Benefit ušetří až 55 %. A teď ta zajímavá část – v kombinaci s Reserved Capacity se dostanete na úspory až 80 %.

Kombinace slev	Potenciální úspora
Pouze Reserved Capacity (1 rok)	Až 33 %
Pouze Azure Hybrid Benefit	Až 55 %
Reserved Capacity + Hybrid Benefit	Až 80 %
Reserved + Hybrid + Dev/Test pricing	Až 85 %

Azure SQL Serverless pro sporadické workloady

Azure SQL Database Serverless je skvělá volba pro workloady, které neběží pořád. Automaticky škáluje compute podle poptávky, účtuje se po sekundách a – co je nejlepší – databáze se může v nečinnosti úplně pozastavit s nulovými compute náklady. Ideální pro vývojová prostředí, interní aplikace nebo cokoliv s nepředvídatelným provozem.

Elastic Pools pro konsolidaci

Provozujete desítky menších databází s proměnlivou zátěží? Pak se podívejte na Azure SQL Elastic Pools. Místo toho, aby každá databáze měla vlastní dedicované zdroje (a většinu času je nevyužívala), sdílíte jednu společnou pool kapacitu. Pro SaaS aplikace s databází per tenant je to často úplně nejefektivnější model.

# Azure CLI: Vytvoření Elastic Pool s right-sized konfigurací
az sql elastic-pool create \
  --resource-group moje-rg \
  --server muj-sql-server \
  --name muj-elastic-pool \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 8 \
  --db-max-capacity 4 \
  --db-min-capacity 0.5

# Přesun existující databáze do elastic pool
az sql db update \
  --resource-group moje-rg \
  --server muj-sql-server \
  --name moje-databaze \
  --elastic-pool muj-elastic-pool

# Zobrazení doporučení Azure Advisor pro SQL databáze
az advisor recommendation list \
  --filter "Category eq 'Cost' and ResourceType eq 'Microsoft.Sql/servers/databases'" \
  --output table

GCP: Cloud SQL CUDs a BigQuery optimalizace

Google Cloud přišel v období 2025–2026 s několika zajímavými novinkami. Pojďme si je projít.

Cloud SQL Committed Use Discounts

Cloud SQL CUDs nabízejí výrazné slevy za závazek kontinuálního používání databázových instancí v určitém regionu na 1 nebo 3 roky. Doporučení pro Cloud SQL využívají pokročilou analytiku a strojové učení k identifikaci:

• Over-provisioned instancí
• Idle instancí (těch bývá víc, než byste čekali)
• Instancí, které by profitovaly z CUD

Doporučení jsou dostupná pro Cloud SQL for MySQL, PostgreSQL i SQL Server přes Recommender API a Recommendation Hub.

BigQuery Committed Use Discounts (novinka 2025)

Tohle je velká věc. Na Google Cloud Next 2025 Google poprvé oznámil CUDs pro BigQuery. BigQuery CUDs poskytují slevy na PAYG compute kapacitu výměnou za 1- nebo 3letý závazek s měsíčním účtováním. Jsou tu dvě varianty:

• Spend-based CUDs – založené na dolarové útratě, ne na konkrétním množství zdrojů, takže máte větší flexibilitu
• Capacity commitments – nákup fixního počtu BigQuery slotů

Spend-based CUDs se aplikují napříč BigQuery Editions, Cloud Composer 3 compute SKUs a BigQuery Data Governance. Ale pozor – jsou region-specifické, takže závazek platí jen v jednom regionu.

BigQuery Storage API: Fyzické účtování

Jeden tip, který se snadno přehlédne: použijte BigQuery Storage API s fyzickým billing modelem. Účtuje se za komprimované bajty místo logických bajtů. Pro dobře komprimovaná data to může znamenat úspory 70–80 % na storage nákladech. To není překlep.

# gcloud: Zobrazení CUD doporučení pro Cloud SQL
gcloud recommender recommendations list \
  --project=muj-projekt \
  --location=europe-west1 \
  --recommender=google.cloudsql.instance.CostRecommender \
  --format="table(name,description,primaryImpact.costProjection)"

# Vytvoření Cloud SQL CUD
gcloud sql instances patch moje-instance \
  --commitment-plan=ONE_YEAR

# BigQuery: Přepnutí na fyzický billing model
bq update \
  --default_table_expiration=0 \
  --storage_billing_model=PHYSICAL \
  muj-projekt:muj-dataset

DynamoDB: Skryté úspory, o kterých většina týmů neví

DynamoDB má vlastní sadu optimalizačních páků, které jdou daleko za rámec prostého výběru mezi on-demand a provisioned capacity. A některé z nich jsou překvapivě jednoduché.

Standard-IA tabulky

DynamoDB Standard-IA (Infrequent Access) nabízí až 60 % úsporu na storage nákladech pro data, ke kterým přistupujete méně často. To nejlepší na tom? Přepnutí nevyžaduje žádný downtime, žádnou migraci dat a žádné změny kódu. Je to čistě konfigurační změna. Latence, throughput, durabilita i dostupnost zůstávají identické.

Database Savings Plans pro DynamoDB

Poprvé v historii můžete díky novým AWS Database Savings Plans získat slevy i na DynamoDB on-demand throughput. Dřív jste měli jen dvě možnosti: DynamoDB Reserved Capacity (omezená flexibilita) nebo plný on-demand pricing. Savings Plans tuhle mezeru elegantně uzavírají.

Optimalizace read/write kapacity

# Analýza DynamoDB tabulek pro identifikaci kandidátů na Standard-IA
aws dynamodb list-tables --query "TableNames" --output text | \
  xargs -I {} aws dynamodb describe-table --table-name {} \
  --query "Table.{Name:TableName,SizeBytes:TableSizeBytes,ItemCount:ItemCount,Class:TableClassSummary.TableClass}" \
  --output table

# Přepnutí tabulky na Standard-IA
aws dynamodb update-table \
  --table-name moje-tabulka \
  --table-class STANDARD_INFREQUENT_ACCESS

# Kontrola DynamoDB Contributor Insights pro identifikaci hot keys
aws dynamodb describe-contributor-insights \
  --table-name moje-tabulka

5kroková příručka: Jak snížit databázové náklady o 30–70 %

Tak, prošli jsme si jednotlivé nástroje a strategie. Teď to pojďme dát dohromady do konkrétního akčního plánu, který můžete začít realizovat hned zítra.

Krok 1: Audit a viditelnost (týden 1)

1. Zmapujte všechny databázové instance napříč účty a regiony
2. Tagujte každou databázi: environment, owner, application, cost_center
3. Aktivujte AWS Cost Explorer, Azure Cost Management nebo GCP Billing Reports
4. Identifikujte top 10 nejdražších databází – tady budete optimalizovat jako první

Krok 2: Eliminace odpadu (týden 2)

1. Vypněte nebo smažte idle databáze (dev/test prostředí, staré prototypy – garantuju vám, že nějaké najdete)
2. Nastavte automatické stop/start plány pro non-prod prostředí (úspora 10–20 %)
3. Odstraňte nepoužívané snapshoty a zálohy

Krok 3: Right-sizing (týden 3–4)

1. Aktivujte AWS Compute Optimizer / Azure Advisor / GCP Recommender
2. Zapněte RDS Performance Insights pro přesnější doporučení
3. Migrujte na Graviton4 instance (r8g/m8g) kde je to možné
4. Přepněte Aurora I/O-heavy workloady na I/O-Optimized pricing

Krok 4: Commitment slevy (týden 5–6)

1. Po right-sizingu nakupte commitment slevy na optimalizovaný baseline
2. Pro stabilní produkční workloady: Reserved Instances (AWS/Azure) nebo CUDs (GCP)
3. Pro proměnlivé workloady: AWS Database Savings Plans
4. Začněte na 70–80 % baseline a postupně navyšujte

Krok 5: Průběžná optimalizace (ongoing)

1. Nastavte rozpočtové alerty a anomaly detection
2. Měsíčně revidujte utilizaci commitment slev
3. Optimalizujte SQL dotazy – neefektivní queries znamenají zbytečné compute náklady
4. Archivujte historická data do levnějšího úložiště

Srovnání úspor: Přehled všech strategií

Strategie	Poskytovatel	Potenciální úspora	Složitost
Eliminace idle databází	Všichni	10–30 %	Nízká
Right-sizing instancí	Všichni	20–40 %	Střední
Migrace na Graviton4	AWS	20–29 %	Nízká
Aurora I/O-Optimized	AWS	30–40 %	Nízká
Database Savings Plans	AWS	12–35 %	Nízká
Reserved Instances (3 roky)	AWS/Azure	Až 69–77 %	Střední
Azure Hybrid Benefit + RI	Azure	Až 80 %	Střední
DynamoDB Standard-IA	AWS	Až 60 % (storage)	Nízká
GCP Cloud SQL CUDs	GCP	Až 52 %	Nízká
BigQuery fyzický billing	GCP	70–80 % (storage)	Nízká

Často kladené otázky (FAQ)

Jaký je rozdíl mezi AWS Database Savings Plans a Reserved Instances pro RDS?

Database Savings Plans nabízejí flexibilitu napříč enginy, instance typy a regiony za slevu až 35 %. Reserved Instances poskytují vyšší slevy (až 69–77 %), ale vyžadují závazek ke konkrétní instance třídě, enginu a regionu. Pro stabilní produkční workloady jsou RI stále výhodnější. Pro proměnlivé nebo modernizující se prostředí jsou lepší Savings Plans. Oba typy nelze kombinovat na stejném workloadu.

Jak zjistím, jestli se mám přepnout na Aurora I/O-Optimized?

Podívejte se na svou měsíční Aurora fakturu v AWS Cost Explorer. Pokud I/O náklady (Aurora:StorageIOUsage) tvoří víc než 25 % celkového Aurora spendingu, I/O-Optimized vám pravděpodobně ušetří 30–40 %. Přepnutí je jednoduché, bez prostojů a bez migrace dat. A kdyby to náhodou nevyšlo, můžete se kdykoliv vrátit zpět.

Vyplatí se migrovat RDS instance na Graviton4?

Skoro vždycky ano. Graviton4 instance (r8g, m8g) nabízejí až 40 % vyšší výkon a až 29 % lepší poměr cena/výkon oproti Graviton3. Aurora a RDS pro MySQL i PostgreSQL jsou plně kompatibilní. Migrace se provádí jako standardní modify-db-instance operace. Jediná výjimka je proprietární software závislý na x86 architektuře – ale to je dost okrajový případ.

Jak kombinovat Azure Hybrid Benefit s Reserved Capacity pro maximální úspory?

Nejdřív aktivujte Azure Hybrid Benefit s existujícími SQL Server licencemi se Software Assurance – to ušetří až 55 %. Pak nakupte Reserved Capacity na 1 nebo 3 roky pro předvídatelné workloady. Kombinace obou přináší úspory až 80 %. Pro dev/test prostředí přidejte ještě Dev/Test pricing a celková úspora může dosáhnout 85 %.

Jsou Google Cloud BigQuery CUDs dostupné ve všech regionech?

BigQuery CUDs jsou region-specifické – závazek platí jen pro eligible usage ve zvoleném regionu. Pokud workloady přesunete jinam, sleva se automaticky nepřenese. Proto je důležité před nákupem CUD analyzovat, ve kterých regionech máte stabilní BigQuery spotřebu. Spend-based CUDs nabízejí širší pokrytí služeb (BigQuery Editions, Cloud Composer 3, BigQuery Data Governance), zatímco capacity commitments se zaměřují čistě na sloty.