AWS Lambda로 웹 애플리케이션을 운영해 본 분이라면 세 가지 제약을 한 번쯤 겪어 보셨을 것입니다. Express나 Next.js 같은 프레임워크를 올리려면 이벤트 핸들러로 감싸는 어댑터가 필요했습니다. 실행 환경 하나가 요청 하나만 처리하므로 LLM 토큰 스트림처럼 오래 열려 있는 연결이 늘어날수록 실행 환경도 같은 수만큼 늘어났습니다. 데이터베이스나 외부 API 응답을 기다리는 시간도 실행 시간으로 과금되었습니다.
2026년 10월 12일 발표된 AWS Lambda Web Functions는 이 세 가지를 한 번에 바꿉니다. 표준 HTTP 서버를 어댑터 없이 그대로 배포합니다. 실행 환경 하나가 최대 128개 요청을 동시에 처리하고 CPU는 실제로 연산한 시간만 과금됩니다. 같은 날 Amazon CloudFront도 Lambda Web Functions를 오리진으로 지원하기 시작했습니다. 이 글은 2부작 시리즈의 1부입니다. Web Functions의 실행 모델과 리소스 구조, 과금 방식, 배포와 트래픽 전환, CloudFront 오리진 구성을 정리하고 기존 Lambda 함수인 Event Functions와의 비용 차이를 요금 페이지 예시로 계산합니다. 2부에서는 Web Functions를 BFF(Backend for Frontend)로 두고 Amazon Bedrock AgentCore Runtime을 호출하는 구성을 다룹니다.
1. Lambda의 세 가지 형태와 Web Functions의 위치
1.1 Event Functions, Web Functions, MicroVMs
이번 발표로 Lambda는 세 가지 형태를 갖게 되었습니다. 기존 Lambda 함수는 Event Functions라는 이름으로 구분되고 새로 추가된 Web Functions와 MicroVMs가 그 옆에 놓입니다. 세 형태 모두 Firecracker 기반 격리 위에서 실행됩니다.
그림 1. Lambda의 세 가지 형태 비교 (2026년 10월 발표문, Lambda 개발자 가이드, Lambda FAQ 기준. Event Functions의 동시 요청 수는 Lambda Managed Instances를 제외한 온디맨드 기준)
선택 기준은 단순합니다. 큐 메시지나 파일 업로드처럼 이벤트를 처리하고 끝나는 작업은 Event Functions에, 브라우저나 API 클라이언트가 HTTP로 직접 호출하는 워크로드는 Web Functions에 둡니다. Java, Python, .NET이 필요하면 Event Functions나 MicroVMs를 선택합니다.
1.2 Web Functions가 바꾸는 세 가지
Web Functions가 바꾸는 것은 프로그래밍 모델, 동시성, 과금의 세 가지입니다.
그림 2. Event Functions와 Web Functions의 실행 모델 비교
첫째, 프로그래밍 모델입니다. Web Functions는 이벤트 핸들러 대신 포트에서 대기하는 HTTP 서버를 실행하며 Lambda에 특화된 부분은 AWS_LAMBDA_HTTP_ENDPOINT 환경 변수를 읽는 한 줄뿐입니다. Express, Fastify, Hono는 어댑터 없이 실행됩니다.
둘째, 동시성입니다. Event Functions의 실행 환경은 한 번에 요청 하나만 처리하므로 열려 있는 스트림 하나가 실행 환경 하나를 점유합니다. Web Functions의 실행 환경은 다중 동시 실행(Multi-concurrency)으로 여러 요청을 함께 처리합니다.
셋째, 과금입니다. Web Functions는 활성 CPU 과금(Active CPU billing)으로 코드가 실제로 연산하는 동안만 CPU 시간을 과금하므로 데이터베이스나 AI 추론 응답을 기다리는 시간은 CPU 비용에 거의 반영되지 않습니다. 대신 메모리는 실행 환경이 살아 있는 동안 유휴