AWS объявила о AWS Lambda Web Functions — новом формате в составе Lambda, который позволяет напрямую запускать веб-приложения и стандартные HTTP-серверы без переписывания кода под традиционную модель обработчиков событий. Приложения, созданные с использованием Express, Hono, Fastify, Next.js или любого фреймворка Node.js, можно развёртывать одной командой без специальных адаптеров и дополнительного управления инфраструктурой.
Сервис предназначен для веб-приложений, API, рендеринга на стороне сервера и интерактивных HTTP-нагрузок, работающих с одновременными запросами и интенсивной обработкой операций ввода-вывода.
Другая модель выполнения внутри Lambda
Теперь AWS предлагает три различные модели выполнения в Lambda, все они основаны на технологии изоляции Firecracker. Event Functions по-прежнему подходят для обработки событий, потребления сообщений и вызовов, инициированных сервисами AWS: обработчик получает одно событие и возвращает ответ в соответствии с традиционной моделью.
Web Functions используют нативную для HTTP модель: приложение прослушивает порт и обрабатывает стандартные запросы. Одна среда выполнения может обрабатывать до 128 одновременных запросов. Третья модель, Lambda MicroVMs, предоставляет изолированные среды с постоянным состоянием и жизненным циклом, которым управляет клиент, для запуска ненадёжного кода или кода, создаваемого пользователями.
Что практически меняется для разработчиков?
AWS утверждает, что Web Functions уменьшают необходимость собирать несколько компонентов для глобального распределения веб-приложения. Сервис берёт на себя масштабирование, репликацию между регионами и маршрутизацию на основе времени отклика, а код остаётся ближе к HTTP-серверу, который разработчик запускает локально.
Тарификация Web Functions зависит от времени использования процессора, тогда как память оплачивается на протяжении всего существования среды выполнения. Поэтому время, которое приложение проводит в ожидании запроса к базе данных или вызова API, потребляет небольшое количество процессорного времени. Такая модель может подходить для нагрузок, интенсивно использующих ввод-вывод, например для рендеринга на стороне сервера, API и конечных точек вывода ИИ, которые передают токены потоково.
Это не означает, что стоимость автоматически будет ниже для каждого приложения: результат зависит от характера использования, продолжительности существования сред, потребления памяти и объёма запросов.
Развёртывание, распределение и версии
AWS CLI использует команду вроде aws lambda-web deploy для сборки кода, создания Web Function, публикации первой ревизии и привязки конечной точки HTTPS. Приложение можно развернуть в нескольких регионах, таких как us-east-1, eu-west-1 и ap-northeast-1, чтобы Lambda направляла запросы через один глобальный адрес в регион с наименьшим временем отклика на основе принципа наилучших усилий.
Сервис рассматривает каждую версию как неизменяемый снимок кода. Конечные точки также позволяют распределять трафик между версиями, включая постепенный выпуск типа canary, при котором, например, 90% запросов направляются на текущую версию, а 10% — на новую.
Интеграция с CloudFront и первоначальная доступность
Конечную точку Web Function можно использовать как источник для Amazon CloudFront: статические ресурсы будут кэшироваться в сети, а динамические запросы направляться в веб-функцию. AWS также поддерживает привязку CloudFront origin access control к конечной точке, чтобы разрешить вызовы только определённому домену, не раскрывать конечную точку и не добавлять в приложение собственный механизм авторизации.
На момент запуска сервис доступен в регионах US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) и Europe (Ireland). Изначально он работает с Node.js 24 (nodejs24.x) на Arm64 и поддерживает подключение к Amazon VPC для доступа к ресурсам, находящимся внутри виртуальных частных сетей.