Stratégie a osvedčené postupy 12 min čítania

Ako ušetriť 30–70 % na AWS databázach: 8 overených stratégií pre RDS, Aurora a DynamoDB

Databázy tvoria 25–40 % cloudových nákladov, no často sa prehliadajú pri optimalizácii. Naučte sa 8 overených stratégií na zníženie nákladov na AWS RDS, Aurora a DynamoDB o 30–70 % — vrátane Database Savings Plans, Graviton4 a Aurora Serverless v2.

Editorial Team

Databázy sú tichý zabijak vášho cloudového rozpočtu

Ruku na srdce — kedy ste naposledy poriadne prešli faktúru za AWS a pozreli sa, koľko vlastne platíte za databázy? Ak ste ako väčšina tímov, tak pravdepodobne dávno. A práve tam je problém.

Databázové služby patria medzi top 3 najdrahšie položky na účte za AWS u väčšiny organizácií — a paradoxne im venujeme najmenej pozornosti pri optimalizácii. Podľa aktuálnych údajov tvoria náklady na RDS, Aurora a DynamoDB v priemere 25–40 % celkových výdavkov na AWS. To je obrovské číslo.

Dobrá správa? S novými nástrojmi a cenovými modelmi, ktoré AWS predstavil koncom roka 2025, sa dajú tieto náklady znížiť o 30–70 % bez toho, aby ste obetovali výkon alebo dostupnosť. A nie, nie je to len teória.

V tomto sprievodcovi prejdeme 8 konkrétnych stratégií — od úplne nových Database Savings Plans, cez migráciu na Graviton4, až po Aurora Serverless v2 so škálovaním na nulu. Ku každej dostanete praktické príkazy AWS CLI a jasné kroky na implementáciu.

1. AWS Database Savings Plans: Revolučná novinka z re:Invent 2025

Toto je podľa mňa najzaujímavejšia zmena za posledné roky. V decembri 2025 AWS na re:Invent predstavil Database Savings Plans — prvý flexibilný záväzkový cenový model pre databázové služby. Dovtedy ste mali v podstate len dve možnosti: drahé on-demand ceny, alebo rigidné Reserved Instances zamknuté na konkrétnu konfiguráciu.

Ani jedno nebolo ideálne.

Čo pokrývajú Database Savings Plans?

Database Savings Plans pokrývajú 9 databázových služieb AWS:

  • Amazon RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)
  • Amazon Aurora (MySQL, PostgreSQL)
  • Amazon DynamoDB (on-demand throughput)
  • Amazon ElastiCache (Valkey)
  • Amazon DocumentDB
  • Amazon Neptune
  • Amazon Keyspaces
  • Amazon Timestream (InfluxDB)
  • AWS Database Migration Service

Kľúčové výhody oproti Reserved Instances

Najväčšou výhodou je jednoznačne flexibilita. Na rozdiel od Reserved Instances sa zľavy automaticky aplikujú bez ohľadu na:

  • Databázový engine — môžete pokojne migrovať z MySQL na PostgreSQL
  • Rodinu inštancií — prechod z r6g na r8g neovplyvní zľavu
  • Región — presun workloadu do iného regiónu je bezbolestný
  • Typ nasadenia — Single-AZ aj Multi-AZ
  • Serverless — a toto je prelomové: prvýkrát v histórii zľavy aj na Aurora Serverless v2 a DynamoDB on-demand

Koľko reálne ušetríte?

Database Savings Plans ponúkajú úspory 12–35 % oproti on-demand cenám. Na prvý pohľad to vyzerá menej ako maximálnych 69–77 % u Reserved Instances. Lenže — a to je kľúčové — flexibilita často prinesie väčšie reálne úspory. Prečo? Pretože sa vyhnete plytvaniu na zamknuté kapacity, ktoré už dávno nepotrebujete (a všetci vieme, ako rýchlo sa menia požiadavky).

Praktický príklad: Ako nakúpiť Database Savings Plan

Najprv si zistite svoj baseline. Tieto príkazy vám ukážu, koľko vlastne míňate:

# Zistite priemerné hodinové výdavky na databázy za posledných 30 dní
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity DAILY \
  --filter '{"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Relational Database Service", "Amazon DynamoDB", "Amazon Aurora"]}}' \
  --metrics "UnblendedCost" \
  --output json

# Získajte odporúčania pre Database Savings Plans
aws savingsplans describe-savings-plans-offering-rates \
  --savings-plan-offering-ids <offering-id> \
  --filters type=region,values=eu-west-1 \
  --output table

Odporúčaný postup: Začnite konzervatívne — záväzok na 70–80 % konzistentného baseline spotreby. Zvyšok pokryte on-demand cenami. Postupne pridávajte ďalšie záväzky, keď budete mať jasnejší obraz. Je lepšie začať opatrne a pridávať, ako sa zaviazať na príliš veľa a potom to ľutovať.

Database Savings Plans vs. Reserved Instances: Porovnanie

Pre väčšinu tímov je v roku 2026 najlepšia hybridná stratégia:

  • Reserved Instances pre stabilné produkčné databázy, ktoré nebudete meniť 1–3 roky (úspory až 69 %)
  • Database Savings Plans pre moderné, serverless a premenlivé workloady (úspory 12–35 %)
  • On-demand pre dev/test prostredia a nepredvídateľné špičky (nechajte si tu asi 20–30 % rozpočtu)

2. Right-sizing databáz s AWS Compute Optimizer

Takže, povedzme si to na rovinu — right-sizing je najrýchlejšia výhra pri optimalizácii databázových nákladov. Tímy, ktoré implementovali odporúčania Compute Optimizer, zaznamenali úspory 20–40 % len z tohto jedného kroku. Bez akýchkoľvek záväzkov či zmien v kóde.

Ako funguje Compute Optimizer pre RDS a Aurora

AWS Compute Optimizer analyzuje metriky z CloudWatch — využitie CPU, databázové pripojenia, sieťovú priepustnosť a IOPS úložiska. Ak máte zapnutý Performance Insights (čo vrelo odporúčam), analyzuje aj metriky ako DBLoad a swap, čo výrazne spresňuje odporúčania.

Pre každú databázu dostanete:

  • Stav — optimalizovaná, nedostatočne/nadmerne dimenzovaná, alebo nečinná
  • Dve alternatívy — jednu pre x86 a jednu pre Graviton architektúru
  • Odhadované mesačné úspory a hodnotenie výkonnostného rizika
  • Odporúčania pre úložisko — napríklad migrácia z gp2 na gp3

Krok za krokom: Aktivácia a použitie

# 1. Aktivujte Compute Optimizer (ak ešte nie je zapnutý)
aws compute-optimizer update-enrollment-status \
  --status Active

# 2. Počkajte 14 dní na zozbieranie dostatočných metrík

# 3. Získajte odporúčania pre RDS inštancie
aws compute-optimizer get-rds-database-recommendations \
  --output json | jq '.rdsDBRecommendations[] | {
    resourceArn: .resourceArn,
    finding: .finding,
    currentInstanceType: .currentDBInstanceClass,
    recommendation: .instanceRecommendationOptions[0].dbInstanceClass,
    estimatedMonthlySavings: .instanceRecommendationOptions[0].estimatedMonthlySavings
  }'

# 4. Získajte odporúčania pre úložisko
aws compute-optimizer get-rds-database-recommendation-projected-metrics \
  --resource-arn <your-rds-arn> \
  --stat AVERAGE \
  --period 86400 \
  --start-time 2026-02-01T00:00:00Z \
  --end-time 2026-03-01T00:00:00Z

Dôležitý tip: Nastavte lookback period na 32 dní (je bezplatný), aby ste zachytili mesačné vzory záťaže. Ak chcete ešte presnejšie výsledky, zvážte 93 dní — to ale vyžaduje Enhanced Infrastructure Metrics, čo je platená funkcia.

3. Migrácia na Graviton4: Lepší výkon za nižšiu cenu

Graviton4 inštancie (r8g, m8g) sú pre RDS a Aurora dostupné od konca roka 2025 a čísla hovoria samy za seba:

  • Až o 40 % rýchlejšie pre databázové workloady
  • Až o 29 % lepší pomer cena/výkon oproti Graviton3
  • 23 % nárast dotazov za sekundu (m8g vs. m7g)
  • 19 % pokles priemernej latencie
  • Vždy zapnuté šifrovanie pamäte

Úprimne, toto je jedna z tých zmien, kde naozaj nie je dôvod čakať.

Podporované databázy

Graviton4 inštancie (r8g/m8g) sú dostupné pre:

  • Aurora PostgreSQL
  • Aurora MySQL
  • RDS for PostgreSQL
  • RDS for MySQL
  • RDS for MariaDB

Pozor: Ak bežíte na Oracle alebo SQL Server — smola, tie sú obmedzené na x86 inštancie. Graviton tu jednoducho nie je možnosťou.

Postup migrácie na Graviton4

# 1. Skontrolujte dostupnosť r8g vo vašom regióne
aws rds describe-orderable-db-instance-options \
  --engine aurora-postgresql \
  --db-instance-class db.r8g.large \
  --region eu-west-1 \
  --output table

# 2. Vytvorte snapshot pred migráciou
aws rds create-db-snapshot \
  --db-instance-identifier my-production-db \
  --db-snapshot-identifier pre-graviton4-migration-backup

# 3. Modifikujte inštanciu na Graviton4 (v maintenance window)
aws rds modify-db-instance \
  --db-instance-identifier my-production-db \
  --db-instance-class db.r8g.large \
  --apply-immediately false

# 4. Sledujte výkon po migrácii
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=my-production-db \
  --start-time 2026-03-01T00:00:00Z \
  --end-time 2026-03-07T00:00:00Z \
  --period 3600 \
  --statistics Average

Tip: Vždy najskôr otestujte na neprodukčných prostrediach. Aj keď Graviton4 nevyžaduje žiadne zmeny v kóde (je to čisto infraštruktúrna zmena), preventívny test nikdy neuškodí.

4. Aurora I/O-Optimized: Ušetrite 30–40 % na I/O náročných workloadoch

Aurora I/O-Optimized je cenový model, ktorý robí jednu jednoduchú vec — nahrádza platenie za jednotlivé I/O operácie ($0,20 za milión operácií) fixnou vyššou cenou za úložisko so všetkými I/O zahrnutými. Znie to ako drobnosť, ale pre správne workloady to znamená masívne úspory.

Kedy sa oplatí prepnúť?

Jednoduché pravidlo: ak vaše I/O náklady tvoria viac ako 25 % celkového účtu za Aurora, I/O-Optimized sa vám takmer určite oplatí.

Ideálne use cases:

  • E-commerce platformy s vysokým počtom transakcií
  • IoT systémy s nepretržitým zápisom dát
  • Analytické workloady s náročnými dotazmi
  • Aplikácie s nepredvídateľnými vzormi I/O (toto sa často prehliada)

Ako analyzovať, či sa vám prepnutie oplatí

# 1. Zistite aktuálne I/O náklady z Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --filter '{"And": [{"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Aurora"]}}, {"Dimensions": {"Key": "USAGE_TYPE", "Values": ["EU-Aurora:StorageIOUsage"]}}]}' \
  --metrics "UnblendedCost"

# 2. Porovnajte s celkovými Aurora nákladmi
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --filter '{"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Aurora"]}}' \
  --metrics "UnblendedCost"

# 3. Prepnite na I/O-Optimized (bez výpadku)
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --storage-type aurora-iopt1 \
  --apply-immediately

Dôležité: Toto je čisto cenová zmena — výkon, latencia aj priepustnosť zostávajú úplne rovnaké. A čo je najlepšie, zmena sa aplikuje bez akéhokoľvek výpadku.

5. Aurora Serverless v2: Škálovanie na nulu pre dev/test prostredia

Aurora Serverless v2 teraz podporuje škálovanie na 0 ACU (Aurora Capacity Units). Áno, čítate správne — počas nečinnosti neplatíte za výpočtový výkon vôbec nič. Kapacita sa môže pohybovať od 0 do 256 ACU.

Ako funguje automatické pozastavenie

Keď databáza nemá žiadne aktívne pripojenia počas nastaveného intervalu (minimálne 300 sekúnd), inštancia sa automaticky pozastaví. Pri obnovení pripojenia sa zobudí — typicky do niekoľkých sekúnd.

Malá poznámka: ak je pozastavená viac ako 24 hodín, prechádza do hlbšieho spánku a obnovenie môže trvať 30+ sekúnd. Pre dev prostredie to väčšinou nie je problém.

Výpočet úspor

Cena Aurora Serverless v2 v regióne eu-west-1:

  • ACU-hodina: ~$0,12
  • Úložisko (Standard): $0,10/GB-mesiac + $0,20 za milión I/O
  • Úložisko (I/O-Optimized): $0,225/GB-mesiac (bez poplatkov za I/O)

Konkrétny príklad: Predstavte si dev databázu, ktorá je aktívna 8 hodín denne s priemerom 2 ACU a neaktívna zvyšných 16 hodín:

  • Provisioned db.r6g.large (24/7): ~$140/mesiac
  • Serverless v2 (8h × 2 ACU): 8 × 2 × $0,12 × 30 = ~$58/mesiac
  • Úspora: 59 %

To je $82 mesačne na jednej databáze. Ak máte 10 dev prostredí, hovoríme o $820 mesačne — teda takmer $10 000 ročne. To už nie je zanedbateľná suma.

Nastavenie Aurora Serverless v2 so škálovaním na nulu

# 1. Vytvorte cluster so škálovaním na 0 ACU
aws rds create-db-cluster \
  --db-cluster-identifier dev-serverless-cluster \
  --engine aurora-postgresql \
  --engine-version 16.4 \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=16 \
  --master-username admin \
  --manage-master-user-password

# 2. Pridajte serverless inštanciu
aws rds create-db-instance \
  --db-instance-identifier dev-serverless-instance \
  --db-cluster-identifier dev-serverless-cluster \
  --db-instance-class db.serverless \
  --engine aurora-postgresql

# 3. Nastavte interval automatického pozastavenia (v sekundách)
aws rds modify-db-cluster \
  --db-cluster-identifier dev-serverless-cluster \
  --serverless-v2-scaling-configuration \
    MinCapacity=0,MaxCapacity=16,SecondsUntilAutoPause=600

Upozornenie: Škálovanie na nulu je naozaj primárne pre dev/test prostredia. Pre produkciu nastavte minimálne 0,5–1 ACU — vyhnete sa cold-start latencii a váš tím vám poďakuje.

6. DynamoDB Standard-IA: Ušetrite až 60 % na úložisku

Máte DynamoDB tabuľky s dátami, ku ktorým pristupujete raz za čas? Logy, archívne záznamy, historické dáta? Prepnutie na Standard-IA (Infrequent Access) vám môže znížiť náklady na úložisko až o 60 %.

A najlepšie na tom je, že to nevyžaduje žiadny výpadok, migráciu dát ani zmeny v kóde. Je to čisto konfiguračná zmena s identickou latenciou, priepustnosťou a dostupnosťou.

# 1. Identifikujte tabuľky s nízkym prístupom
aws dynamodb describe-table \
  --table-name my-archive-table \
  --query 'Table.{Name:TableName, SizeBytes:TableSizeBytes, ItemCount:ItemCount, TableClass:TableClassSummary.TableClass}'

# 2. Prepnite na Standard-IA
aws dynamodb update-table \
  --table-name my-archive-table \
  --table-class STANDARD_INFREQUENT_ACCESS

# 3. Overte zmenu
aws dynamodb describe-table \
  --table-name my-archive-table \
  --query 'Table.TableClassSummary'

Kedy sa Standard-IA oplatí a kedy nie

  • Oplatí sa: Tabuľky s veľkým objemom dát a nízkym počtom čítaní/zápisov — archívy, audit logy, historické záznamy
  • Neoplatí sa: Tabuľky s vysokým throughputom, kde vyššie poplatky za čítanie/zápis prevážia úspory na úložisku (tu si radšej najskôr spravte kalkuláciu)

7. Optimalizácia úložiska RDS: Migrácia z gp2 na gp3

Ak stále používate úložisko gp2 pre svoje RDS inštancie, prichádzate o jednoduché peniaze. Vážne. GP3 ponúka:

  • Nižšiu cenu za GB oproti gp2
  • Baseline 3 000 IOPS a 125 MB/s priepustnosť zahrnuté v cene (pre zväzky do 400 GiB)
  • Nezávislé škálovanie IOPS a priepustnosti — platíte len za to, čo skutočne potrebujete
# Migrácia z gp2 na gp3
aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --storage-type gp3 \
  --apply-immediately

# Pre databázy vyžadujúce vyšší IOPS
aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --storage-type gp3 \
  --iops 6000 \
  --storage-throughput 250 \
  --apply-immediately

Toto je asi najjednoduchšia optimalizácia v celom zozname. Dva príkazy a hotovo.

8. Správa snapshotov a zálohovania

Snapshoty a zálohy sú často prehliadaný zdroj nákladov — potichu rastú na pozadí a nikto si ich nevšíma, kým nepríde prekvapivo veľký účet. Niekoľko jednoduchých krokov vám pomôže:

  • Znížte retenčné obdobie záloh na minimum potrebné pre compliance (7 dní namiesto predvoleného)
  • Odstráňte manuálne snapshoty, ktoré už nepotrebujete — pozor, tieto sa nikdy automaticky nemažú
  • Exportujte snapshoty do S3 pre dlhodobú archiváciu — úložisko S3 je približne 5× lacnejšie ako RDS snapshoty
# Nájdite staré manuálne snapshoty
aws rds describe-db-snapshots \
  --snapshot-type manual \
  --query 'DBSnapshots[?SnapshotCreateTime<=`2025-12-01`].{ID:DBSnapshotIdentifier, Created:SnapshotCreateTime, Size:AllocatedStorage}' \
  --output table

# Exportujte snapshot do S3 pred odstránením
aws rds start-export-task \
  --export-task-identifier my-snapshot-export \
  --source-arn arn:aws:rds:eu-west-1:123456789:snapshot:my-old-snapshot \
  --s3-bucket-name my-rds-exports \
  --iam-role-arn arn:aws:iam::123456789:role/rds-s3-export-role \
  --kms-key-id my-kms-key-id

Kompletný optimalizačný playbook: Správne poradie krokov

A teraz to najdôležitejšie — poradie optimalizácie je kriticky dôležité. Toto je chyba, ktorú vidím opakovane: tímy si najskôr kúpia Savings Plans alebo Reserved Instances a až potom začnú s right-sizingom. Výsledok? Zaviažu sa platiť za kapacity, ktoré vôbec nepotrebujú.

Tu je správne poradie:

  1. Eliminujte plytvanie — odstráňte nečinné inštancie, nepotrebné snapshoty, nevyužité Multi-AZ nasadenia
  2. Right-sizing — použite Compute Optimizer na zmenšenie nadmerne dimenzovaných inštancií
  3. Migrujte na Graviton4 — prejdite na r8g/m8g inštancie pre lepší pomer cena/výkon
  4. Optimalizujte úložisko — prepnite na gp3, vyhodnoťte Aurora I/O-Optimized
  5. Zvážte serverless — Aurora Serverless v2 pre dev/test alebo premenlivé workloady
  6. Záväzkové zľavy — až teraz nakúpte Reserved Instances a Database Savings Plans na nový, optimalizovaný baseline

Ten posledný bod je kľúčový. Záväzky si kupujete až vtedy, keď viete, aký je váš skutočný optimalizovaný baseline — nie predtým.

Často kladené otázky

Aký je rozdiel medzi Database Savings Plans a Reserved Instances?

Database Savings Plans ponúkajú flexibilné zľavy 12–35 % naprieč 9 databázovými službami, regiónmi a typmi inštancií. Reserved Instances dávajú vyššie zľavy (až 69–77 %), ale sú zamknuté na konkrétny engine, rodinu inštancií a región. Pre väčšinu tímov funguje najlepšie kombinácia oboch — RI pre stabilné produkčné databázy a DSP pre premenlivé workloady.

Ako zistím, či je moja RDS inštancia nadmerne dimenzovaná?

Najjednoduchšie je aktivovať AWS Compute Optimizer. Analyzuje 14–93 dní CloudWatch metrík (CPU, pamäť, IOPS, sieť) a poskytne konkrétne odporúčania na zmenu typu inštancie vrátane odhadu mesačných úspor. Pre presnejšie výsledky zapnite aj Performance Insights.

Je Aurora Serverless v2 vhodná pre produkciu?

Áno, Aurora Serverless v2 je navrhnutá pre produkčné nasadenia. Ale pozor — funkcia škálovania na 0 ACU je primárne pre dev/test prostredia. Pre produkciu nastavte minimálnu kapacitu na 0,5–1 ACU, aby ste eliminovali cold-start latenciu.

Koľko ušetrím migráciou na Graviton4?

Graviton4 inštancie (r8g/m8g) ponúkajú až 29 % lepší pomer cena/výkon oproti Graviton3 a až 40 % lepší výkon pre databázy. Migrácia nevyžaduje žiadne zmeny v kóde — je to čisto infraštruktúrna zmena, ktorú si môžete bez obáv najskôr vyskúšať na neprodukčných prostrediach.

Môžem kombinovať Database Savings Plans s Reserved Instances?

Samozrejme. AWS najprv aplikuje zľavu z Reserved Instances a následne Database Savings Plans na zostávajúcu spotrebu. Optimálna stratégia je pokryť stabilný baseline cez RI, premenlivú časť cez Database Savings Plans a na nepredvídateľné špičky nechať on-demand.

O Autorovi Editorial Team

Our team of expert writers and editors.

Súvisiace Články