Serverless náklady v roce 2026: Skryté pasti AWS Lambda, Azure Functions a GCP (a jak ušetřit 20–40 %)

Úvod: Proč „platíte jen za to, co využijete" není celá pravda

Serverless architektura zní na papíře skvěle – spustíte kód, zaplatíte za dobu běhu a počet volání, žádné servery. Hotovo. Jenže pak přijde první faktura a vy si říkáte, kde se to vzalo. Podle dat z roku 2026 může reálná cena serverless běhu dosáhnout až 5,5násobku skutečného výpočetního času. Zaokrouhlování, skryté poplatky za přidružené služby, špatně nastavené funkce – to všechno se sčítá.

A nejste v tom sami. Serverless adopce v roce 2026 prudce roste a podle State of FinOps 2026 je řízení těchto nákladů jednou z nejžádanějších dovedností FinOps týmů. Tradiční nástroje pro správu cloudových nákladů přitom serverless výdaje často zachytí jen částečně, protože jsou rozházené napříč desítkami mikroslužeb a přidružených zdrojů.

Tak pojďme na to. V tomto průvodci si rozebereme, jak skutečně funguje cenotvorba serverless služeb u AWS, Azure a GCP, odkryjeme ty náklady, co většina týmů přehlíží, a ukážeme konkrétní postupy a nástroje, jak serverless výdaje snížit o 20–40 %.

Jak funguje cenotvorba serverless služeb

Než se pustíme do optimalizace, je potřeba rozumět tomu, za co přesně platíte. Všichni tři velcí poskytovatelé – AWS Lambda, Azure Functions a Google Cloud Functions – používají model založený na třech hlavních faktorech:

• Počet volání (invocations) – kolikrát se funkce spustí
• Doba běhu (duration) – jak dlouho funkce běží, měřeno v GB-sekundách
• Přidělená paměť – kolik RAM funkce dostane (CPU se přiděluje proporcionálně)

Zatím jednoduché, že? Ale ďábel je v detailech.

Srovnání cen v roce 2026

Tady je přehled klíčových cenových parametrů všech tří platforem:

Parametr	AWS Lambda (x86)	Azure Functions (Consumption)	Google Cloud Functions
Cena za 1M volání	$0,20	$0,20	$0,40
Cena za GB-sekundu	$0,0000166667	$0,000016	$0,0000025 + $0,00001/GHz-s
Free tier – volání/měsíc	1 milion	1 milion	2 miliony
Free tier – GB-sekundy/měsíc	400 000	400 000	400 000
ARM/Graviton varianta	Ano (20 % levnější)	Ne	Ne
Minimální účtování	1 ms	100 ms	100 ms

Důležitý detail: AWS Lambda účtuje po milisekundách, zatímco Azure a Google Cloud Functions zaokrouhlují na nejbližších 100 ms. U funkcí s hodně krátkým během (řekněme pod 50 ms) tak může AWS vyjít výrazně levněji. Tohle je věc, kterou spousta lidí při výběru platformy přehlédne.

5 skrytých nákladů serverless, které většina týmů přehlíží

1. Zaokrouhlování doby běhu

Zní to jako drobnost, ale není. Funkce, která běží 280 ms, se u Azure a GCP vyúčtuje jako 300 ms. Při milionech volání měsíčně se ten rozdíl nastřádá na stovky až tisíce dolarů ročně.

AWS Lambda od roku 2020 účtuje po jednotlivých milisekundách, takže tenhle problém je tam méně výrazný. Ale pozor – i u AWS existuje minimální účtování 1 ms a paměť se zaokrouhluje na nejbližších 1 MB.

2. API Gateway – 35× dražší než ALB

Většina serverless aplikací přijímá HTTP requesty přes API Gateway. A tady přichází nepříjemné překvapení:

• AWS API Gateway: $3,50 za milion requestů
• AWS Application Load Balancer: $0,10 za milion requestů

To je 35násobný cenový rozdíl. Pokud vaše aplikace zpracovává 100 milionů requestů měsíčně, API Gateway vás stojí $350/měsíc jen za routing, zatímco ALB by stál $10. Samozřejmě – API Gateway nabízí autorizaci, rate limiting a transformace, které ALB nemá. Ale pokud tyhle věci reálně nevyužíváte, zbytečně přeplácíte.

Upřímně, tohle je jedna z prvních věcí, na které se vyplatí se podívat při auditu serverless nákladů.

3. CloudWatch logy – tichý žrout rozpočtu

Každá serverless funkce ve výchozím nastavení loguje do CloudWatch (AWS), Application Insights (Azure) nebo Cloud Logging (GCP). A problém? Výchozí retence je často neomezená. Náklady na ingestion i storage se tiše hromadí měsíc za měsícem, aniž by si toho kdokoli všiml.

Konkrétní čísla pro AWS CloudWatch:

• Ingestion: $0,50 za GB logů
• Storage: $0,03 za GB/měsíc

Funkce zpracovávající 10 milionů requestů denně s průměrným logem 1 KB na volání generuje zhruba 300 GB logů měsíčně. To je $150/měsíc za ingestion + $9/měsíc za storage – a roste to každý měsíc, protože staré logy se prostě nemažou. Osobně jsem viděl projekty, kde logy stály víc než samotný compute.

4. Data transfer a cross-region komunikace

Odchozí datový přenos (egress) je zpoplatněn nezávisle na serverless ceníku a tady se to může pěkně prodražit:

• AWS: $0,09/GB (internet), $0,01/GB (cross-region)
• Azure: $0,087/GB (internet)
• GCP: $0,12/GB (internet)

Serverless funkce, která volá externí API nebo vrací větší odpovědi klientům, může snadno generovat terabajty egress dat měsíčně. A tyto náklady často zmizí v obecné kategorii „networking" na faktuře, kde je nikdo nesleduje. Klasická past.

5. Provisioned Concurrency a Premium plány

Cold starty jsou prokletím serverless. Pomalé první spuštění funkce může trvat od stovek milisekund po desítky sekund (Azure Functions Consumption plán je v tomhle obzvlášť pomalý). Řešením je Provisioned Concurrency (AWS) nebo Premium plán (Azure), jenže tyto funkce přinášejí stálé náklady i v době nečinnosti.

AWS Lambda Provisioned Concurrency stojí $0,0000041667 za GB-sekundu – asi čtvrtina ceny on-demand, ale platíte ji 24/7 bez ohledu na to, jestli funkci někdo volá. Špatně nastavená Provisioned Concurrency může klidně stát víc než samotné on-demand volání. To je přesně ten typ nákladu, který vás tiše žere.

Praktické strategie pro snížení serverless nákladů

Strategie 1: Right-sizing paměti pomocí Lambda Power Tuning

Tohle je pravděpodobně ta nejefektivnější optimalizace, kterou můžete udělat. AWS Lambda Power Tuning je open-source nástroj založený na Step Functions, který vaši funkci spustí s různými konfiguracemi paměti a najde optimální poměr cena/výkon.

Proč je to tak důležité? U Lambda roste CPU výkon proporcionálně s přidělenou pamětí. Funkce se 128 MB RAM dostane zlomek CPU oproti funkci s 1024 MB. Výsledek bývá paradoxní: funkce s méně pamětí běží déle a může stát víc než funkce s více pamětí.

Instalace a použití:

# Nasazení Lambda Power Tuning přes AWS SAR
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM

# Po nasazení spusťte Step Function s parametry:
# Input pro Step Functions state machine
{
  "lambdaARN": "arn:aws:lambda:eu-central-1:123456789:function:moje-funkce",
  "powerValues": [128, 256, 512, 1024, 2048, 3008],
  "num": 50,
  "payload": "{"key": "test-event"}",
  "parallelInvocation": true
}

Nástroj vygeneruje graf závislosti ceny a doby běhu na velikosti paměti. V praxi se často ukazuje, že zvýšení paměti 4–8× sníží celkové náklady o 30–40 %, protože funkce doběhne několikanásobně rychleji. Zní to neintuitivně, ale funguje to.

Strategie 2: Přechod na ARM/Graviton2 (AWS)

AWS Lambda na procesorech Graviton2 (ARM64) stojí o 20 % méně za GB-sekundu než x86 varianta a nabízí až 19 % lepší výkon. Úspora bez jakéhokoli kompromisu – u většiny workloadů.

# Změna architektury existující funkce na ARM64
aws lambda update-function-configuration \
  --function-name moje-funkce \
  --architectures arm64

# Ověření konfigurace
aws lambda get-function-configuration \
  --function-name moje-funkce \
  --query "Architectures"

Pozor: Pokud vaše funkce používá nativní binární závislosti (kompilované C/C++ knihovny), musíte zajistit, aby byly zkompilovány pro ARM64. Čistě interpretované jazyky jako Python, Node.js nebo Java fungují na ARM bez úprav.

Strategie 3: Filtrování zbytečných volání u zdroje

Zbytečná volání jsou jedním z nejtišších zdrojů plýtvání. Každé volání stojí peníze – a pokud funkce zpracovává události, které vůbec nepotřebuje, platíte za nic. Doslova.

# Příklad: SQS event filtering – funkce se spustí jen pro objednávky
# nad 1000 Kč, místo zpracování všech zpráv
aws lambda create-event-source-mapping \
  --function-name zpracuj-objednavku \
  --event-source-arn arn:aws:sqs:eu-central-1:123456789:objednavky \
  --filter-criteria '{
    "Filters": [
      {
        "Pattern": "{"body": {"castka": [{"numeric": [">=", 1000]}]}}"
      }
    ]
  }'

U Azure Functions můžete filtrovat pomocí Event Grid subscription filtrů, u Google Cloud Functions přes Eventarc filtry. Princip je všude stejný – odfiltrujte nevhodné události dřív, než dorazí k funkci.

Strategie 4: Optimalizace logování

Snížení nákladů na logy je rychlá výhra. A přitom to většina týmů řeší až když je pozdě. Tady jsou konkrétní kroky:

# AWS: Nastavení retence CloudWatch log group na 30 dní
aws logs put-retention-policy \
  --log-group-name /aws/lambda/moje-funkce \
  --retention-in-days 30

# Hromadné nastavení retence pro všechny Lambda log groups
for lg in $(aws logs describe-log-groups \
  --log-group-name-prefix /aws/lambda/ \
  --query "logGroups[?retentionInDays==null].logGroupName" \
  --output text); do
  aws logs put-retention-policy \
    --log-group-name "$lg" \
    --retention-in-days 30
  echo "Nastavena retence 30 dní pro: $lg"
done

Další tipy pro logování:

• V produkci logujte na úrovni WARN nebo ERROR, ne DEBUG (to zní samozřejmě, ale bylo by překvapivé, kolik produkčních funkcí má zapnutý DEBUG)
• Používejte strukturované logy (JSON) – efektivněji se parsují a dají se filtrovat bez nutnosti ukládat úplně všechno
• Zvažte sampling – logujte třeba jen každý desátý request v plném detailu
• Pro dlouhodobou archivaci exportujte logy do S3 ($0,023/GB/měsíc vs. $0,03/GB/měsíc v CloudWatch)

Strategie 5: Chytré využití Provisioned Concurrency

Provisioned Concurrency eliminuje cold starty, ale jen pokud ji používáte správně. Klíčem je nastavit ji selektivně a dynamicky – ne plošně pro všechno:

# Nastavení Application Auto Scaling pro Provisioned Concurrency
# Funkce automaticky škáluje PC podle poptávky
aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --resource-id function:moje-api:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --min-capacity 5 \
  --max-capacity 100

# Target tracking – udržuje 70% využití PC
aws application-autoscaling put-scaling-policy \
  --service-namespace lambda \
  --resource-id function:moje-api:prod \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --policy-name pc-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 0.7,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization"
    }
  }'

Alternativně můžete PC nastavit pouze pro konkrétní hodiny pomocí plánovaného škálování – třeba 8:00–20:00 v pracovních dnech, kdy je reálný provoz. Přes noc a o víkendu ať klidně cold starty proběhnou.

Strategie 6: Compute Savings Plans pro Lambda

Málokdo ví, že AWS Compute Savings Plans se vztahují i na Lambda. S jednoletým nebo tříletým závazkem můžete ušetřit až 17 % na Lambda výpočetním čase.

Jasně, 17 % zní méně dramaticky než u EC2. Ale u vysokoobjemových serverless aplikací to znamená stovky až tisíce dolarů ročně. A navíc – Savings Plans se automaticky aplikují na Lambda po aktivaci, takže není potřeba žádná změna kódu ani konfigurace. Prostě to zapnete a šetříte.

Kdy je serverless dražší než kontejnery

Serverless není vždycky nejlevnější volba. A to je v pořádku. Existuje docela jasný bod zvratu, kde kontejnery (ECS, AKS, GKE) nebo i klasické VM vychází ekonomicky výhodněji:

• Konzistentní, vysoký provoz: Pokud funkce běží nepřetržitě s utilizací nad 60 %, kontejnery na Reserved Instances vychází levněji
• Dlouhotrvající procesy: Lambda má limit 15 minut, Azure Functions Consumption 10 minut. Pro batch joby trvající déle jsou kontejnery prostě lepší volba
• Vysoký objem dat: Funkce zpracovávající velké datové objemy generují vysoké egress a I/O náklady, které kontejnery obejdou efektivněji

Hrubé pravidlo: Pokud vaše funkce zpracovává víc než 1 milion requestů denně se stabilním provozem, proveďte analýzu nákladů serverless vs. kontejnery. Pod 100 000 requestů denně je serverless téměř vždy ekonomicky výhodnější.

Monitoring a nástroje pro serverless FinOps

Bez viditelnosti nemůžete optimalizovat – tohle platí dvojnásob u serverless, kde se náklady rozpadají do stovek drobných položek. Tady jsou nástroje, které v roce 2026 fungují nejlépe:

Nativní nástroje

• AWS Cost Explorer – seskupení nákladů podle funkce (Group by → Resource) odhalí, které funkce jsou nejdražší
• Azure Cost Management – filtrování podle resource type = Microsoft.Web/sites pro přehled nákladů Azure Functions
• GCP Billing Reports – filtrování podle SKU pro Cloud Functions a Cloud Run

Third-party nástroje

• Datadog Serverless Monitoring – end-to-end viditelnost s cost estimation na úrovni jednotlivých invokací
• Lumigo – automatická detekce problémů s výkonem a náklady v serverless architekturách
• Sedai – autonomní optimalizace paměti a concurrency pomocí ML modelů (tohle je celkem zajímavý přístup, pokud nechcete ladění dělat ručně)

Klíčové metriky, které byste měli sledovat:

# AWS CLI: Zjištění top 10 nejdražších Lambda funkcí za poslední měsíc
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=RESOURCE_ID \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["AWS Lambda"]
    }
  }' \
  --query "ResultsByTime[0].Groups | sort_by(@, &Metrics.UnblendedCost.Amount) | [-10:]"

Kontrolní seznam pro serverless optimalizaci

Tenhle seznam si klidně uložte – hodí se jako výchozí bod při auditu serverless nákladů:

1. Spusťte Lambda Power Tuning na všech produkčních funkcích
2. Přepněte na ARM/Graviton2 tam, kde je to možné
3. Nastavte retenci CloudWatch logů na 14–30 dní
4. Ověřte, jestli nepotřebujete API Gateway a ALB by nestačil
5. Implementujte event filtering u SQS, DynamoDB Streams, EventBridge
6. Auditujte Provisioned Concurrency – platíte za to, co nevyužíváte?
7. Zvažte Compute Savings Plans pro vysokoobjemové Lambda workloady
8. Nastavte budget alerty v AWS Budgets / Azure Cost Management
9. Sledujte data transfer náklady odděleně od compute
10. Porovnejte náklady serverless vs. kontejnery pro stabilní workloady

Často kladené otázky (FAQ)

Je serverless vždy levnější než klasický hosting?

Rozhodně ne. Serverless je ekonomicky výhodný pro nepravidelný, špičkový nebo nepředvídatelný provoz. Pro stabilní workloady běžící 24/7 s vysokou utilizací často vychází levněji kontejnery na Reserved Instances nebo Committed Use Discounts. Neexistuje univerzální odpověď – záleží na konkrétním workloadu.

Jak zjistím, kolik mě serverless skutečně stojí?

Samotný ceník Lambda/Azure Functions/Cloud Functions ukazuje jen část příběhu. Pro celkový obraz musíte sečíst: compute (GB-sekundy), volání, API Gateway/Load Balancer, data transfer, logování a monitoring, úložiště pro deployment packages a náklady na přidružené služby (SQS, DynamoDB, EventBridge). AWS Cost Explorer s filtrováním podle tagu nebo resource ID je dobrý výchozí bod.

Vyplatí se AWS Compute Savings Plans pro Lambda?

Pokud vaše měsíční Lambda náklady přesahují $500–1 000, Savings Plans s úsporou až 17 % dávají smysl. Při menších výdajích je efekt minimální a líp uděláte, když se zaměříte na right-sizing paměti a přechod na Graviton2, které přinesou výraznější úspory bez dlouhodobého závazku.

Jaký je rozdíl mezi AWS Lambda, Azure Functions a Google Cloud Functions z hlediska ceny?

AWS Lambda nabízí nejpřesnější účtování (po milisekundách) a ARM variantu o 20 % levnější. Azure Functions mají srovnatelné ceny, ale vyšší minimální účtování (100 ms) a problematické cold starty v Consumption plánu. Google Cloud Functions jsou nejdražší za volání ($0,40 vs. $0,20 za milion), ale nabízejí štědřejší free tier (2 miliony volání) a oddělené účtování CPU a paměti – což může být výhodné pro CPU-intenzivní funkce.

Jak eliminovat cold starty bez zbytečných nákladů?

Místo plošné Provisioned Concurrency použijte Application Auto Scaling s target tracking, které dynamicky škáluje počet předehřátých instancí podle skutečné poptávky. Minimální kapacitu nastavte jen na úroveň odpovídající vašemu nejnižšímu stabilnímu provozu a nechte auto scaling pokrýt špičky. U Azure zvažte Premium plán jen pro kritické funkce – zbytek nechte klidně na Consumption plánu.