Srovnání platforem FaaS: AWS Lambda a Azure Functions

FaaS jako stavební kámen serverless architektur

Function as a Service (FaaS) abstrahuje servery a provozní správu: vývojář nasazuje pouze funkce reagující na události. Dvě nejrozšířenější platformy v podnikovém prostředí jsou AWS Lambda a Azure Functions. Obě se škálují na požádání, účtují podle skutečného běhu a integrují se do bohatých ekosystémů služeb. Liší se však v detailech spouštěčů, modelu vývoje, škálování, síťové integrace, observability, cen a správy stavu. Tento článek přináší technicky podrobné srovnání a praktická doporučení.

Architektura a spouštěče (triggery)

• AWS Lambda: spouštění prostřednictvím event sources (S3, SQS, SNS, DynamoDB Streams, Kinesis, EventBridge, API Gateway/ALB, CloudWatch Events/cron). Podporuje také Function URL pro přímý vstup HTTP bez API Gateway a Lambda@Edge v síti CDN CloudFront.
• Azure Functions: spouštění prostřednictvím bindings & triggers (HTTP, Timer, Queue/Service Bus, Event Grid, Event Hubs, Cosmos DB change feed, Blob/Files). Silná integrace se službami Azure Storage, API Management a Event Grid.

Bindings (Azure) zjednodušují přístup k I/O bez nutnosti psát klienty. Lambda cílí na obecný model událostí a explicitní práci se službami prostřednictvím SDK.

Runtimy, balení a nasazení

• Jazyky: Node.js, Python, Java, .NET, Go; Lambda navíc podporuje vlastní runtime prostřednictvím Runtime API. Azure Functions podporuje také PowerShell a Javu s Isolated worker pro .NET.
• Balení: Lambda ZIP (typicky až stovky MB po rozbalení) nebo container image (ECR) pro složité závislosti. Azure Functions běží jako úloha typu App Service – lze ji nasadit jako kód i jako kontejner (ACR).
• Infrastructure-as-Code: Lambda – AWS SAM, CDK, Terraform, Serverless Framework. Functions – Bicep/ARM, Terraform, Pulumi; lokální nástroje Azure Functions Core Tools.
• Verzování a směrování: Lambda versions/aliases s weighted traffic (canary). Azure deployment slots s řízeným přepnutím.

Škálování, souběh a studené starty

• Automatické škálování: Lambda se škáluje podle příchozích událostí – každé souběžné spuštění představuje izolovanou instanci. Azure škáluje instanční „workers“ podle zátěže a přiděluje jim invokace funkcí.
• Cold start: inicializace runtime a načtení balíčku. Zmírnění: Lambda Provisioned Concurrency a (zejména pro JVM) SnapStart. Azure: Premium plan s předem zahřátými instancemi.
• Limity a řízení: na obou platformách lze nastavovat concurrency limits pro ochranu navazujících služeb; integrační služby (SQS/Service Bus) mají vlastní mechanismy opakování a back-pressure.

Plány a modely účtování

• Lambda: cena = GB-sekundy (paměť × doba běhu) + počet požadavků. Vyšší paměť zvyšuje také výkon CPU/IOPS. Ušetřit lze prostřednictvím Compute Savings Plans a volbou Graviton/arm64.
• Azure Functions: Consumption (platba za běh + transakce), Premium (předem zahřáté instance, VNET, vyšší výkon) a Dedicated (App Service plan). Náklady ovlivňuje také objem přenesených dat prostřednictvím bindings.

U obou platforem je klíčové zkrátit dobu běhu, minimalizovat zápisy do vzdálených úložišť a zvolit odpovídající velikost paměti → vyšší výkon CPU zkrátí dobu běhu a často i sníží cenu.

Síť a konektivita: VPC/VNet, privátní přístup

• AWS: Lambda v privátním VPC má ENI a může přistupovat k RDS/ElastiCache; pro odchozí provoz na internet je nutný NAT. Využívejte VPC endpoints pro přímý přístup k S3/Secrets Manager bez internetu.
• Azure: VNet Integration (odchozí provoz), Private Endpoints a Private Link pro služby, jako jsou Storage/Key Vault; plán Premium nabízí plnohodnotnější podporu VNet.

Nezapomínejte na connection reuse a pooling, případně na zprostředkující proxy: AWS RDS Proxy, Azure SQL connection pooling/Managed Identity → výrazně sníží zatížení DB při škálování.

Stav, workflow a dlouhotrvající úlohy

• Lambda: stav se uchovává mimo funkci (DynamoDB, S3, ElastiCache). Koordinace prostřednictvím AWS Step Functions (stavy, opakování, paralelizace, map state). Plánování/cron prostřednictvím EventBridge.
• Azure: Durable Functions (orchestrator, entity functions) – vzory fan-out/fan-in, human interaction, saga. Časovače prostřednictvím Timer Trigger.

Pro běhy delší než 15 minut používejte workflow a rozdělení práce na části (chunking), nikoli „nekonečné“ funkce. Příjem dat ze streamů řešte prostřednictvím Event Hubs/Kinesis + consumer groups/shards.

Observabilita a tracing

• AWS: CloudWatch Logs/Metrics, Embedded Metrics, distribuované trasování prostřednictvím AWS X-Ray, podpora OpenTelemetry (OTel Collector jako extension). EventBridge Pipes s DLQ a metrikami.
• Azure: Application Insights (telemetrie, mapa závislostí, dotazy Kusto), Log Analytics, nativní OTel. Bindings automaticky generují telemetrii.

Sjednoťte korelační ID, zapisujte strukturované logy (JSON) a nastavte alerts/SLO pro latenci p95, míru chyb a metriky throttlingu/lagu front.

Bezpečnost, identita a tajemství

• Identita při běhu: Lambda execution role (IAM); Azure Managed Identity (MSI). Přidělujte pouze nezbytná oprávnění (least privilege), do kódu nevkládejte žádné statické klíče.
• Tajemství: AWS Secrets Manager/SSM Parameter Store, Azure Key Vault. Hodnoty ukládejte do mezipaměti v rámci „zahřátého“ runtime a respektujte jejich rotaci.
• Zabezpečení na okraji sítě: API Gateway / API Management pro omezení počtu požadavků, ověřování (JWT/OAuth2), WAF a mTLS.

Výkonnost: optimalizace cold startu a běhu

• Balíček: minimalizujte jeho velikost a počet závislostí, používejte tree-shaking, modulární importy a lokální bundling (esbuild, SWC).
• Inicializace: náročnou inicializaci přesuňte mimo handler (využijte opakovaně použitelný kontext), podle potřeby použijte lazy-load.
• I/O a úložiště: maximalizujte přístup k datům v paměti, používejte dočasné úložiště (/tmp) s rozumným limitem; požadavky do navazujících služeb odesílejte v dávkách.
• Výběr paměti: testujte různé alokace – více paměti znamená vyšší výkon CPU → kratší dobu běhu a často nižší cenu.

Vzory integrace s událostmi a frontami

• At-least-once: Lambda ze SQS/Kinesis a Functions ze Service Bus/Event Hubs doručují zprávy opakovaně → používejte idempotenci, deduplikaci (klíč, hash) a transakční outbox.
• DLQ/Poison queue: po vyčerpání pokusů o opakování přesouvejte zprávy do DLQ a spouštějte kompenzační/analytické toky.
• Back-pressure: omezte batch size, nastavte max concurrent u triggerů a škálujte spotřebitele s ohledem na kapacitu DB/externích API.

Scénáře HTTP/API

• AWS: API Gateway (REST/HTTP) s authorizéry (JWT/Lambda), směrováním, validací a transformací. Alternativou je ALB target (Lambda) nebo Function URL pro jednoduché veřejné endpointy.
• Azure: nativní HTTP trigger se šablonami rout a integrace se službou Azure API Management (kvóty, produkty, verze, zabezpečení).

Pro streaming responses a velké payloady zvažte proxy v PaaS (App Service/Container Apps) nebo edge funkce (CloudFront Functions/Workers) podle požadavků na latenci a limitů.

Limity prostředí a souborový systém

• Doba běhu: typicky do 15 minut na jednu invokaci (Lambda i Azure Consumption). Dlouhé úlohy rozdělte na menší kroky a orchestrujte.
• Paměť/CPU: Lambda až na jednotky GB s lineárním škálováním CPU; výkon Functions se škáluje podle plánu (Premium/Dedicated mají více CPU/RAM).
• Ephemeral storage: dočasné /tmp (limit lze zvýšit) – vhodné pro kompresi a dočasné soubory, nikoli pro trvalá data.
• Vrstvy/rozšíření: Lambda Layers a Extensions (telemetrie, zabezpečení); Azure Extension bundles pro bindings.

CI/CD, testování a lokální vývoj

• Lokální běh: Lambda – sam local, LocalStack; Azure – func start (Core Tools) s emulací Storage/Queues.
• Testy: jednotkové (izolace handleru), kontraktační (schémata událostí), integrační (skutečné služby v sandboxu), chaos testy (latence/timeouty).
• Nasazení: Lambda aliases pro canary, Azure deployment slots s postupným přepnutím. Po nasazení automaticky ověřujte zdraví (synthetic checks).

Bezstavovost vs. „zahřátý“ kontext

Funkce musí být bezstavové. „Zahřátý“ kontext (opětovné použití procesu) je optimalizační výhoda, nikoli spolehlivá vlastnost. Mezipaměť (klienti DB, tajemství, vyhledávací tabulky) uchovávejte v globálním scope a navrhujte bezpečně s ohledem na paralelismus.

Funkce na okraji sítě a hybridní běh

• AWS: Lambda@Edge a CloudFront Functions pro extrémně nízkou latenci při úpravě hlaviček HTTP a směrování.
• Azure: Functions lze provozovat v prostředích Container Apps/Kubernetes s KEDA (škálování na nulu podle metrik), případně v Edge Zones.

Srovnávací tabulka

Bezpečnostní a provozní „ochranná opatření“

• Implementujte rate limiting a timeouts na všech hranicích; definujte DLQ a retry policy.
• Vynucujte least privilege (IAM/AAD), auditujte přístupy k tajemstvím a zaznamenávejte všechny administrativní akce.
• Nastavte budgets & alerts (náklady/počty invokací) a sledujte anomálie v provozu.

Typické anti-patterny

• Časté I/O: synchronní volání DB/API v cyklu bez dávkování → používejte hromadné operace a asynchronní fronty.
• Neřízený paralelismus: škálování „naplno“ proti neelastickým backendům → nastavte reserved/concurrent limits a back-pressure.
• Velké monolitické balíčky: zbytečně dlouhé cold starty → rozdělte je do menších funkcí a sdílených knihoven.
• Stav v paměti: spoléhání na „zahřátou“ instanci pro business stav → trvalý stav uchovávejte ve spravovaných úložištích.

Rozhodovací rámec: kdy Lambda a kdy Functions

1. Cloudový kontext: prostředí zaměřené na AWS (DynamoDB, S3, Kinesis) → Lambda; Azure (AAD, Service Bus, Cosmos DB) → Functions.
2. Požadavky na workflow: komplexní orchestraci s lidskou interakcí → Durable Functions; mikroorchestrace řízené událostmi a integrace se službami AWS → Step Functions.
3. HTTP/API: správa podnikových API, verzování a monetizace → Azure APIM + Functions; masivní příjem událostí a flexibilní směrování → API Gateway + Lambda.
4. Latence a cold starty: kritická latence → Lambda Provisioned Concurrency nebo Azure Premium, případně edge funkce.

Kontrolní seznam pro nasazení do produkce

• Definované SLO (latence p95, chybovost, dostupnost) a error budget.
• Upozornění na throttles, DLQ depth, invocation errors a náklady.
• Idempotence při event processing, korelace událostí, audit trail.
• Bezpečný přístup k tajemstvím (MSI/IAM), klíče mimo kód, rotace.
• Nasazení canary (aliases/slots), automatický rollback na základě metrik.

Závěr: praktická doporučení

Lambda i Azure Functions umožňují budovat vysoce škálovatelné a nákladově efektivní systémy, pokud jsou navrženy jako event-driven, bezstavové a s důrazem na idempotenci, observabilitu a back-pressure. Volbu platformy určujte především podle ekosystému navazujících služeb, požadavků na orchestraci a principů správy identity. Investice do CI/CD, testů (včetně scénářů chaos/failover), správné konfigurace sítí a řízení nákladů rozhoduje o úspěchu více než samotná volba FaaS. Správně navržené funkce pak tvoří lehké, bezpečné a snadno vyvíjitelné stavební bloky moderních serverless aplikací.