Úvod: Proč je cloudové úložiště tichým žroutem vašeho rozpočtu
Když se řekne „optimalizace cloudových nákladů", většina týmů okamžitě pomyslí na compute – right-sizing instancí, spot instance, reserved capacity. Úložiště? To se nějak přehlíží. A přitom podle studie Crayon ze září 2025 má 94 % IT lídrů stále problémy s optimalizací nákladů na cloudové úložiště. I po letech práce s cloudem.
No a není divu. Cloudové úložiště roste organicky, tiše a pořád. Logy se hromadí, zálohy se vrší, staré verze souborů zabírají místo a nikdo se k promazání neodhodlá. A k tomu přidejte fakt, že cenový model služeb jako AWS S3 má tolik dimenzí – storage class, typ requestu, retrieval tier, data transfer, management features – že predikce nákladů je vlastně skoro nemožná. Rozdíl mezi nejlevnější a nejdražší storage třídou? Klidně 23násobný.
V předchozích článcích jsme si ukázali, jak optimalizovat náklady na Kubernetes, AI/ML workloady a serverless funkce. Dnes pokračujeme tím, co všechny tyto workloady spojuje – úložištěm dat. Projdeme si srovnání cen AWS S3, Azure Blob Storage a Google Cloud Storage, odhalíme skryté náklady, které většina týmů přehlíží, a ukážeme konkrétní postupy, jak dostat náklady na storage dolů o 40–80 %.
Srovnání storage tříd: AWS S3 vs. Azure Blob vs. Google Cloud Storage
Než se do toho pustíme, potřebujeme rozumět tomu, jaké úrovně úložiště jednotliví poskytovatelé nabízejí. Všichni tři velcí hráči mají vícestupňový model – od „horkého" úložiště pro často přistupovaná data po archivní třídy pro data, ke kterým se téměř nikdy nesahá.
Přehled storage tříd
| Úroveň | AWS S3 | Azure Blob Storage | Google Cloud Storage |
|---|---|---|---|
| Horká (častý přístup) | S3 Standard | Hot | Standard |
| Chladná (méně častý přístup) | S3 Standard-IA / One Zone-IA | Cool | Nearline |
| Studená (občasný přístup) | S3 Glacier Instant Retrieval | Cold | Coldline |
| Archivní (vzácný přístup) | S3 Glacier Flexible / Deep Archive | Archive | Archive |
| Automatické tierování | S3 Intelligent-Tiering | – | Autoclass |
Srovnání cen za úložiště (US East / US regiony, za GB/měsíc)
| Storage třída | AWS S3 | Azure Blob | GCS |
|---|---|---|---|
| Hot / Standard | $0,023 | $0,018 (LRS) / $0,023 (ZRS) | $0,020 |
| Cool / Nearline | $0,0125 (IA) | $0,010 | $0,010 |
| Cold / Coldline | $0,004 (Glacier Instant) | $0,0045 | $0,004 |
| Archive / Deep Archive | $0,00099 (Deep Archive) | $0,002 | $0,0012 |
Důležitý detail: Azure Blob s Local Redundant Storage (LRS) je v hot tieru nejlevnější. Jakmile ale přejdete na Zone-Redundant Storage (ZRS) kvůli vyšší dostupnosti, cena se vyrovná AWS S3. A AWS S3 Glacier Deep Archive? Pouhých $0,00099/GB/měsíc – jedna z nejlevnějších archivních služeb vůbec. To je o polovinu méně než Azure Archive.
5 skrytých nákladů na cloudové úložiště, které vás ženou nahoru
Samotná cena za GB/měsíc je jen špička ledovce. Skutečné náklady se skládají z řady dalších položek, které týmy běžně přehlížejí. Tak pojďme na to.
1. Egress fees – odchozí datový přenos
Tohle je pravděpodobně ten největší „skrytý" náklad. Kdykoli data opouštějí cloud poskytovatele – ať už směrem k uživatelům, do jiného regionu nebo k jinému poskytovateli – platíte egress fee. A ty se můžou vyšplhat na 3–5násobek samotných nákladů na úložiště. Upřímně, tohle číslo mě samo překvapilo, když jsem ho poprvé viděl na faktuře.
| Poskytovatel | Egress do internetu (prvních 10 TB) |
|---|---|
| AWS S3 | $0,09/GB |
| Azure Blob | $0,087/GB |
| Google Cloud Storage | $0,12/GB (první 1 TB), $0,11/GB (1–10 TB) |
Příklad z praxe: webová aplikace, která servíruje 5 TB dynamického obsahu měsíčně přes CDN, zaplatí na egress fees $400–$600/měsíc – bez ohledu na to, jak levné je samotné úložiště. Britský regulátor Ofcom dokonce označil egress fees za „pravděpodobně nepotřebné pro pokrytí nákladů" a příklad antikonkurenčního chování. Ale u běžného provozu tyto poplatky bohužel stále platí.
2. API requesty – poplatky za operace
Každý PUT, GET, LIST, COPY a DELETE volání má svou cenu. A liší se nejen podle poskytovatele, ale taky podle storage třídy. U archivních tříd mohou být retrieval fees výrazně vyšší než u standardního tieru.
Typické ceny na AWS S3:
- PUT/COPY/POST/LIST: $0,005 za 1 000 requestů (Standard), $0,01 za 1 000 requestů (IA)
- GET/SELECT: $0,0004 za 1 000 requestů (Standard), $0,001 za 1 000 requestů (IA)
- Glacier retrieval: závisí na rychlosti – Expedited může stát $0,03/GB + $10 za 1 000 requestů
Pro workloady s miliony malých souborů a častými LIST operacemi (třeba data lake indexování) mohou API requesty překonat samotné náklady na úložiště. Spousta týmů to zjistí až z faktury – a to už je pozdě na prevenci.
3. Versioning a nekompletní multipart uploady
Versioning je skvělá věc pro ochranu dat – ale má svou cenu. Každá verze každého objektu se ukládá a fakturuje zvlášť. Bucket s 1 TB dat a zapnutým versioningem může tiše narůst na 5 TB během pár měsíců, pokud se staré verze automaticky nečistí. To je pětinásobek. Tiše, bez varování.
Podobný problém představují nekompletní multipart uploady. Když upload selže uprostřed (a věřte mi, stává se to častěji, než byste čekali), částečně nahraná data zůstávají v bucketu a účtují se za standardní sazby – navždy, dokud je explicitně nesmažete.
4. Early deletion charges
Přesunutí dat do chladnějšího tieru neznamená, že je nemůžete smazat dřív. Ale zaplatíte za to. Většina cold a archivních tříd má minimální dobu uložení:
- S3 Standard-IA: 30 dní
- S3 Glacier Instant Retrieval: 90 dní
- S3 Glacier Deep Archive: 180 dní
- Azure Cool: 30 dní
- Azure Archive: 180 dní
- GCS Nearline: 30 dní
- GCS Coldline: 90 dní
- GCS Archive: 365 dní
Pokud data smažete nebo přesunete před uplynutím minimální doby, zaplatíte poměrnou část storage fee za celé období. U GCS Archive je to celý rok – to si fakt třeba dobře rozmyslet, než tam data pošlete.
5. Cross-region replikace
Pro disaster recovery a compliance často potřebujete replikovat data do jiného regionu. Jenže cross-region replikace přináší trojitý náklad: platíte za storage v obou regionech, za data transfer mezi nimi a za replikační API requesty. U velkých datasetů to může představovat desítky procent celkových storage nákladů navíc. Není to maličkost.
S3 Intelligent-Tiering: automatizovaná optimalizace, která ušetřila $6 miliard
Tak, a teď k tomu nejzajímavějšímu. AWS S3 Intelligent-Tiering je pravděpodobně ta nejdůležitější storage optimalizace posledních let. Od svého spuštění v roce 2018 zákazníkům ušetřil přes 6 miliard dolarů ve srovnání se standardním S3 úložištěm. A v roce 2026 je relevantnější než kdy dřív.
Jak to funguje
Intelligent-Tiering automaticky přesouvá objekty mezi úrovněmi přístupu na základě skutečných přístupových vzorců. Žádné hádání, žádné ruční nastavování pravidel:
- Frequent Access tier – stejná cena a výkon jako S3 Standard ($0,023/GB/měsíc)
- Infrequent Access tier – po 30 dnech bez přístupu, úspora 40 %
- Archive Instant Access tier – po 90 dnech bez přístupu, úspora 68 %
- Archive Access tier (volitelný) – po 90+ dnech, úspora až 71 %
- Deep Archive Access tier (volitelný) – po 180+ dnech, úspora až 95 %
Za monitoring a automatizaci platíte $0,0025 za 1 000 objektů měsíčně. Zní to jako drobnost, ale u bucketů s desítkami milionů malých souborů se to nasčítá. Dobrá zpráva: objekty menší než 128 KB nejsou monitorovány a zůstávají ve Frequent Access tieru – monitoring fee za ně neplatíte.
Kdy Intelligent-Tiering použít a kdy ne
Ideální scénáře:
- Data s nepředvídatelnými nebo měnícími se přístupovými vzorci
- Data lake s miliony souborů různého stáří
- User-generated content (dokumenty, média)
- Analytická data, kde nevíte, jak často budou dotazována
Kdy se to naopak nevyplatí:
- Buckety s miliony velmi malých objektů (pod 128 KB) – monitoring fee může převýšit úspory
- Data s konstantně vysokou frekvencí přístupu – všechno zůstane ve Frequent Access a navíc platíte monitoring fee zbytečně
- Krátkodobá data (pod 30 dní) – nestihnou se ani přesunout do levnějšího tieru
Reálné příklady úspor
Electronic Arts (EA) použil Intelligent-Tiering pro svůj data lake s měnícími se přístupovými vzorci a dosáhl 30% snížení nákladů na úložiště. AppsFlyer, zpracovávající 100 miliard událostí denně v petabytovém data lake, dosáhl úspory 18 % na GB pouhým přechodem na Intelligent-Tiering. A to jsou velcí hráči – u menších firem s méně optimalizovaným storage bývají úspory ještě výraznější.
Lifecycle politiky: proaktivní řízení životního cyklu dat
Zatímco Intelligent-Tiering pracuje automaticky, lifecycle politiky vám dávají plnou kontrolu nad tím, co se s daty stane a kdy. Pro data s předvídatelným životním cyklem jsou často efektivnější volbou – hlavně proto, že neplatíte monitoring fee.
Doporučená baseline lifecycle politika
Pro většinu workloadů funguje následující třístupňový přechod:
{
"Rules": [
{
"ID": "OptimizeStorageCosts",
"Status": "Enabled",
"Filter": {},
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
},
{
"Days": 90,
"StorageClass": "GLACIER_IR"
},
{
"Days": 365,
"StorageClass": "DEEP_ARCHIVE"
}
],
"NoncurrentVersionExpiration": {
"NoncurrentDays": 30
},
"AbortIncompleteMultipartUpload": {
"DaysAfterInitiation": 7
}
}
]
}Tenhle kousek JSONu dělá víc, než by se na první pohled zdálo:
- Po 30 dnech přesouvá data do Standard-IA – úspora 46 % na storage
- Po 90 dnech do Glacier Instant Retrieval – úspora 83 %
- Po roce do Deep Archive – úspora 96 %
- Staré verze souborů maže po 30 dnech
- Nekompletní multipart uploady čistí po 7 dnech
Organizace, které lifecycle politiky nastaví proaktivně, ušetří 25–40 % na S3 nákladech ve srovnání s těmi, které problém řeší zpětně po letech akumulace. Ten rozdíl je prostě obrovský.
Lifecycle politiky na Azure a GCP
Stejný princip platí i u ostatních poskytovatelů. Na Azure nastavíte pravidla přes Azure Blob Lifecycle Management:
az storage account management-policy create --account-name mystorageaccount --resource-group myresourcegroup --policy @policy.jsonNa Google Cloud Storage použijete gsutil lifecycle:
gsutil lifecycle set lifecycle-config.json gs://my-bucket/Klíčové je, aby pravidla odpovídala skutečným retenčním požadavkům a minimální době uložení u jednotlivých tříd. Jinak zaplatíte early deletion charges – a to fakt nechcete.
Intelligent-Tiering vs. Lifecycle politiky: kdy co použít
Tahle otázka se objevuje pořád dokola a odpověď (překvapivě) není jednoznačná. Záleží na vašem konkrétním scénáři.
| Kritérium | S3 Intelligent-Tiering | Lifecycle politiky |
|---|---|---|
| Přístupové vzorce | Nepředvídatelné, měnící se | Předvídatelné, známé |
| Poplatky navíc | $0,0025 / 1 000 objektů (monitoring) | $0,01 / 1 000 objektů (přesun) |
| Retrieval fees | Žádné (ve hlavních tierech) | Ano (u IA, Glacier tříd) |
| Operační režie | Minimální – automatizováno | Vyšší – nutno definovat pravidla |
| Riziko chyby | Nízké | Střední (špatně nastavená pravidla) |
| Ideální pro | Data lake, UGC, analytika | Logy, zálohy, archivní data |
Mimochodem: Obě strategie jde kombinovat. Můžete nastavit lifecycle pravidlo, které nová data nejdřív přesune do S3 Intelligent-Tiering, a ten se pak postará o další optimalizaci přístupových vzorců. První měsíc bude mírně dražší kvůli jednorázovému přesunu, ale od druhého měsíce začnete vidět úspory. V praxi tohle používám jako výchozí strategii pro buckety, kde si nejsem jistý přístupovými vzorci.
Praktický návod: audit storage nákladů krok za krokem
Teorie je fajn, ale pojďme na to prakticky. Tady je postup, jak provést audit svých storage nákladů a najít největší příležitosti k úsporám.
Krok 1: Zmapujte aktuální stav
Na AWS použijte S3 Storage Lens – bezplatný dashboard, který vám ukáže rozložení dat napříč storage třídami, buckety a regiony:
aws s3control put-storage-lens-configuration --account-id 123456789012 --config-id my-storage-lens --storage-lens-configuration file://storage-lens-config.jsonNa Azure využijte Azure Storage Explorer a Azure Cost Management, na GCP pak Cloud Monitoring s metrikami pro Cloud Storage. Cíl je jednoduchý – získat přehled o tom, co máte, kde to máte a kolik vás to stojí.
Krok 2: Identifikujte „zombie" data
Hledejte tyto typické zdroje plýtvání:
- Staré verze souborů – buckety s versioningem bez expiration policy
- Nekompletní multipart uploady – seznam získáte jednoduše (viz níže)
- Nepoužívané snapshoty a zálohy – starší než retence politika vyžaduje
- Duplikáty dat – stejná data v různých bucketech nebo regionech
- Dev/test data v produkčních tierech – testovací datasety uložené v S3 Standard, i když se k nim nikdo měsíce nedotkl
# Seznam nekompletních multipart uploadů starších než 2026-01-01
aws s3api list-multipart-uploads --bucket my-bucket --query "Uploads[?Initiated<='2026-01-01']"
# Analýza non-current verzí
aws s3api list-object-versions --bucket my-bucket --query "Versions[?IsLatest==\`false\`]" --output jsonKrok 3: Nastavte lifecycle politiky a tagging
Pro každý bucket si odpovězte na čtyři otázky:
- Jaký typ dat obsahuje (logy, zálohy, user data, analytika)?
- Jak dlouho musí být data snadno dostupná?
- Jaká je minimální retence z compliance důvodů?
- Jsou přístupové vzorce předvídatelné (→ lifecycle) nebo ne (→ Intelligent-Tiering)?
Tagování bucketů je naprosto klíčové pro sledování nákladů. Bez tagů nevíte, kdo za co platí. Doporučené tagy:
aws s3api put-bucket-tagging --bucket my-bucket --tagging '{
"TagSet": [
{"Key": "Environment", "Value": "production"},
{"Key": "DataType", "Value": "logs"},
{"Key": "CostCenter", "Value": "engineering-ops"},
{"Key": "RetentionDays", "Value": "90"},
{"Key": "Owner", "Value": "platform-team"}
]
}'Krok 4: Optimalizujte egress náklady
Egress fees mohou tvořit větší část faktury než samotné úložiště. Klíčové strategie:
- Používejte CDN – CloudFront, Azure CDN nebo Cloud CDN cachují data blíže uživatelům a snižují opakovaný egress z origin storage
- Držte compute a storage ve stejném regionu – cross-region přenos je zbytečně drahý (a přitom se tomu dá snadno vyhnout)
- Komprimujte data před přenosem – gzip nebo zstd komprese může snížit objem přenášených dat o 60–80 %
- Zvažte alternativní poskytovatele pro vysoký egress – služby jako Backblaze B2 nebo Cloudflare R2 nabízejí nulové nebo minimální egress fees
Automatizace: infrastructure as code pro storage optimalizaci
Ruční správa lifecycle politik a storage konfigurací napříč desítkami bucketů a účtů je neudržitelná. Dříve nebo později na něco zapomenete. Proto je klíčové celou strategii definovat jako kód.
Terraform modul pro optimalizovaný S3 bucket
resource "aws_s3_bucket" "optimized" {
bucket = "my-optimized-bucket"
}
resource "aws_s3_bucket_intelligent_tiering_configuration" "tiering" {
bucket = aws_s3_bucket.optimized.id
name = "FullOptimization"
tiering {
access_tier = "ARCHIVE_ACCESS"
days = 90
}
tiering {
access_tier = "DEEP_ARCHIVE_ACCESS"
days = 180
}
}
resource "aws_s3_bucket_lifecycle_configuration" "lifecycle" {
bucket = aws_s3_bucket.optimized.id
rule {
id = "cleanup-old-versions"
status = "Enabled"
noncurrent_version_expiration {
noncurrent_days = 30
}
abort_incomplete_multipart_upload {
days_after_initiation = 7
}
}
}
resource "aws_s3_bucket_versioning" "versioning" {
bucket = aws_s3_bucket.optimized.id
versioning_configuration {
status = "Enabled"
}
}Tímhle způsobem máte storage optimalizaci definovanou jako kód, verzovanou v Gitu a snadno replikovatelnou napříč prostředími. Žádná ruční klikání v konzoli, žádné zapomenuté buckety bez lifecycle pravidel. A hlavně – nový člen týmu vidí v kódu přesně, jaká je vaše storage strategie.
Azure a GCP: specifické optimalizační nástroje
Azure Blob Storage – Access Tier Management
Azure má jednu zajímavou výhodu – možnost nastavit access tier na úrovni jednotlivého blobu, nejen celého kontejneru. To umožňuje granulární optimalizaci, kde různé soubory ve stejném kontejneru mají různé tiery.
# Změna tieru jednotlivého blobu
az storage blob set-tier --account-name mystorageaccount --container-name mycontainer --name myblob.dat --tier Cool
# Hromadná změna tieru pro staré bloby
az storage blob list --account-name mystorageaccount --container-name mycontainer --query "[?properties.lastModified<='2025-12-01'].name" --output tsv | while read blob; do
az storage blob set-tier --account-name mystorageaccount --container-name mycontainer --name "$blob" --tier Archive
doneAzure Blob Storage taky nabízí volume discounts – čím víc dat máte, tím nižší cena za GB. To je fajn výhoda oproti AWS, kde taková objemová sleva u standardního S3 neexistuje.
Google Cloud Storage – Autoclass
Google Cloud má funkci Autoclass, což je v podstatě obdoba AWS Intelligent-Tiering. Automaticky přesouvá objekty mezi Standard, Nearline, Coldline a Archive třídami podle přístupových vzorců. Na rozdíl od Intelligent-Tiering neúčtuje monitoring fee za objekt – místo toho platíte management fee za bucket, což může být u bucketů s hodně objekty výrazně levnější.
Další příjemná věc na GCS je jednotný API napříč všemi storage třídami – nepotřebujete zvláštní retrieval requesty jako u S3 Glacier. Přístup k datům v Coldline nebo Archive třídě probíhá úplně stejně jako ke Standard datům, jen zaplatíte retrieval fee.
Checklist: 10 rychlých výher pro snížení storage nákladů
Na závěr praktické části – tady je seznam akcí, které můžete provést hned a vidět úspory na příští faktuře. Některé z nich zaberou doslova pár minut:
- Zapněte AbortIncompleteMultipartUpload na všech bucketech – 7 dní je rozumné výchozí nastavení
- Nastavte NoncurrentVersionExpiration – 30 dní pro většinu workloadů, 90 dní pro compliance
- Aktivujte S3 Intelligent-Tiering pro buckety s nepředvídatelnými přístupovými vzorci
- Nastavte lifecycle politiky pro buckety s předvídatelnými vzorci (logy → IA po 30 dnech → Glacier po 90 dnech)
- Zkontrolujte egress – držte compute ve stejném regionu jako storage
- Zapněte kompresi – gzip pro textová data, zstd pro strukturovaná data
- Tagujte buckety – minimálně Environment, Owner, CostCenter, DataType
- Odstraňte duplikáty – stejná data v různých regionech nebo účtech
- Přesuňte dev/test data z hot tieru do levnější třídy
- Nastavte budget alerty – 80 % a 100 % prahu pro storage náklady
Často kladené otázky (FAQ)
Jaký je rozdíl mezi S3 Intelligent-Tiering a lifecycle politikami?
S3 Intelligent-Tiering automaticky přesouvá objekty mezi tiery na základě skutečných přístupových vzorců – za monitoring fee $0,0025 / 1 000 objektů. Lifecycle politiky vyžadují ruční definici pravidel (např. „po 30 dnech přesuň do IA"), ale neplatíte monitoring fee. Intelligent-Tiering je ideální pro data s nepředvídatelnými vzorci, lifecycle politiky pro data s jasným životním cyklem. A jak jsem zmínil výše – obě strategie jde kombinovat.
Kolik lze reálně ušetřit optimalizací cloudového úložiště?
Záleží na výchozím stavu, ale typicky organizace ušetří 40–80 % na storage nákladech. Samotný přechod ze S3 Standard na Standard-IA přinese 46% úsporu, přechod na Glacier Instant Retrieval 83 %. Přidejte k tomu vyčištění starých verzí, nekompletních uploadů a duplikátů a úspory se rychle nasčítají.
Jsou egress fees u všech cloudových poskytovatelů stejné?
Ne, a liší se docela výrazně. AWS účtuje $0,09/GB, Azure $0,087/GB a Google Cloud $0,12/GB za prvních 10 TB. Pro workloady s vysokým egress existují alternativy jako Cloudflare R2 nebo Backblaze B2 s nulovými nebo minimálními egress fees. Google Cloud a AWS nabízejí zrušení egress fees při trvalém odchodu od poskytovatele, ale u běžného provozu fees platí.
Vyplatí se S3 Intelligent-Tiering pro malé soubory?
Záleží na velikosti. Objekty menší než 128 KB nejsou automaticky tierovány a zůstávají v nejdražším Frequent Access tieru (za monitoring fee se ale neúčtují). Pro buckety s převážně malými soubory pod 128 KB nemá Intelligent-Tiering moc smysl – lepší je použít lifecycle politiky nebo zvážit, jestli malé soubory nelze agregovat do větších archivů.
Jak předejít neočekávaně vysoké faktuře za cloudové úložiště?
Nastavte si budget alerty v AWS Budgets, Azure Cost Management nebo GCP Billing Alerts na 80 % a 100 % očekávaného rozpočtu. Používejte S3 Storage Lens nebo ekvivalentní nástroje pro průběžný monitoring. Tagujte buckety pro přiřazení nákladů k týmům. A hlavně – nastavte lifecycle politiky a AbortIncompleteMultipartUpload pravidla hned při vytvoření bucketu, ne až po roce, kdy se problémy nakupí. To je ta nejlepší prevence.