AWS Lambda gosti običajne strežnike, a za zdaj samo v Node.js

AWS je Lambda Web Functions uvedel 12. oktobra 2026: običajni strežniki HTTP lahko tečejo na Lambdi v okolju Node.js 24 na arhitekturi Arm64, med začetnimi regijami pa je tudi Irska. Med primernimi ogrodji so Express, Hono, Fastify in Next.js. Strežnik posluša na omrežnih vratih in aplikacije ni treba pretvoriti v dogodkovni upravljalnik.

Sprememba je pomembna za spletne aplikacije in API-je, ki že uporabljajo strežniški model Node.js. Web Function lahko v istem izvajalnem okolju obravnava več sočasnih zahtev, medtem ko običajna Lambda, zdaj poimenovana Event Function, obdeluje sprožitve z upravljalnikom. Za selitev sta odločilni dve meji: Web Functions trenutno podpirajo le Node.js, račun pa poleg dejavnega procesorja vključuje tudi pomnilnik med življenjsko dobo okolja.

Običajni strežnik dobi končno točko Lambda

Aplikacija Express lahko ohrani svoje poti, vmesno programsko opremo in običajen način obravnave zahtev HTTP. Ob zagonu mora poslušati na naslovu in vratih, ki ju določa spremenljivka AWS_LAMBDA_HTTP_ENDPOINT; prilagoditveni vmesnik za pretvarjanje zahtev v dogodke Lambda ni potreben. Enaka zamisel velja za druga ogrodja Node.js, če njihova produkcijska aplikacija zažene strežnik na določenih vratih.

Koda se uvede kot paket ZIP. Web Function ima revizije, torej nespremenljive posnetke kode in nastavitev, ter končne točke HTTPS, ki zahteve usmerjajo v izbrano revizijo. Končna točka lahko promet razdeli med dve reviziji, zato je mogoče novo izdajo uvajati postopoma. Strežnik še vedno deluje kot proces v izvajalnem okolju, Lambda pa okolja ustvarja in odstranjuje glede na promet. Aplikacija vodi poti in odzive, storitev pa življenjski cikel okolij.

Sočasnost zmanjša potrebo po novih okoljih

Eno ogreto okolje Web Function sprejme več zahtev hkrati. Manjši porast prometa lahko zato prevzame že delujoči proces, pri večji obremenitvi pa Lambda doda okolja. Ko zahteve prenehajo prihajati, se lahko storitev zmanjša na nič aktivnih okolij; naslednja zahteva mora tedaj počakati na inicializacijo. Pri Event Functions vsaka sočasna sprožitev zahteva svoje izvajalno okolje. Zato enaka količina sočasnih zahtev pri obeh oblikah ne pomeni enakega števila okolij.

Končna točka Web Function omogoča omejitev hitrosti zahtev in največjega števila okolij. S tem lahko aplikacija varuje podatkovno bazo pred sunkom prometa, vendar prenizka meja zavrne tudi uporabniške zahteve. Aidan Steele je v neodvisnem preizkusu Web Functions pri meji štirih okolij poslal 40 sočasnih zahtev in pri prvem sunku prejel 30 odgovorov HTTP 429. V poznejših ponovitvah je bilo zavrnitev manj; ko je omejitev okolij odstranil, jih v ponovljenem preizkusu ni opazil. Gre za rezultat njegove konkretne nastavitve in obremenitve.

Procesor in pomnilnik tečeta po različnih urah

Dokumentacija AWS za Web Functions navaja štiri postavke obračuna: zahteve, dejavni procesorski čas, pomnilnik skozi življenjsko dobo izvajalnega okolja in prenos podatkov. Ko strežnik čaka na poizvedbo v podatkovni bazi ali odgovor drugega API-ja, porabi malo procesorskega časa. Pomnilnik pa se obračunava tudi med mirovanjem okolja med zahtevami. Obračun zato ni zgolj seštevek trajanj posameznih odgovorov.

Pri pogojnem API-ju, ki veliko časa čaka na podatkovno bazo, je lahko procesorski del računa manjši, saj čakanje ne pomeni enake porabe procesorja kot aktivno računanje. Če okolje zaradi prometa ostaja pri življenju, se njegov pomnilniški del še naprej nabira. Ob več sočasnih zahtevah se strošek pomnilnika istega okolja porazdeli med več odgovorov; pri redkem prometu je to razmerje lahko drugačno. Za aplikacijo, ki večino časa računa, prednost obračuna dejavnega procesorja ni samoumevna.

Node.js določa, kaj se lahko preseli neposredno

Za obstoječo aplikacijo v Expressu ali Honu je Web Function možnost, ker lahko njen strežnik neposredno odgovarja na zahteve HTTP. To velja tudi za strežniško izrisovanje in API-je, ki jih aplikacija že izvaja v procesu Node.js. Za obdelavo sporočil v vrsti, nalaganje datotek in druga opravila, ki jih sprožijo dogodki, ostajajo primerne Event Functions. Znotraj istega sistema se lahko zato spletni promet izvaja v Web Function, delo v ozadju pa v dogodkovnih funkcijah.

Strežnik v Pythonu, Javi ali .NET se v tej začetni različici ne more enako neposredno preseliti v Web Functions. Za te jezike sta na voljo Event Functions ali Lambda MicroVMs, ki uporabljajo drugačen način izvajanja. Tudi aplikacija v Node.js, zgrajena okoli dogodkovnega upravljalnika, nima samodejnega razloga za prehod: spremenila bi se način izvajanja in obračun, ne zgolj ime funkcije.

Lastna domena doda CloudFront

Web Function dobi lastno končno točko HTTPS, vendar nanjo ni mogoče neposredno pripeti domene po meri. Za lastno domeno ali zaščito AWS WAF je pred njo potrebna distribucija Amazon CloudFront. Ta lahko statične datoteke vrača iz predpomnilnika, dinamične zahteve pa posreduje strežniku na Lambdi. Z nadzorom dostopa do izvora je mogoče omejiti tudi neposreden dostop do končne točke. Pri javni spletni aplikaciji je to dodatna sestavina arhitekture.

Končno točko je mogoče razširiti na več regij in zahteve usmerjati glede na zakasnitev. Bližina strežniškega procesa uporabniku še ne pove, kako hitro se odzovejo podatkovna baza in druge odvisnosti. Če te ostanejo v oddaljeni regiji, se lahko del poti zahteve podaljša kljub bližji vhodni točki.

Preberite tudi:

• AWS Lambda ali Cloudflare Workers: cena zahteve ne pove zakasnitve
• Slack ali Mattermost: nadzor nad podatki prinese račun za strežnik