FinOps v roce 2026: kde firmy v cloudu nejvíc přeplácejí a jak to změřit za týden

Co říkají čísla za rok 2026

Dva nejcitovanější průzkumy oboru letos vyznívají podobně: disciplína dospívá, ale plýtvání nemizí.

Flexera 2026 State of the Cloud Report vychází z odpovědí 753 technických odborníků a manažerů z celého světa. Respondenti odhadují, že 29 % výdajů za IaaS a PaaS je vyhozených, a je to první nárůst po pěti letech poklesu. Řízení nákladů označilo za prioritu číslo jedna 85 % dotázaných. FinOps tým má přitom už 63 % organizací.

State of FinOps 2026 od FinOps Foundation (1 192 respondentů, firmy s ročními výdaji za cloud přes 83 miliard dolarů) ukazuje, kam se obor posouvá. Výdaje za AI dnes řídí 98 % dotázaných týmů, před dvěma lety to bylo 31 %. Podle tiskové zprávy z 19. února 2026 spadá 78 % FinOps týmů pod CTO nebo CIO, tedy do technologie, ne do financí.

Pro praxi je nejdůležitější jedna věta reportu: optimalizace workloadů a omezování plýtvání zůstává nejvyšší současnou prioritou, zatímco FinOps pro AI je nejvyšší prioritou do budoucna. Jinými slovy – ani firmy s vyspělým FinOps nemají základy hotové.

Pět míst, kde se přeplácí nejčastěji

1. Předimenzované Kubernetes clustery

Cast AI ve zprávě 2026 State of Kubernetes Resource Optimization (duben 2026) uvádí průměrné využití CPU 8 % a paměti 20 %; rok předtím to bylo 10 % a 23 %. Data pocházejí z desítek tisíc produkčních clusterů na AWS, GCP a Azure změřených před jakoukoli optimalizací. Je to tedy vzorek clusterů, jejichž provozovatelé si optimalizační nástroj teprve pořizovali – a dodavatel má na dramatickém čísle zájem. Řádově ale stejný obraz dává starší nezávislejší pohled: Datadog State of Cloud Costs (červen 2024) spočítal na datech z AWS, že 83 % výdajů za kontejnery připadá na nevyužité zdroje, z toho 54 % na předimenzovanou infrastrukturu clusteru a 29 % na zbytečně vysoké requests workloadů.

Příčina je strukturální. Requests nastavuje vývojář „pro jistotu“, nikdo je nereviduje a node pool se škáluje podle requests, ne podle skutečné spotřeby.

2. Zdroje, které nikdo nepoužívá

Odpojené disky, staré snapshoty, load balancery bez backendů, nepřiřazené veřejné IP adresy, zastavené virtuální stroje s připojeným prémiovým diskem, zapomenutá testovací prostředí. Jednotlivě drobnosti, dohromady položka, která roste s každým projektem a sama nikdy neklesne.

3. Neprodukční prostředí běžící nonstop

Týden má 168 hodin. Vývojové a testovací prostředí, které se používá v pracovní dny deset hodin denně, je aktivní 50 hodin, tedy zhruba 30 % času. Zbylých 70 % hodin platíte za výkon, na který nikdo nesahá. U prostředí, která nejdou vypnout celá, obvykle jde aspoň škálovat node pooly a databáze na minimum.

4. Platba plných on-demand cen za stabilní zátěž

Závazkové slevy jsou nejjednodušší páka bez zásahu do architektury. AWS v dokumentaci Savings Plans uvádí úsporu až 72 % výměnou za závazek na jeden nebo tři roky vyjádřený v dolarech za hodinu. Přesto podle zmíněné analýzy Datadogu používalo závazkové slevy jen 67 % organizací a pouze 29 % jimi pokrývalo víc než polovinu způsobilých výdajů. Čísla jsou z roku 2024 a týkají se AWS, ale vzorec je stále platný: firmy se závazku bojí víc, než je racionální.

5. Přenosy dat a zastaralé typy zdrojů

Tatáž analýza Datadogu zjistila, že téměř polovinu nákladů na přenos dat v AWS tvoří provoz mezi zónami dostupnosti a platí ho 98 % organizací. Na instance předchozí generace šlo zhruba 17 % výdajů za EC2 a 58 % výdajů za EBS připadalo na starší disky gp2. Jde o položky, které se ve faktuře schovávají pod obecné řádky a bez rozpadu podle typu využití je nikdo neuvidí.

Bez alokace se nedá řídit nic

Všechna předchozí místa mají společného jmenovatele: někdo musí vědět, čí ten náklad je. Faktura rozdělená podle služeb („EC2“, „Storage“) odpověď nedá. Potřebujete rozpad podle týmu, produktu a prostředí.

Minimální sada tagů, která stačí na začátek: owner (tým), service (aplikace nebo produkt), env (prod, test, dev) a cost-center. Důležitější než jejich počet je vynucení. Tagy patří do Terraform modulů jako povinné proměnné a do policy (AWS Organizations tag policies, Azure Policy), ne do wiki. Jak stavět moduly tak, aby se pravidla nedala obejít, rozebírá článek o návrhu Terraform modulů.

V Kubernetes tagy cloudových zdrojů nestačí, protože jeden node sdílí desítky workloadů. Tady pomáhá OpenCost, vendor-neutrální open source projekt pro měření a alokaci nákladů na infrastrukturu a kontejnery, který je od 25. října 2024 inkubačním projektem CNCF. Rozpočítá cenu nodů na namespace, deployment nebo label.

FOCUS: jeden formát pro všechny faktury

Firmy s více cloudy narážejí na to, že každý poskytovatel exportuje vyúčtování v jiné struktuře. Řeší to otevřená specifikace FOCUS (FinOps Open Cost and Usage Specification), jejíž aktuální verze 1.4 vyšla 4. června 2026. Podle changelogu přidala mimo jiné datové sady pro rekonciliaci faktur; verze 1.3 z prosince 2025 přinesla smluvní závazky a alokaci sdílených nákladů.

Poskytovatelé jsou o krok pozadu: AWS Data Exports nabízí tabulku FOCUS 1.2 with AWS columns, Microsoft Cost Management uvádí jako nejnovější verzi 1.2-preview. Pro týdenní audit to nevadí. Pokud ale stavíte vlastní reporting, zapněte export ve formátu FOCUS hned – historická data zpětně nedostanete tak snadno a podle State of FinOps už 68 % organizací s výdaji nad 100 milionů dolarů FOCUS používá nebo s ním experimentuje.

Týdenní audit: pět dní, žádný nový nástroj

Cílem není uspořit, ale změřit: na konci týdne máte mít seznam nálezů s odhadem v korunách a jménem vlastníka. Stačí nativní nástroje poskytovatele a jeden člověk s přístupem pro čtení k billingu a k účtům.

Ukázka: první tři dotazy

Náklady podle tagu, odpojené disky v AWS a v Azure a porovnání requests se spotřebou v clusteru:

# AWS: náklady za září 2026 podle tagu "owner"
aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=TAG,Key=owner

# AWS: disky, které nejsou připojené k žádné instanci
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' --output table

# Azure: nepřipojené managed disky
az disk list --query "[?diskState=='Unattached'].[name,diskSizeGb,resourceGroup]" -o table

# Kubernetes: skutečná spotřeba vs. nastavené requests
kubectl top pods -A --sort-by=cpu
kubectl get pods -A -o custom-columns=\
'NS:.metadata.namespace,POD:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory'

Prázdný řádek u tagu owner v prvním dotazu je nejdůležitější číslo celého pondělí. kubectl top ukazuje okamžitý stav; pro rozhodnutí o requests použijte percentily za několik týdnů z Promethea nebo z OpenCost.

Co udělat s výsledky a v jakém pořadí

Jednorázový úklid vydrží několik měsíců. Aby úspora nezmizela, potřebujete tři trvalé věci: povinné tagy vynucené v pipeline, rozpočty s alerty na úrovni týmu a měsíční patnáctiminutovou revizi největších změn. State of FinOps tomu říká „shift left“ – cenu řešit už při návrhu a v pull requestu, ne až na faktuře. Report zároveň přiznává otevřený problém: úspora, která se odstraní předem, není nikde vidět, a vývojářům se za ni těžko přiznává zásluha.

Kde infrastruktura vzniká ručně a bez standardů, alokace nebude fungovat nikdy; souvislosti popisuje článek o chaosu v infrastruktuře před nasazením AI.

Kdy se optimalizace nevyplatí

FinOps má i svou cenu a některá doporučení neplatí vždy.

• Malý účet. Pokud je měsíční faktura v řádu desítek tisíc korun, týden práce seniorního inženýra stojí víc než roční úspora. Stačí smazat zjevné zbytky a nastavit rozpočtový alert.
• Rezerva není plýtvání. Volná kapacita pro špičky, failover do druhé zóny a rezerva na rolling update jsou cena za dostupnost. Využití CPU 8 % je špatně; cíl 90 % je špatně také. Rozumný cíl určuje profil zátěže a SLO, ne benchmark.
• Provoz mezi zónami. Stažení služby do jedné zóny ušetří přenosy, ale zhorší odolnost. Řešením je spíš směrování s ohledem na topologii než rezignace na multi-AZ.
• Závazek před změnou. Chystáte-li migraci, přechod na jinou architekturu procesorů nebo výrazné přeškálování, tříletý závazek na konkrétní rodinu instancí je sázka proti vlastnímu plánu.
• Rychle rostoucí produkt. Když je úzkým hrdlem rychlost dodávky, hodina vývojáře věnovaná ladění requests může být dražší než přeplacený node. Rozhoduje jednotková ekonomika, ne absolutní výše faktury.

A co náklady na AI

Skok z 31 % na 98 % týmů, které řídí výdaje za AI, ukazuje, že se z okrajového tématu stal standard během dvou let. State of FinOps zároveň uvádí řízení nákladů na AI jako dovednost číslo jedna, kterou týmy potřebují doplnit. Cast AI ve své letošní zprávě poprvé měřil i GPU a uvádí průměrné využití 5 % – se stejnou výhradou ke vzorku jako u CPU.

Pro týdenní audit z toho plyne jediné: zařaďte AI služby a GPU node pooly do stejného rozpadu jako ostatní náklady. Stejné tagy, stejní vlastníci, stejné rozpočty. Samostatná „AI faktura“ mimo alokaci je přesně ten typ slepé skvrny, kvůli které odhad plýtvání letos poprvé po letech vzrostl.

Klíčové poznatky

• Plýtvání znovu roste. Flexera 2026 uvádí odhad 29 % vyhozených výdajů za IaaS/PaaS, první nárůst po pěti letech, přestože FinOps tým má 63 % organizací.
• Základy nejsou hotové ani u vyspělých. Optimalizace workloadů a omezování plýtvání je podle State of FinOps 2026 stále nejvyšší aktuální prioritou.
• Největší rezerva bývá v Kubernetes. Dodavatelská i nezávislejší data ukazují na nízké využití requests; změřte si vlastní clustery, než čísla převezmete.
• Nejdřív alokace, potom úspory. Bez povinných tagů a vlastníka se žádný nález nepromění v akci.
• Pořadí rozhoduje. Smazat, vypínat, zmenšit, a teprve potom se zavázat.
• Audit jde zvládnout za týden nativními nástroji. Výstupem je backlog s cenou a jménem, ne prezentace.
• Rezerva pro dostupnost není plýtvání. Cílové využití určuje SLO, ne průměr z průzkumu.