Röviden: A serverless nem olcsó. Csak akkor olcsó, ha a gép tényleg alszik. 2026 nyarán, preview runtime-okkal és saját S3-kódtárral a kérdés ugyanaz maradt: milyen a te terhelésed alakja?
A Lambda-számlát kétféle csapat szokta félreérteni. Az egyik azt hiszi, a serverless mindig olcsóbb, mert „nincs gép”. A másik azt, hogy mindig drágább, mert millió kérésenként fizetsz. 2026 nyarán, amikor a Lambda nyilvános preview-runtime-ot kapott Node.js 26-hoz és Python 3.15-höz, és amikor a függvénykódot saját S3-bucketben is tarthatod, a kérdés nem az, hogy a Lambda jó-e. A kérdés az, hogy a te terhelésed alszik-e eleget ahhoz, hogy a használatalapú modell kifizetődjön — vagy annyira folyamatos, hogy a kényelem felára már a költségvetést viszi.
A terhelés alakja dönt, nem az identitás
„Mi serverless cég vagyunk” — ezt a mondatot akkor hallod, amikor egy csapat identitást csinál egy futtatókörnyezetből. A Lambda akkor nyer, ha a munka tüskés, eseményvezérelt, és a gép a nap nagy részében tényleg nem dolgozik: webhook, éjszakai riport, feltöltés utáni transzformáció, ritka admin-művelet. Ott a nulla alapdíj a lényeg. Ha viszont a függvény percenként több százszor ébred, tartós kapcsolatot tart, vagy percnyi CPU-t rág, a számla gyorsan utoléri — majd megelőzi — egy kihasznált Fargate-szolgáltatást vagy egy jól méretezett EC2-t.
A 2026-os preview-runtime-ok praktikus jelei annak, hogy a Lambda továbbra is a gyors kísérletezés helye: új nyelvi verziót a GA előtt ki lehet próbálni, visszajelzést adni, és nem kell saját image-et karbantartani. Ez nem indok arra, hogy mindent függvénybe tegyél. Csak arra, hogy ahol a modell illik, ott ne maradj le a futtatókörnyezetről.
A serverless nem olcsó. Csak akkor olcsó, ha a gép tényleg alszik.
A rejtett költségek, amiket a kalkulátor nem mutat
A GB-másodperc csak a kezdet. A valós Lambda-számla ott dagad, ahol a kéréshez tartozó adatmozgás és a megfigyelés belép. Nagy payload az API Gatewayen, chatty DynamoDB, Cross-Region hívás, végtelen CloudWatch-megőrzés: ezek külön sorok, és külön viselkednek. Egy „olcsó” függvény, ami minden hívásban háromszor olvas és kétszer ír, plusz mindent naplóz JSON-ban, hamar többe kerül, mint a compute maga.
A 2026 júliusi változás — hogy a függvénykódot saját, általad kezelt S3-bucketben tarthatod — pont a skálázó csapatoknak szól. A 75 GB-os kódtár-limit és a „melyik bucketben van az artifact, amit a security nem lát” vita sok helyen ugyanaz a beszélgetés volt. Saját bucket: saját lifecycle, saját encryption-policy, saját audit. Ez nem olcsóbbá teszi a Lambdát, csak üzemeltethetőbbé, ha már sok függvényed van.
Hidegindítás, memória, timeout: a három gomb
A hidegindítás 2026-ban is létezik, csak kevesebbet beszélünk róla, mert a provisioned concurrency és a gyorsított indítás eltakarják. Akkor fáj, ha a p95 latencia üzleti SLO. Egy belső ETL-nél simán elfogadható; egy checkout-API-nál nem. A memória-állítás továbbra is a legolcsóbb teljesítménykar: több memória több CPU-t ad, és gyakran rövidebb futással fizetsz kevesebbet. A timeoutot ne „hagyjuk harminc másodpercen, majd kiderül” alapon állítsd — a túl bő timeout a beragadt függvények számlája, a túl szűk a hamis hibáké.
A durable functions megfigyelhetősége — strukturált log, X-Ray, callback-timeout riasztás — 2026-ban már nem extra, hanem belépő. Ha a folyamat percekig, órákig él, a „függvény lefutott” metrika önmagában vak. Itt a Lambda már nem olcsó glue, hanem hosszú életű orchestrator, és ettől a költségmodellje is más: a várakozás ideje és a callback hibái viszik el a türelmedet, nem a CPU.
Mikor ne Lambda legyen
Három piros zászló. Először: tartós, kiszámítható terhelés, ahol a kihasználtság a nap nagy részében magas — ott a használatalapú modell felárat fizettet. Másodszor: speciális hálózat, GPU, vagy olyan library, ami a Lambda korlátait (csomagméret, /tmp, futási idő) rendszeresen feszegeti. Harmadszor: a csapatnak nincs fegyelme a megfigyelésre. Elosztott rendszerben a vak üzemeltetés drágább, mint egy unalmas, de átlátható szolgáltatás.
A feature flag AppConfigon, a saját S3-kódtár, a preview runtime: ezek mind azt üzenik, hogy a Lambda érett platform. Az érett platformot akkor használd, amikor a terhelésed is érett hozzá. A „minden serverless” identitás 2026-ban ugyanolyan drága hiba, mint a „semmi se legyen függvény” dogma.
Magyar csapatnál van egy negyedik, kevésbé technikai érv is. Ha ketten vagytok, a Lambda azért vonzó, mert kevesebb éjszakai ügyeletet jelent. Ez valós. De csak addig, amíg a rendszered kicsi és a hibák lokalizálhatók. Amikor tizenöt függvény, három queue és két DynamoDB-tábla között kell keresni egy elveszett korrelációs azonosítót, a „nincs szerver” hirtelen azt jelenti: nincs hova belépni. Ekkor a megfigyelésbe fektetett óra többe kerül, mint egy unalmas, de egyben tartott szolgáltatás.
Hogyan mérj egy hét alatt, hazugság nélkül
A döntéshez nem kell éves projekt. Kell egy hétnyi őszinte adat. Nézd a kérésszámot órákra bontva, ne napi átlagban — az átlag elkeni az éjszakai nullát és a délelőtti tüskét, pedig pont ez a kettő dönt. Nézd a p95 durációt memóriánként: 128 MB-on hosszú, 512-n rövid, 1024-en már nem rövidül. Ott van a gazdasági optimum, nem a „adjunk neki 3008-at, aztán tuti”. Nézd a konkurenciát: ha a reserved concurrency mindig a plafonon van, a Lambda már nem alszik, csak sorban áll.
A Cost Explorerben bontsd szét a compute-ot, az API Gatewayt, a DynamoDB-t és a naplót. Ha a napló vagy a NAT nagyobb sor, mint a függvény, nem compute-problémád van. Egy magyar B2B SaaS-nél, ahol a nappali forgalom a munkaidőhöz simul, a Lambda gyakran nyer a webhookon és a reporton, és veszít a folyamatos API-n. Ne egyetlen számmal dönts a teljes backendről. Dönts komponensenként, és írd le, melyik miért marad.
A hidegindítás mérése külön fejezet. A átlagos latencia szépségverseny. A p95 és a p99 az, amit a felhasználó érez, és amit a SLO-d véd. Ha a hidegindítás a p99-et viszi, provisioned concurrency egy szűk, üzleti útvonalon indokolt — az egész függvényparkra nem. A provisioned concurrency a „gép mégsem alszik” beismerése, csak drágábban, mint egy kicsi, mindig futó szolgáltatás. Használd ott, ahol a pénzt a latencia viszi, nem a számla-ideológia.
Mit jelent ez neked?
Mérd a terhelés alakját egy héten át, ne a slogant. Ha a munka tüskés, tartsd Lambdán, állítsd a memóriát, korlátozd a logmegőrzést, és próbáld ki a preview runtime-ot, mielőtt GA-kor kapkodsz. Ha a függvény gyakorlatilag mindig ébren van, számold ki ugyanazt Fargate-en vagy egy kis EC2-n — ne érzésre. A saját S3-kódtárat akkor vedd elő, ha a 75 GB vagy a security audit már fáj; addig ne optimalizálj problémát, amid nincs. A serverless akkor spórol, ha hagyod aludni a gépet. Ha nem alszik, fizetsz a meseért.