이 글은 AWS 공식 블로그와 AWS 공식 문서/제품 페이지만을 출처로 작성했습니다. (2026년 11월 기준)
수치, 요금, 한도는 바뀔 수 있으니 실제 적용 전에는 글 하단의 공식 링크에서 최신 정보를 확인하세요.
1. 들어가며
2026년 10월 12일, AWS는 AWS Lambda Web Functions를 발표했습니다. 이번 발표로 Lambda는 다음 세 가지 형태(form factor)를 갖게 되었습니다. 세 가지 모두 같은 Firecracker 격리 기술 위에서 동작합니다.
| 폼 팩터 | 특징 | 적합한 워크로드 |
|---|---|---|
| Event Functions | 기존 Lambda. 이벤트 기반 핸들러, 환경당 동시 1요청, 실행 시간(wall-clock) 기준 과금 | 이벤트 처리, 큐 컨슈머, 서비스 트리거 작업 |
| Web Functions | HTTP 네이티브, 환경당 다중 동시 요청, 활성 CPU 기준 과금, 코드가 포트에서 대기(listen) | 웹 앱, API 백엔드, 인터랙티브 HTTP 워크로드 |
| MicroVMs | 고객이 수명주기를 관리하는 격리된 상태 유지(stateful) 샌드박스 | 신뢰할 수 없는 코드, 사용자 생성 코드 실행 |
이 글에서는 이 중 Web Functions를 집중적으로 다룹니다.
[그림 1] Lambda의 세 가지 폼 팩터 비교
2. Web Functions란?
Web Functions는 포트를 열고 대기하는 평범한 Node.js HTTP 서버를 Lambda에서 그대로 실행하는 서비스입니다.
기존 Lambda(Event Functions)는 handler(event, context) 형태의 함수를 작성하고, API Gateway나 Function URL이 HTTP 요청을 이벤트 객체로 바꿔서 전달하는 방식이었습니다. 반면 Web Functions에서는 Express, Fastify, Hono, Koa, Next.js 같은 프레임워크로 만든 서버가 직접 HTTP 요청을 받습니다. Lambda Web Adapter 같은 이벤트-HTTP 변환 어댑터도 필요 없습니다.
주요 특징
- 코드 변경 최소화: 기존 Node.js 웹 프레임워크를 어댑터나 독점 API 없이 사용
- 다중 동시성(Multi-concurrency): 실행 환경 하나가 최대 128개의 요청을 동시에 처리 (기본값 64)
- 활성 CPU 과금: DB나 외부 API 응답을 기다리는 I/O 대기 시간은 CPU 요금으로 청구되지 않음
- 네이티브 스트리밍: SSE(Server-Sent Events), chunked transfer, 요청/응답 스트리밍 지원
- 한 줄 배포:
aws lambda-web deploy한 번으로 HTTPS 엔드포인트까지 생성 - 멀티 리전: 하나의 글로벌 도메인 뒤에서 지연 시간 기반 라우팅
- CloudFront 오리진 지원: OAC(Origin Access Control)로 배포(distribution)에서 오는 요청만 받도록 구성 가능
- VPC 연결 지원
- 0까지 스케일: 트래픽이 없으면 실행 환경도 0개
3. 프로그래밍 모델
3.1 리슨 주소
Lambda는 서버가 바인딩해야 할 호스트와 포트를 AWS_LAMBDA_HTTP_ENDPOINT 환경 변수에 host:port 형식으로 넣어 줍니다. 서버는 시작할 때 이 값을 읽어서 listen하기만 하면 됩니다.
// index.js (Express 예시)
const express = require('express');
const app = express();
app.get('/', (req, res) => {
res.json({ message: 'Hello from Lambda Web Functions!' });
});
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host, () => {
console.log(`Server running on port ${port}`);
});
로컬에서는 이 변수가 설정되지 않으므로 기본값(localhost:3000)이 쓰이고, 직접 지정해서 실행할 수도 있습니다.
AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js
3.2 런타임과 진입점
| 항목 | 내용 |
|---|---|
| 런타임 | nodejs24.x (Node.js 24), 현재 유일한 지원 런타임 |
| 아키텍처 | Arm64 |
| 실행 환경 사양 | 환경당 2 vCPU, 2 GB 메모리 |
| 기본 진입 파일 | 패키지 루트의 index.js |
| 진입 파일 변경 | AWS_LAMBDA_NODEJS_ENTRYPOINT 환경 변수 |
| 배포 패키지 | .zip, 최대 512 MB |
| 런타임 패치 | 자동 패치. 특정 패치 버전 고정(runtime management controls)은 지원하지 않음 |
Next.js standalone 모드처럼 자체 환경 변수로 리슨 주소를 읽는 프레임워크는, AWS_LAMBDA_HTTP_ENDPOINT 값을 해당 변수로 옮겨 주는 작은 index.js를 진입점으로 두면 됩니다.
3.3 요청이 서버에 도달하는 방식
- 엔드포인트는 HTTPS(443)만 받습니다. 평문 HTTP는 제공하지 않습니다.
- TLS는 Lambda 엔드포인트에서 종료되고, 실행 환경 안의 서버에는 평문 HTTP로 전달됩니다. 애플리케이션에서 인증서를 다룰 필요가 없습니다.
- Lambda는 모든 요청에
lambda-web-request-id헤더를 붙여 전달하고, 응답 헤더로도 같은 값을 돌려줍니다. 클라이언트 요청과 애플리케이션 로그를 연결할 때 유용합니다. - 서버는 시작 후 10초 이내에 listen을 시작해야 합니다.
- 요청 하나의 타임아웃은 리비전의
timeoutSeconds로 설정하며, **3~900초(기본 30초)**입니다.
4. 리소스 모델
Web Functions는 세 가지 리소스가 부모-자식 계층을 이룹니다.
[그림 2] Web Function, Revision, Endpoint의 관계
| 리소스 | 설명 |
|---|---|
| Web Function | 최상위 리소스. 이름, ARN, 자체 수명주기 상태(Pending/Active/Failed/Deleting)를 가짐 |
| Revision | 코드와 설정의 불변(immutable) 스냅샷. 코드나 리비전 설정(타임아웃, 환경당 최대 동시성, 환경 변수 등)을 바꿀 때마다 새로 생성됨 |
| Endpoint | HTTP 트래픽 진입점. 고유한 TLS 도메인, 인증 방식, 스케일링 설정, 리비전으로의 라우팅 규칙을 가짐. Web Function당 최대 10개 |
리비전이 불변이기 때문에, 이전 리비전으로 트래픽을 다시 돌리는 것만으로 롤백할 수 있습니다. 엔드포인트 하나는 최대 두 개의 리비전에 트래픽을 나눠 보낼 수 있어서 카나리·블루그린 배포가 가능합니다.
수명주기 상태에서 주의할 점
리비전과 엔드포인트는 각각 Pending → Active(또는 Failed) 상태를 독립적으로 거칩니다. 공식 문서는 다음 사항을 분명히 경고합니다.
Lambda는 리비전을 만들거나 엔드포인트를 업데이트할 때 서버가 실제로 listen하는지 확인하지 않습니다. 리비전과 엔드포인트가
Active여도 요청이 실패할 수 있으므로, 배포 후에는 반드시 테스트 요청을 보내고 애플리케이션 로그를 확인해야 합니다.
5. 엔드포인트 유형
엔드포인트 유형은 생성 시에 정하며 이후 변경할 수 없습니다. 리전 목록도 마찬가지입니다. 바꾸려면 새 엔드포인트를 만들고 트래픽을 옮긴 뒤 기존 엔드포인트를 삭제해야 합니다.
[그림 3] 엔드포인트 유형별 트래픽 라우팅
| 유형 | 동작 | 도메인 형식 |
|---|---|---|
| HomeRegion | 단일 리전에서 실행. 가장 단순한 구성 | {domain-id}.{shard-id}.lambda-web.{region}.on.aws |
| MultiRegion | 여러 리전에서 실행, 글로벌 도메인 하나로 지연 시간 기반 라우팅(best-effort). 헬스 기반 장애 조치(failover)는 하지 않음 | {domain-id}.lambda-web.global.on.aws |
| PerRegion | 여러 리전에서 실행, 리전별 도메인을 따로 발급. 라우팅은 사용자가 직접 관리(Route 53, CloudFront 등) | 리전별로 {domain-id}.{shard-id}.lambda-web.{region}.on.aws |
MultiRegion과 PerRegion에서는 홈 리전이 자동으로 포함되며, 최소 한 개의 다른 리전을 지정해야 합니다. Lambda가 코드와 리비전 설정(환경 변수 포함)을 각 리전에 복제하고, 로그는 홈 리전에 모입니다.
AWS Compute 블로그 필자는 영국에서 측정했을 때 eu-west-2까지 16ms, us-east-1까지 90ms가 나왔다고 소개했습니다(단일 측정값이며 벤치마크는 아니라고 명시).
커스텀 도메인: 엔드포인트에 커스텀 도메인을 직접 연결할 수는 없습니다. 자체 도메인으로 서비스하려면 엔드포인트 앞에 Amazon CloudFront를 두고 Lambda가 할당한 도메인을 오리진으로 사용합니다.
6. 동시성과 스케일링
6.1 Event Functions와의 차이
Event Functions는 실행 환경 하나가 한 번에 요청 하나만 처리합니다. AWS Compute 블로그의 예시를 보면, 열린 스트림 200개를 처리하려면 최대 200개의 환경이 필요할 수 있습니다. 또한 호출과 호출 사이에 환경이 동결(freeze)되기 때문에 백그라운드 작업도 멈춥니다.
Web Functions는 환경 하나가 여러 요청을 동시에 처리합니다. 같은 블로그의 부하 테스트(스트리밍 요청 300개, 최대 200개 동시 연결)에서는 다음과 같은 결과가 나왔습니다.
- 사용한 환경 수: 5개
- 처리한 요청: 484건
- 환경 하나의 최대 동시 요청: 59 (기본 한도 64에 근접)
- 소비한 CPU 시간: 총 4.75초
[그림 4] Event Functions와 Web Functions의 동시 요청 처리 방식
6.2 스케일링 설정 3가지
| 설정 | 위치 | 범위 | 기본값 | 의미 |
|---|---|---|---|---|
maxConcurrencyPerEnvironment |
리비전 | 1–128 | 64 | 환경 하나가 동시에 처리할 최대 요청 수(동적 한도의 상한) |
maxEnvironments |
엔드포인트 | 2–10,000 (선택) | 없음 | 리전별 최대 실행 환경 수 |
rateLimit |
엔드포인트 | 0–10,000 RPS (선택) | 없음 | 리전별 초당 요청 수 상한. 0이면 모든 트래픽 차단 |
Lambda는 실제 리소스 사용량을 보고 환경별 동적 동시성 한도를 자동으로 조절합니다. 이 값은 maxConcurrencyPerEnvironment를 넘지 않습니다. 새 Web Function은 보수적인 값에서 시작하며, 학습한 값은 0으로 스케일된 뒤에도 기억합니다. 그래서 공식 문서는 부하 테스트를 여러 번 돌리고 이후 회차의 결과를 기준으로 삼으라고 권장합니다.
6.3 계정 할당량 (리전별)
- 엔드포인트당 요청률: 10,000 RPS
- 계정 전체 요청률: 100,000 RPS
- 계정 vCPU: 2,000 vCPU (환경당 2 vCPU이므로 리전당 환경 약 1,000개)
6.4 용량 계산 예시 (공식 문서)
maxEnvironments=10, maxConcurrencyPerEnvironment=64, rateLimit=8000이라고 가정해 보겠습니다.
- 최대 동시 처리량은 약 640개(10 × 64)입니다.
- 요청당 200ms라면 초당 최대 약 3,200건(640 ÷ 0.2)을 처리하므로 동시성이 먼저 한계에 도달합니다. 이때는
maxEnvironments를 늘려야 합니다. - 요청당 10ms라면 8,000 RPS에서 동시 요청은 약 80개뿐이므로 요청률이 먼저 한계에 도달합니다. 이때는
rateLimit을 늘려야 합니다.
6.5 스로틀링
- 한도를 넘는 요청은 HTTP 429를 받으며 대기열에 쌓이지 않습니다. (단, 새 환경이 초기화 중일 때는 대기합니다.)
rateLimit=0이면Platform.EndpointDisabled헤더와 함께 HTTP 503을 반환합니다.- 클라이언트는 지수 백오프와 지터(jitter)를 적용해 재시도해야 합니다.
6.6 콜드 스타트
- 최소 환경이나 예약 환경을 지정하는 설정은 없습니다. 엔드포인트는 항상 0에서부터 스케일합니다.
- 대신 Lambda가 수요보다 앞서 여유 용량(headroom)을 미리 확보해 두기 때문에, 완만한 트래픽 증가에서는 콜드 스타트가 거의 발생하지 않습니다.
- 0에서 첫 요청이 들어오거나 트래픽이 headroom보다 빠르게 급증하면 콜드 스타트가 발생합니다.
7. 실행 환경 수명주기
[그림 5] 실행 환경 수명주기 (Initialization → Ready → Shutdown)
| 단계 | 내용 |
|---|---|
| Initialization | 코드 로드, 런타임 준비, 서버 프로세스 시작. 10초 안에 listen을 시작해야 함 |
| Ready | maxConcurrencyPerEnvironment 범위 안에서 요청을 받음 |
| Shutdown | 새 요청 라우팅 중단 → 진행 중인 요청 완료 대기(best-effort) → SIGTERM 전송 → 최대 1초 정리 후 종료 |
process.on('SIGTERM', () => {
// 1초 안에 끝나는 짧은 정리 작업(버퍼된 로그 flush 등)만 수행
process.exit(0);
});
환경 재사용의 의미
- 전역 변수, 캐시, 커넥션 풀이 요청 사이에 유지됩니다.
/tmp에 쓴 파일도 환경이 제거될 때까지 남아 있습니다.- 하지만 수명은 보장되지 않으므로 중요한 데이터는 DynamoDB나 S3 같은 외부 저장소에 보관해야 합니다.
- 응답을 보낸 뒤에도 환경이 살아 있으므로, 텔레메트리 전송 같은 백그라운드 작업을 요청 경로 밖에서 실행할 수 있습니다.
8. 동시성 코드 작성 시 주의할 점
환경 하나에서 여러 요청이 같은 프로세스와 이벤트 루프를 공유합니다. 기존 Lambda에서는 신경 쓰지 않아도 됐던 부분입니다.
- 요청별 상태를 전역 변수에 저장하지 않습니다. Express의
req/res처럼 요청 범위 컨텍스트를 사용합니다. await를 사이에 둔 읽기-수정-쓰기를 조심합니다. 비동기 작업 도중 다른 요청이 같은 상태를 읽거나 바꿀 수 있습니다.- 이벤트 루프를 막지 않습니다. 큰 JSON 파싱, 복잡한 계산, 동기 파일 읽기는 같은 환경의 모든 요청을 멈추게 합니다.
worker_threads로 넘기거나maxConcurrencyPerEnvironment를 낮춥니다. - 메모리 예산을 고려합니다. 환경 메모리는 2 GB이고 V8 기본 힙은 1,024 MB입니다. 힙을 늘리려면
NODE_OPTIONS=--max-old-space-size=1536처럼 설정합니다. 힙, 버퍼, 네이티브 할당, 런타임, 동시 요청이 모두 2 GB 안에 들어가야 합니다. - 무거운 초기화는 listen 이후로 미룹니다. listen하는 순간부터 요청이 들어오므로, 초기화 결과에 의존하는 핸들러는 공유 Promise를 await하게 만듭니다.
워크로드 유형별 maxConcurrencyPerEnvironment 가이드 (공식 문서)
- I/O 바운드: 기본값보다 높이면 환경 활용률이 올라가고 비용이 줄어들 수 있습니다.
- CPU 바운드: 낮추면 CPU 경합이 줄고 웜 상태 지연 시간이 개선되지만, 콜드 스타트가 잦아질 수 있습니다.
- 메모리 바운드: 낮추면 동작이 더 예측 가능해집니다.
9. 배포하기
9.1 가장 빠른 시작
# 샘플 앱 생성 + 배포
aws lambda-web deploy --name my-web-app --hello-world
# 내 앱 배포 (같은 이름으로 다시 실행하면 새 리비전으로 업데이트)
aws lambda-web deploy --name my-web-app --code ./my-web-app
AWS News 블로그에 따르면 첫 배포는 1분 이내에 실제 동작하는 HTTPS URL을 반환하고, 재배포는 몇 초면 끝납니다. 첫 배포 때 deploy 명령은 다음 작업을 수행합니다.
- 버전 관리가 켜진 S3 버킷을 생성하거나 재사용 (배포 패키지 저장용)
- CloudWatch Logs 권한이 있는 IAM 실행 역할을 생성하거나 재사용
- Web Function과 첫 리비전 생성
dev라는 이름의HomeRegion엔드포인트 생성 (LatestRevision모드)
참고:
aws lambda-web명령이 인식되지 않으면 AWS CLI v2를 최신 버전으로 업데이트해야 합니다(aws lambda-web help로 확인). CI/CD에서는 확인 프롬프트를 건너뛰도록--create를 붙입니다. 기본 엔드포인트는 인증 없는 공개 엔드포인트이므로, 접근을 제한하려면--auth-type IamAuth를 추가하세요.
9.2 멀티 리전 배포
aws lambda-web deploy --name my-web-app --code ./my-app \
--regions us-east-1,eu-west-1,ap-northeast-1
9.3 API 명령으로 단계별 제어
deploy 대신 create-web-function, create-web-function-revision, update-web-function-endpoint 같은 API 대응 명령을 직접 사용할 수도 있습니다. 이때 알아 둘 점이 있습니다. 새 리비전은 이전 리비전의 설정을 복사하지 않습니다. 생략한 설정은 기본값(예: 타임아웃 30초, 환경 변수 없음)으로 돌아가므로 매번 전체 설정을 넘겨야 합니다.
9.4 정리(Clean up)
aws lambda-web delete-web-function --function-name my-web-app
이 명령은 엔드포인트와 리비전도 함께 삭제합니다. 하지만 deploy가 만든 IAM 역할, S3 배포 패키지, CloudWatch 로그 그룹은 남아 있으므로 필요 없으면 따로 삭제해야 합니다.
10. 카나리, 블루그린 배포와 롤백
엔드포인트의 autoDeploymentMode에 따라 배포 방식이 달라집니다.
| 모드 | 동작 | 용도 |
|---|---|---|
LatestRevision |
새 리비전이 Active가 되면 트래픽 100%를 자동 전환. HomeRegion만 지원 | 개발/스테이징 |
Disabled |
리비전 가중치(revisionWeights)로 직접 제어. API 기본값이며, MultiRegion/PerRegion은 항상 이 모드 |
프로덕션 |
리비전 가중치 규칙: 각 가중치는 1~100 사이의 정수이고, 합은 정확히 100이어야 합니다. 리비전은 최대 2개까지, 모두 Active 상태여야 합니다.
[그림 6] 카나리 배포 흐름과 롤백 경로
# 카나리: 기존 90% / 새 리비전 10%
aws lambda-web update-web-function-endpoint \
--function-name my-web-app \
--endpoint-name prod \
--auto-deployment-mode Disabled \
--revision-weights '[{"revisionId":"rev-abc12","weight":90},{"revisionId":"rev-def45","weight":10}]'
# 업데이트 완료 대기
aws lambda-web wait web-function-endpoint-updated \
--function-name my-web-app --endpoint-name prod
# 롤백: 정상 리비전으로 100%
aws lambda-web update-web-function-endpoint \
--function-name my-web-app \
--endpoint-name prod \
--auto-deployment-mode Disabled \
--revision-weights '[{"revisionId":"rev-abc12","weight":100}]'
실무 팁
- 가중치 변경은 비동기로 처리됩니다.
updateStatus가Successful이 된 뒤에 평가하거나 다음 변경을 진행하세요. - Web Function 메트릭에는 리비전 차원(dimension)이 없습니다. 카나리 오류를 구분하려면 애플리케이션 로그나 커스텀 메트릭에 직접 관리하는 빌드/리비전 ID를 넣어야 합니다.
- 프로덕션 트래픽 없이 검증하고 싶다면 별도의 테스트 엔드포인트를 만들어 새 리비전을 붙여 보세요.
- 트래픽을 받고 있는 리비전은 삭제할 수 없습니다(conflict 오류).
11. 보안과 접근 제어
11.1 두 가지 인증 방식
| 인증 방식 | 동작 |
|---|---|
| ApplicationManaged | Lambda가 인증하지 않음. 모든 요청이 앱으로 전달되고 앱이 OAuth, JWT, 세션 쿠키, Amazon Cognito 등으로 직접 처리. 리소스 기반 정책으로 호출자를 제한할 수 없음 |
| IamAuth | Lambda가 요청 서명을 검증. HomeRegion/PerRegion은 SigV4, MultiRegion은 SigV4a. 호출자에게 lambda:InvokeWebFunctionEndpoint 권한이 필요 |
인증 방식은 재배포 없이 엔드포인트 업데이트만으로 바꿀 수 있습니다.
IamAuth로 직접 서명할 때 주의할 점은 다음과 같습니다.
- 본문이 없더라도 모든 서명 요청에
X-Amz-Content-SHA256헤더가 있어야 합니다(없으면 403). - 스트리밍처럼 본문을 서명하지 않는 경우에는
UNSIGNED-PAYLOAD를 사용합니다.
11.2 CloudFront + OAC 패턴 (권장 구성)
[그림 7] CloudFront OAC를 사용한 Web Functions 아키텍처
- 엔드포인트를 IamAuth로 설정합니다.
- CloudFront에서 오리진 유형
lambda, 서명 동작always-amz-auth로 OAC를 만듭니다. - Web Function의 리소스 기반 정책에서
cloudfront.amazonaws.com에lambda:InvokeWebFunctionEndpoint를 허용하고,aws:SourceArn조건으로 내 배포(distribution)만 허용합니다.
이렇게 하면 정적 자산은 CloudFront 캐시에서, 동적 요청은 Web Function에서 처리됩니다. CloudFront는 Authorization 헤더를 서명에 사용하지 않기 때문에, JWT나 쿠키 같은 앱 자체 인증도 그대로 유지할 수 있습니다.
⚠️ 엔드포인트가 ApplicationManaged라면 CloudFront 뒤에 두더라도 자체 도메인으로 여전히 공개 접근이 가능합니다. 오리진을 보호하려면 반드시 IamAuth를 사용하세요.
11.3 조직 차원의 거버넌스
AWS Organizations 관리자는 SCP에서 lambda:Request/WebFunctionAuthType 조건 키를 사용해 ApplicationManaged(공개) 엔드포인트 생성을 막을 수 있습니다. 이 정책이 적용되면 aws lambda-web deploy는 --auth-type IamAuth를 붙이지 않는 한 실패합니다.
12. 모니터링
- 런타임은 1분마다 환경별로
platform.invokeSummary레코드를 CloudWatch Logs의/aws/lambda/web/<function-name>에 기록합니다. 인스턴스 ID, 요청 수, 최대 동시성, CPU 시간이 담겨 있으며 CloudWatch Logs Insights로 전체 플릿을 집계할 수 있습니다. - 스케일링 설정을 점검할 때 볼 주요 메트릭은 다음과 같습니다.
EndpointRequestThrottles/AccountRequestThrottles→rateLimit또는 계정 할당량 조정EndpointActiveEnvironmentThrottles/AccountActiveVCPUArm64Throttles→maxEnvironments또는 vCPU 할당량 조정EndpointActiveEnvironments/EnvironmentConcurrentRequests→ 한도에 가까워지면 설정 상향
13. 요금
13.1 과금 항목
| 항목 | 설명 |
|---|---|
| 요청 수 | 모든 출처에서 들어온 요청의 총합 |
| 활성 CPU 시간 | 코드가 실제로 CPU를 사용한 시간, 1ms 단위. I/O 대기는 청구되지 않음 |
| 메모리 | 실행 환경이 살아 있는 동안 소비한 메모리(요청 사이 유휴 시간 포함) |
| 데이터 전송 | 표준 AWS 데이터 전송 요금 + 같은 리전 내 Web Functions↔VPC 간 트래픽 |
단가 (미국 동부 버지니아 북부, Arm 기준)
- 활성 vCPU: $0.0000276944 / vCPU-초
- 메모리: $0.0000036667 / GB-초
- 요청: 100만 건당 $0.30
13.2 공식 요금 예시 (30일, 환경 1개가 전체 트래픽 처리, 프리 티어와 데이터 전송 제외)
| 워크로드 | 월 요청 | 지속 시간 / 활성 CPU | 메모리 | 월 합계 |
|---|---|---|---|---|
| SSR 웹 앱 | 1,500만 | 150ms / 40ms | 0.49 GB | $25.78 |
| I/O 위주 API 백엔드 | 1,000만 | 200ms / 50ms | 0.29 GB | $19.61 |
| 인가(Authorization) 미들웨어 | 1억 | 50ms / 12ms | 0.14 GB | $64.56 |
| LLM 스트리밍 엔드포인트 | 500만 | 3,000ms / 200ms | 0.50 GB | $33.94 |
LLM 스트리밍 예시에서는 요청 하나가 3초 동안 이어지지만 실제 CPU 사용은 200ms뿐이므로, CPU 요금은 이 200ms에 대해서만 청구됩니다. 또 약 6개의 동시 요청이 환경 하나를 공유하므로, 메모리 요금도 환경 1개 분량만 낸다고 공식 페이지는 설명합니다.
14. Web Functions와 Event Functions 선택 기준
Web Functions가 잘 맞는 경우
- Express/Fastify/Hono/Next.js 등으로 만든 Node.js 웹 앱, SSR, REST/GraphQL API
- DB나 외부 API를 많이 기다리는 I/O 위주 백엔드
- SSE나 chunked 응답으로 토큰을 흘려보내는 LLM 게이트웨이/스트리밍 API
- 전 세계 사용자를 대상으로 하는 멀티 리전 저지연 서비스
- CloudFront 뒤의 동적 오리진
Event Functions가 맞는 경우
- SQS 배치, S3 객체 이벤트처럼 이벤트 소스가 트리거하는 작업 (AWS Compute 블로그도 이 경우에는 Event Functions를 권장)
- Node.js 외의 런타임이 필요한 경우 (Web Functions는 현재
nodejs24.x만 지원)
15. 출시 시점 제약 사항
- 런타임: Node.js 24(
nodejs24.x), Arm64만 지원 - 리전(출시 시점): 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오리건), 아시아 태평양(도쿄), 유럽(아일랜드). 서울 리전은 출시 리전 목록에 없습니다.
- 실행 환경: 2 vCPU / 2 GB로 고정
- 요청 타임아웃: 최대 900초
- 커스텀 도메인 직접 연결 불가 → CloudFront 사용
- 엔드포인트 유형과 리전은 생성 후 변경 불가
- MultiRegion은 헬스 기반 장애 조치 없음
- 최소/예약 환경 설정 없음 (항상 0부터 스케일)
- 런타임 패치 버전 고정 불가
- 메트릭에 리비전 차원 없음
16. 마치며
Lambda Web Functions를 쓰면 Node.js 서버 코드를 핸들러 형태로 바꾸지 않고도 Lambda에 올릴 수 있습니다. 여기에 더해 다음과 같은 이점이 있습니다.
- 다중 동시성: 콜드 스타트와 환경 수를 줄여 줍니다.
- 활성 CPU 과금: I/O 대기 비용을 줄여 줍니다.
- 스트리밍, 멀티 리전, CloudFront 연동을 지원합니다.
반면 하나의 프로세스를 여러 요청이 공유하므로, 동시성 문제가 생기지 않게 코드를 짜는 일은 개발자가 챙겨야 합니다. 출시 리전과 런타임 제약도 아직 있습니다. 새로운 Node.js 웹 서비스를 계획 중이거나, API Gateway + Lambda 구성에서 I/O 대기 비용이 부담된다면 한 번 검토해 볼 만한 선택지입니다.
참고 자료 (AWS 공식 출처)
AWS 공식 블로그
- Announcing AWS Lambda Web Functions — AWS News Blog (2026-10-12)
- Exploring AWS Lambda Web Functions for building web applications — AWS Compute Blog (2026-10-13)
- AWS Weekly Roundup (2026-10-19)
AWS 공식 문서 / 제품 페이지
- AWS Lambda Web Functions 제품 페이지
- AWS Lambda 요금
- What's New: AWS Lambda announces Lambda Web Functions
- What's New: Amazon CloudFront now supports AWS Lambda Web Functions as an origin
- Core concepts
- Creating a Lambda Web Function
- Lambda Web Function runtimes
- Lambda Web Function endpoints
- Scaling behavior for Lambda Web Functions
- Execution environment lifecycle
- Deployment patterns
- Endpoint access control
'AWS 서버리스' 카테고리의 다른 글
| Serverless Framework v3와 v4의 차이점 및 기존 프로젝트 마이그레이션 가이드 (0) | 2026.11.07 |
|---|---|
| AWS Lambda Python 로깅 시스템 분석: 중복 로그와 Request ID를 해결하는 방법 (0) | 2026.11.03 |
| ASGI 애플리케이션을 서버리스 환경에서 실행하는 원리와 구현 방법 (0) | 2026.10.30 |
| AWS Lambda와 API Gateway로 서버리스 Discord 봇 구축하기 (0) | 2026.10.29 |