Amazon Web Services 한국 블로그
AWS Lambda Web Functions 정식 출시
오늘 AWS는 코드를 이벤트 핸들러로 다시 작성하지 않고도 Lambda에서 표준 HTTP 웹 애플리케이션을 실행할 수 있는 새로운 폼 팩터인 AWS Lambda Web Functions를 발표합니다. Express, Hono, Fastify, Next.js 등의 Node.js 프레임워크로 구축한 표준 포트 리스닝 서버를 단일 명령으로 배포할 수 있으며, Lambda가 자동으로 확장, 다중 리전 배포 및 활성 CPU 사용량 기반 청구를 처리합니다. 어댑터도, 관리할 인프라도, 특정 프레임워크에 종속될 걱정도 없습니다.
이번 출시와 함께, AWS Lambda는 이제 동일한 Firecracker 격리 기술을 기반으로 구축되고 서로 다른 프로그래밍 모델용으로 설계된 세 가지 폼 팩터를 제공합니다.
Lambda Event Functions는 기존에 알고 계신 Lambda 함수입니다. 이벤트 중심의 단일 동시 핸들러 모델을 사용하며 실제 경과 시간을 기준으로 요금이 부과됩니다. 이러한 프로그래밍 모델을 강조하기 위해 ‘Event Functions’라는 명칭을 붙였습니다. 함수가 이벤트를 받아 처리한 후 응답을 반환하기 때문이죠. 이벤트 기반 프로그래밍 모델은 다른 AWS 서비스에서 트리거되는 이벤트 처리, 대기열 소비자, 간접 호출에 적합합니다.
Lambda Web Functions는 HTTP 네이티브 프로그래밍 모델을 사용하며, 다중 동시 실행을 지원하고 활성 CPU 사용량을 기준으로 요금이 부과됩니다. 코드는 포트에서 요청을 수신하고 표준 HTTP 요청을 처리합니다. 이 프로그래밍 모델은 여러 개의 동시 요청과 I/O가 많은 처리 작업이 일반적으로 발생하는 웹 애플리케이션, API 백엔드 및 대화형 HTTP 워크로드에 적합합니다.
Lambda MicroVM은 신뢰할 수 없는 코드 또는 사용자가 생성한 코드를 실행하기 위한 고객 관리형 수명 주기를 지원하는 격리된 상태 저장 샌드박스 환경을 제공합니다.
이 세 가지는 서로를 보완합니다. 애플리케이션에서 비동기 백엔드 처리에는 Event Functions를, 사용자 대면 API 및 서버 측 렌더링 계층에는 Web Functions를, 대화형 코드 실행 기능에는 MicroVM을 사용할 수 있습니다. 세 가지 모두 동일한 AWS 계정 내에서 동일한 운영 모델을 공유합니다.
Web Functions를 사용하는 이유
현대적 웹 애플리케이션은 개발자가 표준 프레임워크를 자유롭게 사용하고 빠르게 반복할 수 있도록 하면서, 전 세계 사용자에게 일관되게 빠른 응답 시간을 제공해야 합니다. 오늘날 이를 구축하려면 일반적으로 여러 인프라 구성 요소를 조합하고, 다중 리전 배포를 구성하고, 지연 시간 기반 라우팅을 설정하고, I/O 대기에 따른 비용을 지불하지 않도록 청구 모델을 조정해야 합니다. 개발자는 이미 보유한 HTTP 서버를 배포하는 대신, 특정 컴퓨팅 모델에 맞게 애플리케이션 코드를 조정하는 경우가 많습니다.
Lambda Web Functions는 이러한 복잡성을 없앱니다. 각 실행 환경은 여러 요청을 동시에 처리합니다(환경당 최대 128건의 동시 요청 처리). 즉, 들어오는 트래픽이 급증하더라도 각 요청에 새 실행 환경을 할당하는 대신, 이미 준비된 실행 환경을 여러 요청이 공유합니다. Web Functions는 코드에 소요되는 CPU 시간을 측정하므로, 데이터베이스 쿼리 또는 API 직접 호출을 기다리는 데 걸리는 시간 동안 CPU를 거의 소비하지 않습니다. 메모리는 실행 환경이 존재하는 한 측정됩니다. 서버 측 렌더링, API 백엔드, AI 추론 엔드포인트 스트리밍 토큰 응답 등, I/O가 많은 웹 워크로드의 경우 이를 통해 컴퓨팅 비용을 줄일 수 있습니다.
직접 사용해 보기
시작하기 위해 간단한 Express.js 서버를 작성했습니다. Lambda 전용 어댑터나 래퍼 없이도 로컬에서 node index.js 명령으로 실행하는 것과 동일한 코드입니다.
import express from 'express';
const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');
app.get('/', (req, res) => {
res.json({ message: 'Hello from Lambda Web Functions!' });
});
app.listen(port, host, () => {
console.log(`Server running on port ${port}`);
});
로컬에서 실행할 때와의 유일한 차이점은 AWS_LAMBDA_HTTP_ENDPOINT 환경 변수입니다. Lambda는 서버가 수신 대기해야 하는 호스트와 포트를 이 변수에 설정합니다. 로컬에서 실행하려면 AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js와 같이 해당 변수를 직접 설정합니다.
코드가 준비되면 AWS Command Line Interface(AWS CLI)를 사용하여 배포합니다.
aws lambda-web deploy --name my-web-app --code ./my-app
명령을 하나만 실행하면 되고, 사전 리소스 설정은 필요 없습니다. CLI가 소스를 번들링하고, 웹 함수를 생성하고, 첫 번째 수정 버전을 게시하고, 웹 함수 엔드포인트를 연결한 다음, 1분 이내에 실제로 접속할 수 있는 HTTPS URL을 반환했습니다.
수정 버전은 제가 배포한 코드의 변경 불가능한 스냅샷입니다. 엔드포인트는 트래픽을 수정 버전으로 라우팅하거나 수정 버전 간에 트래픽을 분할하는 HTTPS URL입니다. 해당 리소스를 사용하여 코드를 반복적으로 개선하고 트래픽이 새 코드로 이동하는 방식을 제어합니다.
그리고 바로 테스트했습니다.
$ curl https://<domain-id>.<shard-id>.lambda-web.us-east-1.on.aws/
{"message":"Hello from Lambda Web Functions!"}
다음으로, 유럽과 아시아 사용자에게 짧은 지연 시간으로 서비스를 제공하고자 했습니다. 이를 위해 여러 리전에 재배포했습니다.
aws lambda-web deploy --name my-web-app --code ./my-app \
--regions us-east-1,eu-west-1,ap-northeast-1
Lambda Web Functions가 코드를 세 리전 모두에 복제하고 지연 시간 기반 라우팅을 자동으로 구성했습니다. 이제 각 요청은 가능한 한 하나의 글로벌 URL(<domain-id>.lambda-web.global.on.aws)을 통해 호출자에게 지연 시간이 가장 짧은 리전으로 라우팅됩니다.
코드를 업데이트하고 동일한 배포 명령을 다시 실행하자 CLI가 기존 함수를 감지하고 새 수정 버전을 업로드한 다음 엔드포인트가 새 수정 버전을 가리키도록 변경했습니다. 코드 변경부터 배포 완료까지 걸린 시간은 단 몇 초였습니다.
좀 더 점진적으로 배포해야 하는 프로덕션 워크플로에서는 단일 API 직접 호출로 수정 버전 간에 트래픽을 전환할 수 있습니다.
aws lambda-web update-web-function-endpoint \
--function-name my-web-app \
--endpoint-name dev \
--auto-deployment-mode Disabled \
--revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'
결과적으로, 엔드포인트 트래픽의 90%는 현재 수정 버전으로, 10%는 새 수정 버전으로 전송되므로 추가 도구 없이 카나리 배포를 수행할 수 있습니다.
Amazon CloudFront와 함께 사용하면 더욱 효과적
정적 콘텐츠와 동적 콘텐츠를 결합하는 애플리케이션의 경우 Web Functions를 Amazon CloudFront와 함께 사용하면 효과적입니다. 웹 함수 엔드포인트를 CloudFront 배포의 오리진으로 선택할 수 있습니다. 정적 자산은 캐시에서 제공되고 동적 요청은 웹 함수로 라우팅되므로, 정적 콘텐츠에는 CDN 성능을 활용하고 동적 콘텐츠에는 서버리스 컴퓨팅을 사용할 수 있습니다.
Web Functions는 CloudFront를 통해 프라이빗 오리진 환경을 개선합니다. 이번 출시에서는 대신 CloudFront 오리진 액세스 제어(OAC)를 웹 함수 엔드포인트에 연결합니다. CloudFront는 오리진에 대한 요청에 서명하고, 엔드포인트는 해당 배포에만 간접 호출을 허용합니다. 엔드포인트를 노출하거나 앱에 사용자 지정 인증을 추가하지 않고도 CloudFront가 Amazon Simple Storage Service(Amazon S3)에 이미 제공하고 있는 것과 동일한 프라이빗 오리진 패턴을 사용할 수 있습니다.
지금 사용 가능
AWS Lambda Web Functions는 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오리건), 아시아 태평양(도쿄) 및 유럽(아일랜드) 리전에서 사용할 수 있습니다. Web Functions는 출시 시점에 Arm64 기반 Node.js 24(nodejs24.x)를 실행하고 Amazon 가상 프라이빗 클라우드(VPC) 연결을 지원하므로, 함수가 VPC 내에 있는 리소스에 액세스할 수 있습니다.
단 1분 만에 첫 번째 Web Function을 배포하여 시작할 수 있습니다.
aws lambda-web deploy --name hello-world --hello-world
요금 세부 정보는 AWS Lambda 요금 페이지에서 확인하세요. 자세히 알아보려면 Lambda Web Functions 설명서를 참조하세요.