Amazon Redshift Náklady 2026: Ako Ušetriť 40 až 60 % na RA3, Serverless a Concurrency Scaling

Aktualizované: 12. september 2026

Amazon Redshift náklady v roku 2026 znížite najrýchlejšie kombináciou troch pák: prechodom na RA3 uzly s oddeleným compute a storage, migráciou nepravidelných workloadov na Redshift Serverless a nákupom Reserved Nodes na stabilný baseline (úspora až 75 % oproti on-demand). U našich klientov to v praxi znamená 40 až 60 % nižší mesačný účet za rovnaké alebo lepšie SLA na queries. Honestly, väčšina tímov s ktorými pracujem nevedela ani presne pomenovať, za čo v tom účte vlastne platí. V tomto sprievodcovi rozpíšem, kedy siahnuť po ktorej páke, ako čítať vydieračské položky v Cost Explorer a aké dotazy do SVL_QUERY_METRICS vám ukážu, kde peniaze naozaj utekajú.

• RA3 uzly (ra3.large, ra3.xlplus, ra3.4xlarge, ra3.16xlarge) oddeľujú compute a storage. Platíte $0,024/GB/mesiac za managed storage namiesto zbytočne veľkých DC2 uzlov len kvôli disku.
• Redshift Serverless účtuje $0,375/RPU-hodina (US East, min. 8 RPU). Dáva zmysel pre workloady s využitím pod ~30 % dňa, inak provisioned RA3 vyjde lacnejšie.
• Concurrency Scaling má 1 hodinu voľných kreditov denne za každú aktívnu hodinu hlavného clustera. Dvojnásobná fakturácia začne až po prekročení.
• Reserved Nodes na 3 roky s upfront platbou dávajú až 75 % zľavu. Vhodné len pre stabilný baseline compute, nikdy nie pre celý cluster.
• Materialized views s AUTO REFRESH, WLM Query Monitoring Rules a Redshift Spectrum na chladné dáta v S3 znížia typický účet o ďalších 15 až 25 %.
• Pause/Resume cez EventBridge (RA3 provisioned) alebo Serverless capacity limits eliminujú 100 % compute nákladov mimo pracovných hodín pre dev/test prostredia.

Ako funguje Redshift cenník v roku 2026

V roku 2026 má Amazon Redshift tri fakturačné modely, ktoré sa dajú miešať v rámci jedného účtu: Redshift Serverless, RA3 provisioned a Redshift Spectrum. Ak neviete, za čo presne platíte, nemáte šancu optimalizovať. Začnem preto detailmi cenníka podľa najnovších čísel v regióne us-east-1 (podľa oficiálneho Redshift cenníka).

Serverless sa účtuje v Redshift Processing Units (RPU). Minimálna kapacita je 8 RPU, base cena $0,375/RPU-hodina. Cluster sa automaticky prebudí pri prvom dotaze a uspí po ~5 minútach neaktivity. Storage v Serverless režime platíte oddelene za RMS (Redshift Managed Storage), teda $0,024/GB/mesiac.

RA3 provisioned máte v štyroch veľkostiach: ra3.large (2 vCPU, $0,326/h), ra3.xlplus (4 vCPU, $1,086/h), ra3.4xlarge (12 vCPU, $3,26/h) a ra3.16xlarge (48 vCPU, $13,04/h). Storage je opäť RMS s tou istou cenou. Kľúčové je, že compute a storage škálujete nezávisle. Starý model DC2 (kde ste kupovali uzly aj kvôli disku) už nedáva zmysel a AWS ho postupne sťahuje z ponuky.

Redshift Spectrum vám umožní queryovať Parquet/ORC súbory priamo v S3 za $5,00/TB naskenovaných dát. Používa sa cez externé schémy s Glue Data Catalog a je ideálny pre archívne fact tabuľky, ktoré chcete raz za týždeň analyzovať bez zaťaženia clustera.

Cez roky som v spreadsheetoch modelovala desiatky Redshift účtov a jedna vec je konštantná: ak nespočítate jednotkovú cenu $/naskenovaný GB, $/RPU-hodina a $/uzol-hodina cez tri modely súčasne, s najväčšou pravdepodobnosťou platíte 30 až 50 % zbytočne.

Prečo váš Redshift účet rastie: 7 najčastejších dier

Než začnete strihať, potrebujete presne vedieť, kde peniaze utekajú. Pri auditoch v multi-account prostrediach (typicky 4 až 12 Redshift clusterov v produkcii, staging a analytics accounte) narážam stále dokola na tie isté vzory. Ak ich rozpoznáte skôr, ako budete kupovať Reserved Nodes, ušetríte si nákup rezervácií na kapacitu, ktorú vôbec nepotrebujete.

1. Nadmerne dimenzovaný cluster kvôli storage

Klasický vzor z DC2 čias. Tím pridal uzly, lebo im nestačil disk, aj keď CPU bolo na 15 %. Migrácia na RA3 tento problém eliminuje: disk je elastický, platíte len za skutočne uložené GB. V spreadsheeti si spočítajte $(počet DC2 uzlov × cena) − $(minimálny RA3 count × cena) − $(reálne GB × 0,024)$.

2. Concurrency Scaling bez limitu

Feature, ktorý sa hodí, no bez max_concurrency_scaling_clusters limitu môže behom peak hodín zdvojnásobiť účet. Denné voľné kredity (1 hodina za každú hodinu základného clustera) sa spotrebujú okolo obeda a zvyšok dňa platíte za druhý cluster.

3. Idle clustery cez víkend

Dev, staging a data science clustery bežia 168 hodín týždenne, aj keď ich niekto reálne používa 40. Pause/Resume alebo Serverless model dokáže odstrihnúť 76 % nákladov.

4. Redshift Spectrum bez partition pruning

Spectrum je fajn, ale len ak neskenujete plné tabuľky. Bez partition kľúčov v WHERE klauzule a bez columnar formátu (Parquet) sa jeden dashboard môže vyšplhať aj na $50 až $100 za spustenie.

5. Chýbajúce Reserved Nodes na baseline

Ak beží 24×7 aspoň jeden RA3.4xlarge cluster viac ako rok, on-demand cena je hazard. 3-year all-upfront zľava je až 75 %.

6. Neefektívne dotazy s cross-join a broadcastom

Jeden zle napísaný ETL dotaz vie za noc vygenerovať toľko CPU cyklov, koľko celý remote reporting tím za deň. QMR (Query Monitoring Rules) ich zabijú automaticky.

7. Chýbajúca lifecycle politika na Spectrum data v S3

Fact tabuľky bez S3 Intelligent-Tiering alebo Glacier prechodu stoja $0,023/GB/mesiac v S3 Standard, aj keď sa ich dotýkate raz za štvrťrok. Detaily nájdete v mojom sprievodcovi optimalizáciou cloud storage nákladov.

Redshift Serverless vs RA3: ktorý model je lacnejší?

Toto je otázka, na ktorú neexistuje univerzálna odpoveď. Závisí od utilizácie a predvídateľnosti workloadu. Serverless dáva zmysel pre workloady, kde compute beží menej ako ~30 % dňa. Provisioned RA3 vyhráva pri stabilnom 24×7 zaťažení.

Vlastnosť	Redshift Serverless	RA3 Provisioned
Cenový model	$0,375/RPU-hodina (min. 8 RPU)	$0,326 až $13,04/uzol-hodina
Minimálna cena mesačne	~$219 (idle, cold start)	~$237 (1× ra3.large 24×7)
Auto-pause	Áno, po ~5 min	Manuálne cez pause API
Reserved discounts	Áno, na Serverless RPU (2026)	Áno, až 75 % na 3 roky
Concurrency Scaling	Zabudované (autoškáluje RPU)	Samostatná služba s free kreditmi
Predvídateľnosť účtu	Nízka (RPU-hodiny podľa dotazov)	Vysoká (fixný počet uzlov)
Ideálny use case	BI dashboardy, ad-hoc analýza, dev/test	ETL pipelines, 24×7 reporting, produkčný DWH

V mojich alokačných modeloch používam nasledujúci vzorec: ak (počet RPU-hodín za mesiac × $0,375) > (mesačná cena rovnakého RA3 clustra × 0,7), je čas prejsť na provisioned. Tých sedemdesiat percent zohľadňuje priestor pre Reserved Nodes, ktoré si následne kúpite.

Ako správne dimenzovať RA3 uzly a využiť Concurrency Scaling

Rightsizing Redshift clustra nie je len o počte uzlov. Je o pomere slots, queue timings a disk-based query ratio. Kľúčové metriky pozerám v SVL_QUERY_METRICS_SUMMARY a STL_WLM_QUERY.

-- Percento dotazov ktoré tečú na disk (indikátor príliš malých uzlov)
SELECT
  DATE_TRUNC('hour', starttime) AS hour_bucket,
  COUNT(*) AS total_queries,
  SUM(CASE WHEN is_diskbased = 't' THEN 1 ELSE 0 END) AS disk_queries,
  ROUND(100.0 * SUM(CASE WHEN is_diskbased = 't' THEN 1 ELSE 0 END) / COUNT(*), 2) AS pct_disk
FROM SVL_QUERY_SUMMARY
WHERE starttime > DATEADD(day, -7, GETDATE())
GROUP BY 1
ORDER BY 1;

Ak pct_disk stabilne presahuje 10 %, potrebujete buď väčšie uzly, alebo viac uzlov v clustri. Naopak, ak je pod 1 % a priemerné CPU využitie v CloudWatch je pod 40 %, ste predimenzovaní.

Concurrency Scaling je jednoduchá záchranná páka pre špičky, ale zapnite ju s tvrdým limitom. V parameter groupe nastavte:

-- V parameter group nastavte max počet CS clusterov
max_concurrency_scaling_clusters = 2

-- V databáze zapnite CS pre špecifickú WLM queue
ALTER USER etl_user SET concurrency_scaling = auto;

-- Overte využitie voľných kreditov cez posledných 7 dní
SELECT
  DATE_TRUNC('day', starttime) AS day,
  COUNT(*) AS cs_queries,
  SUM(elapsed_time)/1000000.0 AS cs_elapsed_seconds
FROM STL_QUERY
WHERE concurrency_scaling_status = 1
  AND starttime > DATEADD(day, -7, GETDATE())
GROUP BY 1
ORDER BY 1;

Ak cs_elapsed_seconds denne prekračuje 3600 (teda tú jednu voľnú hodinu), platíte za druhý cluster. Spočítajte, či by nebolo lacnejšie zväčšiť hlavný cluster o jeden uzol.

Reserved Nodes: úspora až 75 % pri stabilnom load

Reserved Nodes fungujú podobne ako EC2 Reserved Instances. Kupujete kapacitu na 1 alebo 3 roky, s možnosťou upfront, partial upfront alebo no-upfront platby. Zľavy pri 3-year all-upfront dosahujú 75 % voči on-demand pri RA3 uzloch (AWS to potvrdzuje v oficiálnej dokumentácii Reserved Node purchases).

Zlaté pravidlo: kupujte len baseline, teda tú kapacitu, ktorú beziete 24×7 celý rok. Nikdy nie peak. Pri audite si vyexportujte hodinové CloudWatch metriky NumberOfNodes za posledných 12 mesiacov a nájdite 5. percentil. To je vaša bezpečná baseline pre 3-year commit.

# Python skript na výpočet Redshift baseline z CloudWatch dát
import boto3
from datetime import datetime, timedelta
import numpy as np

cw = boto3.client('cloudwatch')
end = datetime.utcnow()
start = end - timedelta(days=365)

resp = cw.get_metric_statistics(
    Namespace='AWS/Redshift',
    MetricName='NumberOfNodes',
    Dimensions=[{'Name': 'ClusterIdentifier', 'Value': 'analytics-prod'}],
    StartTime=start,
    EndTime=end,
    Period=3600,
    Statistics=['Average']
)

values = [d['Average'] for d in resp['Datapoints']]
baseline_p5 = np.percentile(values, 5)
baseline_p50 = np.percentile(values, 50)

print(f"5th percentil (bezpečná 3-year rezervácia): {baseline_p5:.1f} nodov")
print(f"50th percentil (agresívnejšia 1-year rezervácia): {baseline_p50:.1f} nodov")

Podobný prístup som popísala aj v článku o Savings Plans vs Reserved Instances. Redshift Reserved Nodes stále nie sú súčasťou Compute Savings Plans, takže sa musia kupovať separátne.

Ako znížiť náklady na storage cez RA3 managed storage a Redshift Spectrum

Storage býva pri Redshift účte podceňovaný. Pri tabuľkách s históriou 5 až 10 rokov môže tvoriť 30 až 40 % mesačnej faktúry. Základné páky sú tri: kompresia, partition pruning a odsun chladných dát do S3 Spectrum.

Kompresné algoritmy: ZSTD by default

Od roku 2023 je ZSTD odporúčaný default pre väčšinu column types. Ak máte staršie tabuľky s LZO alebo bez kompresie, spustite ANALYZE COMPRESSION:

ANALYZE COMPRESSION public.fact_orders;

Typický zisk pri prechode na ZSTD je 30 až 50 % menšia RMS spotreba. Pri 10 TB tabuľke to je $72 až $120/mesiac len na storage.

Odsun cold dát do S3 cez Redshift Spectrum

Pre fact tabuľky staršie ako 90 dní odporúčam nasledujúci vzor:

1. UNLOAD dát staršich ako 90 dní do S3 v Parquet formáte s partition po dni.
2. Vytvorte externú tabuľku v Glue Data Catalog s rovnakou schémou.
3. Vytvorte view, ktorý spája live tabuľku (posledných 90 dní) s Spectrum tabuľkou (starší dáta).
4. Nastavte S3 Intelligent-Tiering na bucket. Po 90 dňoch neaktivity pôjdu chunky do Infrequent Access ($0,0125/GB), po 180 dňoch do Glacier Instant ($0,004/GB).

-- UNLOAD historických partícií do S3 Parquet
UNLOAD ('SELECT * FROM fact_orders WHERE order_date < DATEADD(day, -90, CURRENT_DATE)')
TO 's3://acme-dwh-archive/fact_orders/'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftUnloadRole'
FORMAT PARQUET
PARTITION BY (order_date)
ALLOWOVERWRITE;

-- Externá tabuľka v Glue
CREATE EXTERNAL SCHEMA IF NOT EXISTS archive_schema
FROM DATA CATALOG DATABASE 'acme_dwh_archive'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole';

-- Union view pre transparentné čítanie
CREATE OR REPLACE VIEW public.fact_orders_all AS
SELECT * FROM public.fact_orders
UNION ALL
SELECT * FROM archive_schema.fact_orders;

Výsledok: hot partície (~90 dní) žijú v RMS s ~$0,024/GB, chladné roky v S3 za $0,004 až $0,0125/GB. To je 5 až 6× lacnejšie za storage a zároveň sa uvoľní compute kapacita, ktorá už netreba udržiavať staré partície v pamäti.

Materialized views, WLM queues a Query Monitoring Rules

Compute nešetríte len hardvérom, šetríte hlavne dizajnom dotazov. Tri techniky, ktoré posunú využitie RA3 uzlov o 20 až 30 % nadol: materialized views, Automatic WLM a Query Monitoring Rules (QMR).

Materialized views s AUTO REFRESH

Ak máte BI dashboardy, ktoré každých 5 minút agregujú tie isté fact-y, MV vám ušetria opakovaný scan. Od roku 2023 Redshift automaticky prepisuje kompatibilné dotazy tak, aby siahali na MV.

CREATE MATERIALIZED VIEW mv_daily_revenue
BACKUP NO
AUTO REFRESH YES
AS
SELECT
  order_date,
  region,
  SUM(revenue) AS total_revenue,
  COUNT(DISTINCT order_id) AS order_count
FROM fact_orders
WHERE order_date >= DATEADD(day, -30, CURRENT_DATE)
GROUP BY 1, 2;

Automatic WLM s prioritou

Manuálne WLM slots sú dnes zbytočný ceremoniál. Automatic WLM sa učí typické query fingerprints a alokuje memory dynamicky. To, čo potrebujete definovať, sú priority tier-y: highest, high, normal, low, lowest. Interné BI dashboardy dajte na high, ad-hoc analystov na normal, batch ETL na low.

Query Monitoring Rules: automatické zabíjanie ETL beštií

QMR je najlacnejší kontroler nákladov, aký existuje. Pravidlá typu "ak dotaz beží 30+ minút a scan >500 GB, zabi ho" ušetria desiatky Concurrency Scaling hodín mesačne. I hit this exact bug ešte v roku 2024 pri jednom retail klientovi. Jeden zabudnutý cross-join v nočnom ETL nám vygeneroval $1 400 za CS za jednu noc. Odvtedy QMR patrí do každého môjho baseline setupu.

-- Príklad QMR v JSON pre parameter group
{
  "query_group": [],
  "query_group_wild_card": 0,
  "user_group": [],
  "user_group_wild_card": 0,
  "rules": [
    {
      "rule_name": "kill_long_running",
      "predicate": [
        {"metric_name": "query_execution_time", "operator": ">", "value": 1800},
        {"metric_name": "scan_row_count", "operator": ">", "value": 1000000000}
      ],
      "action": "abort"
    },
    {
      "rule_name": "log_expensive_disk_spill",
      "predicate": [
        {"metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 100000}
      ],
      "action": "log"
    }
  ]
}

Ako pauzovať a obnoviť Redshift cluster pre dev/test

Provisioned RA3 clustery viete pauznúť cez API. Počas pauzy platíte len za storage (RMS), compute sa neúčtuje. Dev/staging cluster bežiaci 45 hodín týždenne namiesto 168 zníži účet o 73 %.

# EventBridge pravidlo cez CDK/CloudFormation
# Pauza každý piatok o 20:00, resume každý pondelok o 07:00

aws events put-rule \
  --name RedshiftPauseWeekend \
  --schedule-expression "cron(0 20 ? * FRI *)" \
  --state ENABLED

aws events put-targets \
  --rule RedshiftPauseWeekend \
  --targets '[{
    "Id":"1",
    "Arn":"arn:aws:redshift:us-east-1:123456789012:cluster:dev-analytics",
    "RoleArn":"arn:aws:iam::123456789012:role/EventBridgeRedshiftRole",
    "RedshiftDataParameters":{"Sql":"PAUSE"}
  }]'

Serverless variantu robíte cez max-capacity limit. V pracovnom čase nastavte 128 RPU, mimo pracovnej doby 8 RPU. Query nezastavíte, ale zabránite tomu, aby vám niekto o polnoci spustil dotaz za $500.

Monitorovanie, alerty a detekcia anomálií nákladov

Bez monitorovania sa všetka predchádzajúca práca za pár mesiacov rozpustí. Odporúčam trojvrstvový setup: CloudWatch alarmy na cluster metriky, AWS Cost Anomaly Detection na Redshift usage type a vlastný QuickSight dashboard nad CUR (Cost and Usage Report) alebo FOCUS 1.2 datasetom.

Pre unifikovaný multi-cloud pohľad odporúčam FOCUS štandard. Postup som rozpisala v článku o FOCUS 1.2 zjednotení fakturácie AWS, Azure a GCP. Redshift usage v CUR má v roku 2026 týchto kľúčových usageType hodnôt:

• USE1-Node:ra3.4xlarge, teda hodiny RA3 uzlov
• USE1-RMS-Storage-Bytes, teda RMS storage v GB-mesiacoch
• USE1-CS:ra3.4xlarge, teda Concurrency Scaling hodiny nad rámec free kreditov
• USE1-Spectrum-DataScan-Bytes, teda Spectrum naskenované TB
• USE1-Serverless-RPU-Hours, teda Serverless RPU-hodiny

Cost Anomaly Detection nastavte na Redshift service s prahom $50 nad predikciu. Alert príde priamo do Slack cez SNS + Chatbot, typicky do 24 hodín od nezvyčajného utraty.

Časté otázky

Kedy je Redshift Serverless drahší ako RA3 provisioned?

Serverless začne byť drahší, keď súhrnná spotreba RPU-hodín za mesiac prekročí ~50 až 60 % ekvivalentu 24×7 RA3 clustera. Praktický prah: ak sledujete v Cost Explorer, že RPU-hodiny narastajú lineárne s pracovným dňom aj cez víkend, migrujte na provisioned RA3 s Reserved Nodes.

Ako sa účtuje Concurrency Scaling v roku 2026?

Za každú aktívnu hodinu hlavného clustra dostávate 1 hodinu voľných CS kreditov denne. Po prekročení platíte plnú on-demand cenu druhého clustra, napríklad ra3.4xlarge cluster = $3,26/h navyše za CS.

Oplatí sa migrácia z DC2 na RA3 uzly?

Áno v 95 % prípadov. RA3 oddeľuje storage a compute, takže neplatíte zbytočnú compute kapacitu len kvôli lokálnym SSD. Typická úspora pri migrácii je 20 až 40 %, no otestujte najprv workload. DC2 mal miestami rýchlejšie sequential scan na malých tabuľkách.

Ako často treba refreshovať materialized views?

S AUTO REFRESH YES Redshift refreshuje automaticky, keď má voľnú kapacitu, typicky do 15 minút od zmeny base tabuľky. Pri veľkých dashboardoch nastavte MV len na aggregation queries s GROUP BY, nie na plné SELECTy. Manuálny refresh cez REFRESH MATERIALIZED VIEW využite pre kontrolovaný ETL cyklus.

Aký je rozdiel medzi Redshift Spectrum a Redshift Serverless?

Spectrum je query engine, ktorý číta externé dáta v S3 z existujúceho Redshift clustra a účtuje sa $5/TB naskenovaných dát. Serverless je celý Redshift bez provisioned clustra a účtuje sa RPU-hodinami. Spectrum používate ako doplnok k RA3 alebo Serverless clustrom pre archívne dáta.

Aké tagy nastaviť na Redshift cluster pre cost allocation?

Minimálne: Environment, Owner, CostCenter, DataDomain. Redshift tagy sa propagujú do CUR aj do RMS storage komponentov. Detailný postup a Terraform šablóny nájdete v mojom sprievodcovi cloud tagging stratégiou.