Lambda Web Functions, API 응답을 기다릴 때도 과금될까?

API 응답을 기다려도 메모리 비용은 남는다

Lambda Web Functions에서 외부 API를 기다리는 시간이 곧 무료 시간은 아니다. AWS 문서는 활성 CPU 시간과 실행 환경의 생존 기간에 걸친 메모리 사용을 따로 계량한다고 설명한다. 요청 수와 데이터 전송도 과금 대상이다.

데이터베이스나 AI 모델의 응답을 기다리는 요청은 CPU를 적게 쓴다. 그러나 요청이 끝난 뒤 다음 요청을 기다리는 사이에도 환경이 유지되면 메모리 비용은 이어진다. CPU 사용 시간만 줄었다고 전체 비용이 같은 비율로 줄었다고 계산해서는 안 된다.

기존 이벤트 함수와 HTTP 서버가 나란히 존재한다

AWS가 10월 12일 발표한 Web Functions는 포트에서 요청을 받는 HTTP 서버를 Lambda에서 실행하는 방식이다. Express·Hono·Fastify 같은 Node.js 프레임워크를 이벤트 핸들러로 다시 작성하지 않고 사용할 수 있다.

기존 Lambda 함수에는 Event Functions라는 이름이 붙었다. 이벤트를 받아 처리하는 모델과 경과 시간 기준 과금은 별도로 남는다. 큐 소비나 AWS 서비스가 발생시킨 이벤트 처리는 Event Functions, HTTP API·웹 페이지 응답은 Web Functions처럼 용도에 맞게 나눌 수 있다.

Web Functions의 한 환경은 여러 요청을 함께 처리한다. 동시성 설정의 기본 상한은 64이며 1부터 128까지 지정한다. 실제 한도는 자원 사용량 등에 따라 더 낮아질 수 있으므로, 128이라는 숫자를 보장 처리량으로 받아들여서는 안 된다.

익숙한 서버 코드에도 포트와 공유 상태 조건이 있다

현재 지원 런타임은 Node.js 24다. 서버는 Lambda가 제공하는 AWS_LAMBDA_HTTP_ENDPOINT의 호스트와 포트에서 요청을 받아야 한다. 로컬에서 쓰던 주소를 고정해 두면 Lambda가 앱에 요청을 전달하지 못한다.

패치 버전도 앱이 고정하는 방식이 아니다. Web Functions는 지정한 메이저 런타임의 최신 패치를 자동 적용하며, 자동 패치를 끄거나 특정 패치에 고정하는 런타임 관리 옵션을 제공하지 않는다.

실행 환경 문서에 따르면 전역 변수·캐시·연결은 요청 사이에 남고, 여러 요청이 같은 프로세스를 사용한다. 연결 풀을 재사용할 수 있지만 고객별 데이터나 요청별 인증값은 요청 범위에 둬야 한다. 비동기 처리 도중 공유 변수를 읽고 수정하는 코드도 다른 요청과 섞일 수 있다.

Active 표시 뒤에도 요청을 보내야 한다

리비전이나 엔드포인트의 Active 상태는 서버가 정상적으로 시작했다는 뜻이 아니다. AWS는 엔드포인트 생성·갱신 시 서버의 수신 여부를 검사하지 않는다고 명시한다. 배포 뒤 실제 요청을 보내고 앱 로그를 봐야 한다.

운영 권고는 실제 의존 서비스와 연결한 부하 시험으로 지연·CPU·메모리·후단 용량을 확인하도록 안내한다. 네이티브 모듈은 실행 환경에 맞는 Arm64로 빌드해야 한다. 여러 리전을 쓰면 각 리전의 갱신 상태도 따로 확인한다.

도입 판단에는 활성 CPU 사용량뿐 아니라 환경 유지 시간과 요청 동시성도 필요하다. 기존 서버의 요청별 상태를 정리하고, 같은 부하에서 자원 사용과 응답 지연을 측정해야 새 실행 모델의 이득을 판단할 수 있다.

자주 묻는 질문