AWS Lambda пушта веб-сервери без адаптери, но засега само со Node.js

На 12 октомври 2026 година AWS со објавата за Lambda Web Functions пушти начин стандардни Node.js веб-сервери да работат на Lambda без адаптер што ги претвора HTTP барањата во настани. При пуштањето опцијата е достапна со Node.js 24 на Arm64 во пет региони: Северна Вирџинија, Охајо, Орегон, Токио и Ирска.

За постојна Express или Hono апликација тоа значи дека нејзиниот сервер може директно да прима HTTP барања преку порт, со постојните рути и посреднички функции. Опцијата е достапна, но префрлањето во продукција зависи и од верзијата на Node.js, зависностите, избраниот регион, начинот на распоредување и однесувањето на апликацијата при оптоварување.

Што се менува за Express и Hono

Web Function го извршува продукцискиот Node.js сервер на апликацијата, наместо да бара посебен Lambda обработувач за секое HTTP барање. Express и Hono ги задржуваат своите рути, а истиот модел може да го користи и React Router кога апликацијата стартува сервер. Ова е непосредна промена за API, серверски прикажани страници и одговори што се испраќаат постепено.

Серверот сепак мора да слуша на адресата и портот што Lambda ги задава преку AWS_LAMBDA_HTTP_ENDPOINT. Апликација со фиксно зададен порт ќе треба да го приспособи стартувањето, иако не ѝ треба адаптер за барањата. Кодот се испорачува како ZIP пакет; Lambda создава HTTPS крајна точка, а ревизијата претставува непроменлива верзија на кодот и конфигурацијата кон која таа точка го насочува сообраќајот.

Една извршна околина може истовремено да опслужува повеќе барања. Тоа му дозволува на веќе стартуван сервер да прими дополнителен сообраќај без секое барање да добие сопствена околина. Воедно, податоци чувани само во меморијата на процесот не се трајна состојба: околината може да биде отстранета кога нема сообраќај.

Node.js и регионите го стеснуваат изборот

Поддршката при пуштањето е за runtime nodejs24.x на Arm64. Проект на постара верзија на Node.js мора да ги провери пакетите и начинот на стартување пред префрлање. Зависност со нативен бинарен модул мора да има изведба за Linux Arm64; кај код напишан само во JavaScript нема таква архитектурна зависност. Апликација на Python, Java или .NET засега нема директна патека во овој модел на Web Functions.

Од почетните региони, Ирска е единствениот во Европа. За компанија од Северна Македонија тоа е важен избор ако местото на обработка или доцнењето се дел од барањата на услугата. Web Functions можат да го распоредат истиот код во повеќе избрани региони зад една крајна точка и да ги насочуваат барањата според доцнењето; затоа изборот на тие региони е дел и од одлуката каде ќе се обработува сообраќајот.

Lambda обезбедува HTTPS домен за крајната точка и избор меѓу IAM и автентикација управувана од апликацијата. За сопствен домен или AWS WAF пред крајната точка е потребна поставеност со Amazon CloudFront. Отстранувањето на адаптерот, според тоа, не ги отстранува мрежните и безбедносните поставки што ги има јавна продукциска услуга.

Кога одговара Web Function, а кога друг модел

Трите облици на Lambda решаваат различен начин на примање и извршување работа. Изборот за постојна апликација најлесно се прави според нејзиниот влез, потребната изолација и животниот циклус:

• Web Functions одговараат на Node.js HTTP сервер што прима веб-барања, опслужува API или прикажува страници. Една околина може истовремено да обработува повеќе барања, а процесорот се пресметува според активната работа.
• Event Functions одговараат на обработувачи што добиваат настан, на пример порака од редица или известување за датотека. Тие користат модел со обработувач и пресметка според траењето на извршувањето.
• MicroVMs одговараат на изолирани околини со состојба и животен циклус што го управува корисникот, меѓу другото за извршување недоверлив или кориснички код.

Апликација со јавен API и обработка на редица може да ги подели тие задачи: HTTP серверот да работи како Web Function, а потрошувачот на редицата како Event Function. Така новата опција го менува делот што навистина прима веб-сообраќај, без потреба асинхроната работа да се претвора во HTTP барања.

Зошто мирувањето сè уште чини

Во документацијата за Web Functions AWS ја разложува наплатата на барања, активно процесорско време, потрошена меморија во текот на животот на извршната околина и пренос на податоци. Кога барањето чека база на податоци или надворешен API, троши малку процесорско време. Меморијата продолжува да се пресметува и меѓу барањата додека околината постои.

Тоа ја прави пресметката различна за сервер што главно чека надворешни услуги и за сервер што постојано го оптоварува процесорот. Кај првиот, активното процесорско време може да биде мал дел од времетраењето на барањата; кај двата остануваат ставките за меморија, барања и пренос. Без сообраќајниот профил и потрошувачката на конкретната апликација не може да се изведе општа заштеда во однос на Event Functions или сегашниот хостинг.

Кога нема сообраќај, Lambda може да ги отстрани неактивните околини и да се скалира до нула. Првото следно барање може да почека нова околина да се иницијализира. Затоа реткиот сообраќај влијае на две одделни мерки: колку долго меморијата се пресметува додека околината постои и колку чека корисникот кога серверот повторно стартува.

Што останува за продукциско префрлање

Распоредувањето и ограничувањето на сообраќајот заслужуваат проверка со постојната инфраструктура на тимот. Во практичниот осврт на Ајдан Стил, SAM CLI во верзијата 1.168.0 не го пакувал автоматски кодот за Web Function, а пробен бран со ограничување од четири извршни околини завршил со одбиени 30 од 40 истовремени барања. Кога го отстранил тоа ограничување, авторот не забележал такви одбивања во повторениот пробен товар; резултатот се однесува на неговата поставеност, не на секоја апликација.

За Express или Hono тим, кратката миграциска проверка опфаќа дали апликацијата стартува HTTP сервер со зададениот порт, дали зависностите работат на Node.js 24 и Linux Arm64, дали избраниот регион е соодветен и дали постојниот процес за распоредување може да управува со ревизии и сообраќај. Потоа трошокот и доцнењето треба да се пресметаат од реалниот товар, вклучувајќи ги периодите без барања и првото барање по нив.

Најнепосредната последица е поедноставен HTTP дел за апликации што веќе работат како Node.js сервери. За продукциска миграција одлучува дали таа заштеда во прилагодувањето опстојува кога во истата сметка ќе влезат поддржаниот регион, нативните зависности, скалирањето и меморијата на активните околини.

Прочитајте и:

• AWS Savings Plans или Reserved Instances: заклучувањето ја менува заштедата
• AWS budget alert може сам да сопре ресурс, но IAM-улогата ја носи опасноста
• Omnissa пушта AI-агент во VDI, а задачите остануваат во контролиран простор