AWS Lambda의 4가지 실행 모델 – 구조와 선택 기준

Lambda로 서버리스 워크로드를 설계하다 보면 비슷한 고민을 반복해서 만나게 됩니다. 15분 한도를 넘는 장기 워크 플로우는 어떻게 처리할지, 호출 사이에 실행 환경이 멈추는 freeze(일시 정지) 동작이 상시 트래픽 서비스에 맞는지, 사용자나 AI가 생성한 코드를 어디서 안전하게 실행할지 같은 질문입니다. 지금까지는 이 답을 Lambda 외부에서 찾는 경우가 많았습니다. 워크 플로우는 AWS Step Functions로 옮기고, 상시 워크로드는 컨테이너로 다시 만들고, 코드 샌드박스(Code Sandbox)는 별도 인프라로 직접 구축하는 식이었습니다.

2026년 8월 현재 Lambda라는 이름 아래에는 서로 다른 실행 모델 4가지가 있습니다. 우리가 알던 호출당 실행 모델은 그중 하나인 Lambda Functions이고, 여기에 Lambda Managed Instances, Lambda Durable Functions, Lambda MicroVMs가 더해지면서 실행 한도는 15분에서 최대 1년까지 벌어졌습니다. 이 글에서는 실행 모델 4종의 구조 차이를 먼저 비교하고 이어서 기본 함수 내부의 설정 축과 한도를 AWS 공식 문서 기준으로 정리합니다. 마지막에는 워크로드 성격에 따라 어느 모델에서 시작할지 판단하는 기준을 제시합니다. 본문의 수치와 기본값은 2026년 8월 기준입니다.

실행 모델 4종 한눈에 보기

4가지 모델은 이름만 나란할 뿐 실행 단위와 격리 수준부터 다릅니다. 실행 단위, 최대 지속 시간, 격리, 상태 유지, 주 용도의 5가지 축으로 놓고 보면 차이가 분명해집니다.

표 1. Lambda 실행 모델 4종 비교 (2026년 8월 기준)

1. Lambda Functions – 이벤트 단발 처리

Lambda Functions는 우리가 알던 Lambda입니다. 이벤트가 도착하면 호출 단위로 실행되고 호출 사이에는 실행 환경이 freeze됩니다. 격리는 Firecracker가 담당합니다. Firecracker는 Lambda의 격리 계층을 맡아 온 경량 microVM 가상화 기술로, freeze된 환경이 다음 호출에 재사용되면 /tmp 디렉토리와 핸들러 밖 전역 변수 상태가 그대로 남아 있습니다. 초기화 코드에서 DB 커넥션을 만들어 두고 재사용하는 최적화가 성립하는 이유가 여기에 있습니다. 다만 실행 환경은 수 시간 주기로 교체되므로, 호출 간 상태 유지를 보장으로 가정해서는 안 됩니다.

Lambda Managed Instances는 코드를 고객 소유 Amazon EC2 인스턴스에서 실행하고 Lambda는 운영만 담당합니다. 실행 환경이 freeze되지 않고 계속 활성 상태로 남으며 한 환경 안에서 여러 호출이 동시에 실행됩니다. 상시 활성, 병렬 처리 워크로드가 대상입니다.

Lambda Durable Functions는 durable execution, 즉 체크포인트를 남기고 중단 지점부터 이어가는 실행 방식을 Lambda에 추가합니다. 체크포인트와 replay 메커니즘 덕분에 하나의 실행이 최대 1년까지 이어집니다. 다단계 워크 플로우와 AI 오케스트레이션이 주 용도입니다.

Lambda MicroVMs는 Firecracker를 프리미티브로 직접 노출합니다. 핸들러와 이벤트 모델 대신 MicroVM마다 부여되는 전용 HTTPS 엔드포인트에 직접 접속하는 방식이라 기존 Lambda와는 사고방식 자체가 다릅니다. 사용자나 AI가 생성한 코드를 VM 수준으로 격리하는 샌드박스가 주 용도입니다.

모델 선택의 출발점은 워크로드 성격입니다. 이벤트 단발 처리라면 기본 Functions에서 시작하고, 상시 병렬 처리, 장기 워크 플로우, 코드 샌드박스에 해당할 때만 나머지 모델을 검토합니다.

그림 1. 워크로드 성격에 따른 실행 모델 선택 분기. 이벤트 단발이면 기본 Functions에서 시작하고, 상시 병렬 처리, 장기 워크 플로우, 코드 샌드박스일 때만 나머지 모델로 넘어갑니다.

4가지 모델이 완전히 배타적인 것은 아닙니다. AWS 문서에서는 Durable Functions를 checkpoint와 replay 메커니즘을 쓰는 일반 Lambda 함수(regular Lambda functions)로 설명합니다. 별도 인프라 없이 기본 Functions 위에서 동작하는 실행 모드라는 뜻입니다. 반면 Managed Instances나 MicroVMs와 Durable Functions를 조합할 수 있는지는 작성 시점의 공식 문서에 언급이 없어, 이 글에서는 단정하지 않습니다.

2. Lambda Managed Instances – freeze 없는 실행 환경

Managed Instances는 코드를 고객 소유 EC2 인스턴스에서 실행하고 운영은 Lambda가 맡는 모델입니다. 같은 함수 코드를 올려도 실행 환경의 동작이 기본 Lambda와 근본적으로 다르기 때문에, 이 차이를 모른 채 기존 함수를 그대로 옮기면 예상치 못한 부작용을 만나게 됩니다.

한 환경이 여러 호출을 동시에 처리합니다

기본 Lambda는 호출이 끝나면 실행 환경을 freeze하지만 Managed Instances의 실행 환경은 freeze 없이 계속 활성 상태로 남습니다. 호출 사이에도 실행 환경이 멈추지 않고 계속 동작한다는 뜻입니다.

호출 처리 방식도 다릅니다. 한 실행 환경 안에서 여러 호출이 런타임 워커별로 동시에 실행됩니다. 실행 환경 1개가 동시 호출 1건을 처리한다는 기본 Lambda의 등식이 여기서는 성립하지 않습니다.

주의: 호출 사이의 격리가 사라집니다

기본 Lambda에서는 실행 환경 1개가 동시 호출 1건만 처리하고 환경 자체가 Firecracker microVM으로 격리됩니다. 반면 Managed Instances에서는 동시 호출들이 같은 컨테이너의 프로세스 공간을 런타임 워커 단위로 나눠 씁니다. 전역 변수 오염, 스레드 안전성, 한 호출의 메모리 누수가 다른 호출로 번지는 문제가 마이그레이션 시 새로 검토해야 하는 항목이 됩니다. AWS 문서에서도 스레드 안전성, 상태 관리, 컨텍스트 격리를 이 실행 모델에서는 다르게 다뤄야 한다고 명시합니다.

타임아웃은 호출별로 독립 적용됩니다. 한 호출이 타임아웃되어도 같은 환경의 다른 호출은 영향 없이 계속 실행됩니다.

주의: 타임아웃이 발생해도 코드는 종료되지 않습니다

Managed Instances에서 호출이 타임아웃되면 Lambda는 호출자에게 에러를 반환하지만, 코드는 강제 종료되지 않고 백그라운드에서 계속 실행됩니다. 코드에서 context의 잔여 시간을 직접 확인해 중단하지 않으면, 이미 실패로 처리된 호출이 뒤늦게 완료되어 중복 쓰기나 중복 알림 같은 부작용을 만듭니다. 기본 Lambda 함수를 마이그레이션할 때 반드시 인지해야 하는 차이입니다.

backpressure와 컨테이너 폐기 정책

과부하 상황의 동작도 다릅니다. Managed Instances는 backpressure, 즉 처리 용량을 넘는 요청을 쌓아 두는 대신 앞단에서 거부하는 방식을 씁니다. 런타임 워커가 전부 바쁘면 신규 요청은 거부됩니다.

에러 처리 정책은 단순합니다. 실행 환경에 에러가 나면 Lambda는 리셋이나 복구를 시도하지 않고 컨테이너를 폐기한 뒤 새것으로 교체합니다. 실행 환경 안에 상태를 오래 쌓아 두는 설계에는 이 폐기 정책이 그대로 제약이 됩니다.

한도, 스케일링, 과금

한도 몇 가지는 기본 Lambda보다 넉넉합니다. 초기화는 최대 15분까지 허용되고 파일 디스크립터 한도는 4,096개로 기본 Lambda의 1,024개보다 큽니다. 실행 환경 OS는 Bottlerocket 기반입니다. 리전 제공 범위는 서울을 포함한 모든 상용 리전이며, 텔아비브, 바레인, UAE, 오클랜드 4곳만 예외입니다.

스케일링은 최소와 최대 실행 환경 설정 안에서 리소스 사용 신호에 따라 자동으로 이루어집니다. 다만 자동 scale-to-zero는 없습니다. 트래픽이 없어도 설정된 최소 실행 환경(기본 3개)까지만 줄어듭니다. 최소와 최대를 모두 0으로 지정하면 함수가 비활성화되고 기반 인스턴스가 종료되는데, 이후 트래픽이 와도 자동으로 복귀하지 않으므로 0이 아닌 값으로 다시 설정해야 합니다. 2026년 5월 12일부터는 Amazon EventBridge Scheduler로 일회성 또는 반복 일정을 정의해 용량 한도를 사전에 조정하는 스케줄 기반 스케일링도 쓸 수 있습니다.

과금 구조 역시 기본 Lambda와 다릅니다. 요청 100만 건당 USD 0.20의 요청 요금에, 프로비저닝된 EC2 인스턴스 요금과 EC2 온디맨드 가격의 15%에 해당하는 관리 수수료가 더해집니다. 호출별 실행 시간 과금은 없는 대신, 표 1의 인스턴스 상주가 뜻하는 대로 트래픽이 없어도 인스턴스가 떠 있는 동안에는 계속 과금됩니다. EC2 Savings Plans와 예약 인스턴스 할인은 기반 EC2 요금에만 적용되고 관리 수수료에는 적용되지 않습니다.

3. Lambda Durable Functions – 최대 1년짜리 워크 플로우

Durable Functions는 실행 도중 체크포인트를 남기고, 중단되면 그 지점부터 이어가는 durable execution을 Lambda 함수 안에 구현한 모델입니다. 이 메커니즘 덕분에 하나의 실행이 15분 한도를 넘어 최대 1년까지 이어집니다.

step과 wait, 그리고 replay

개발자가 쓰는 프리미티브는 2개입니다. step은 재시도와 진행 추적이 내장된 비즈니스 로직 단위이고 wait는 과금 없이 실행을 중단해 두는 대기입니다. 긴 승인 대기나 외부 이벤트 대기를 wait로 처리하면 그 시간에는 요금이 발생하지 않습니다.

실행이 재개되면 코드는 처음부터 다시 실행됩니다. 다만 이미 완료된 step은 저장된 체크포인트 결과로 건너뛰는데, 이 재실행 방식을 replay라고 부릅니다.

참고: replay가 요구하는 결정론

replay는 같은 코드를 다시 실행하면 같은 경로를 지나간다는 전제 위에 서 있습니다. 따라서 함수는 결정론적이어야 합니다. 실행할 때마다 값이 달라지는 로직이 섞이면 재개 시점의 실행 경로가 원래 실행과 달라질 수 있습니다.

SDK는 JavaScript, TypeScript, Python, Java를 지원하고 현행 개발자 안내서에는 C#(.NET)용 SDK도 올라와 있습니다. 워크 플로우를 별도 DSL 없이 이 언어들의 일반 코드로 그대로 쓴다는 점이 이 모델의 핵심입니다. 다만 활성화 가능한 런타임에는 하한이 있습니다. 2026년 4월 22일 공지 기준 Python 3.13과 3.14, Node.js 22와 24, Java 17 이상 기반 함수에서 durable execution을 켤 수 있으므로, Python 3.11처럼 그보다 낮은 버전에서 돌던 기존 함수는 런타임 업그레이드가 먼저입니다. 관리형 런타임에 없는 버전이 필요하면 OCI 컨테이너 이미지 기반으로도 durable 함수를 만들 수 있습니다.

Step Functions와의 선택 기준

다단계 워크 플로우에는 이미 AWS Step Functions가 있습니다. 표 2는 2가지 선택지를 실행 위치와 정의 방식, 사용 예로 비교합니다.

표 2. Durable Functions와 Step Functions 선택 기준

정리하면 워크 플로우가 애플리케이션 코드와 한 몸으로 움직이고 개발 언어 안에서 표현하는 편이 자연스럽다면 Durable Functions가, 여러 AWS 서비스를 엮는 오케스트레이션을 코드 배포 없이 시각적으로 운영하고 싶다면 Step Functions가 어울립니다.

상향 불가 한도가 설계 기준입니다

총량 한도부터 보면, 동시에 실행 중인 durable execution은 리전당 기본 500만 건이며, 버지니아, 오레곤, 아일랜드 3곳만 1,000만 건입니다. 실행당 durable operation은 3,000개, 실행당 영속 데이터는 100MB인데 이 2가지 한도는 상향 신청이 불가능합니다.

진입 속도에도 한도가 있습니다. durable execution을 시작하는 함수 호출 속도는 리전당 300 RPS이며 상향 요청이 가능합니다. 주문이나 결제처럼 요청 하나가 실행 하나를 시작하는 흐름이라면 리전당 500만 건보다 이 진입 상한에 먼저 걸립니다. 실행 이력을 조회하는 GetDurableExecutionHistory와 ListDurableExecutionsByFunction 같은 관측 API도 각 15 RPS라 대시보드 폴링 주기도 설계 변수에 들어갑니다.

상향 불가 한도는 운영이 아니라 설계 단계의 제약입니다. durable operation 수가 3,000개에 근접하는 워크 플로우라면 실행 분할을 설계에서 고려해야 합니다.

4. Lambda MicroVMs – Firecracker를 직접 쓰는 샌드박스

MicroVMs는 Lambda의 격리 계층이던 Firecracker를 프리미티브로 직접 노출하는 모델입니다. 2026년 6월 버지니아, 오하이오, 오레곤, 아일랜드, 도쿄 5개 리전에서 정식 출시되었고, 같은 해 8월 뭄바이, 싱가포르, 시드니, 프랑크푸르트, 스톡홀름이 더해져 총 10개 리전에서 제공됩니다. (서울 리전은 아직 대상이 아닙니다.) 핸들러와 이벤트라는 기존 Lambda의 사고방식이 여기서는 적용되지 않습니다. MicroVM마다 전용 HTTPS 엔드포인트가 부여되고, 애플리케이션에 HTTPS, WebSocket, gRPC로 직접 접속합니다.

Dockerfile에서 스냅샷까지

배포 파이프라인은 Dockerfile에서 출발합니다. Dockerfile로 이미지를 정의하면 빌드, 앱 초기화, 스냅샷 생성까지 Lambda가 수행합니다. 실행 시에는 이 스냅샷에서 부팅하므로 의존성이 모두 로드된 상태로 즉시 시작됩니다.

실행 중인 MicroVM은 idle 정책에 따라 자동으로 suspend됩니다. suspend 동안에는 메모리와 디스크 상태가 보존된 채 스토리지 요금만 발생하고 다시 필요해지면 자동으로 resume됩니다.

주의: 스냅샷은 모든 MicroVM이 공유합니다

이미지에 포함된 값은 그 스냅샷에서 부팅하는 모든 MicroVM이 그대로 공유합니다. 고유 ID, 시크릿, 랜덤 시드는 이미지에 넣지 말고 MicroVM 시작 후에 생성해야 하며 자격 증명과 네트워크 연결도 시작 후에 재수립해야 합니다. 이 처리는 lifecycle hook에서 수행합니다.

리소스, 과금, 네트워크

기본 리소스는 메모리 2GB에 1vCPU이고 베이스라인은 최대 8GB와 4vCPU까지 설정할 수 있습니다. 부하가 오르면 베이스라인의 4배까지 자동으로 수직 확장되어 피크 기준 32GB, 16vCPU에 이릅니다. 메모리와 vCPU 비율은 2:1로 고정이고 아키텍처는 ARM64입니다.

과금은 baseline-plus-consumption 방식입니다. 베이스라인 용량을 평균 사용량에 맞춰 두고 이를 넘는 초과분은 실제로 사용할 때만 과금됩니다.

네트워크 연결은 방향에 따라 2가지 기능으로 나뉩니다. MicroVM에서 VPC로 나가는 아웃바운드는 Lambda Network Connector(LNC)라는 신규 리소스로 연결합니다. 반대로 VPC에서 MicroVM으로 들어오는 인바운드는 2026년 8월 25일부터 AWS PrivateLink를 지원해, MicroVM API 호출과 각 MicroVM의 HTTPS 엔드포인트 접속을 퍼블릭 인터넷 노출 없이 수행할 수 있습니다.

용도와 한도

주 용도는 사용자나 AI가 생성한 코드를 VM 수준으로 격리해 실행하는 샌드박스입니다. 브라우저 IDE, 노트북, AI 코딩 에이전트 샌드박스, 취약점 스캐너, CI/CD 격리 환경이 대표 사례이고 Claude Managed Agents의 self-hosted sandbox provider로도 사용할 수 있습니다.

한도는 지속 시간과 총량에 있습니다. MicroVM 하나의 최대 지속 시간은 8시간입니다. 계정과 리전당 총 메모리는 400GB(버지니아, 오레곤, 오하이오, 도쿄는 1,024GB)에 4배 버스트가 가능하고, 이미지는 100개, 이미지당 버전은 50개까지입니다.

처리량 한도는 VM 단위와 API 단위에 있습니다. VM당 동시 연결은 vCPU에 비례해 1vCPU 구성의 8개에서 16vCPU 구성의 128개까지이고, VM당 초당 요청은 4vCPU와 메모리 8GB 구성에서 40건, 16vCPU와 메모리 32GB 구성에서 160건입니다. 이 2가지 한도는 상향 신청이 불가능합니다.

API 속도 한도는 계정과 리전당 적용되며 상향 요청이 가능합니다. 기동(RunMicrovm)과 재개(ResumeMicrovm)는 각 5 TPS, 일시 정지(SuspendMicrovm)는 2 TPS입니다. 기동 5 TPS는 기본값 기준 분당 300개 수준이라, 분당 수백 개 규모의 샌드박스 기동까지는 기본 한도 안에서 소화할 수 있습니다. 동시 이미지 빌드는 계정과 리전당 기본 5개(버지니아, 오레곤, 오하이오, 도쿄는 10개)입니다.

5. 기본 Lambda Functions의 설정 축

실행 모델을 골랐다면 다음은 기본 Lambda Functions 내부의 설정 축입니다. 같은 Functions 모델이라도 패키징, 호출 방식, 동시성, 리소스의 조합에 따라 동작과 한도가 달라집니다. 이 절의 수치는 Lambda quotas 문서를 기준으로 합니다.

패키징, 스토리지, 런타임, 아키텍처

코드를 어떤 형태로 만들어 무엇 위에서 실행할지 정하는 축부터 봅니다.

표 3. 패키징, 스토리지, 런타임, 아키텍처 축 요약

퍼블릭 프리뷰 런타임에는 단서가 있습니다. Node.js 26과 Python 3.15는 Lambda SLA와 AWS 기술 지원 플랜의 보장 대상이 아니며 AWS는 프로덕션 워크로드에 사용해서는 안 된다(should not be used)고 명시합니다(2026년 8월 25일 발표). 기술적으로 차단되는 것은 아니고 문서상의 지침입니다.

호출 방식 3종과 진입 지점 – 입구가 페이로드 한도를 정합니다

같은 함수라도 어떤 입구로 호출하느냐에 따라 페이로드 한도와 실패 처리 방식이 달라집니다. 층위를 나누면 호출 방식은 동기, 비동기, 이벤트 소스 매핑 3가지입니다. 응답 스트리밍은 그중 동기의 변형이고, Function URL이나 Lambda@Edge는 호출 방식이 아니라 진입 지점입니다.

• 동기(RequestResponse) – 호출자가 응답을 기다리는 방식입니다. 요청과 응답 페이로드는 각 6MB까지입니다. 실행 환경 인스턴스당 초당 10건까지 처리하므로 총 호출 상한은 동시성의 10배입니다. 동시성이 1,000이면 동기 호출 상한은 10,000 RPS입니다.
• 비동기(Event) – 페이로드는 1MB이고 Lambda가 기본 2회 재시도합니다. 최종 실패 시 이벤트를 DLQ(Dead Letter Queue) 또는 on-failure destination으로 보냅니다. 실행 환경당 요청 수 제한이 없어 총 상한은 함수가 쓸 수 있는 동시성에만 좌우되고 동기의 10배 계산은 여기에 적용되지 않습니다.
• 이벤트 소스 매핑 – 이벤트 폴러(event poller)라는 Lambda 측 리소스가 소스를 폴링해 함수를 호출합니다. 작성 시점 문서 기준 지원 소스는 Amazon SQS, Amazon Kinesis, Amazon DynamoDB, Amazon MSK, Amazon MQ, self-managed Apache Kafka, Amazon DocumentDB 7종입니다.

응답 스트리밍의 한도는 최대 200MB로, 첫 6MB는 대역폭 제한이 없으며 이후 2MBps로 제한됩니다.

Function URL, Lambda@Edge, Amazon API Gateway는 함수를 어디서 호출할지 정하는 진입 지점입니다. Function URL은 함수에 부여되는 전용 HTTP(S) 엔드포인트로, 퍼블릭 인터넷 전용이라 PrivateLink를 지원하지 않습니다. Lambda@Edge는 Amazon CloudFront와 함께 동작하고 API Gateway는 자체 스로틀을 앞단에 더합니다. 어느 진입 지점이든 뒤에서는 위 호출 방식 중 하나로 함수에 도달하므로, 입구의 조합이 곧 페이로드 한도와 처리량 상한을 정합니다.

동시성 3종과 스케일링 속도

트래픽이 몰릴 때 함수가 늘어나는 총량과 속도는 4가지 항목이 정합니다.

표 4. 동시성 3종과 스케일링 속도

콜드 스타트를 줄이는 축으로는 SnapStart가 있습니다. 함수 버전을 게시할 때 초기화를 미리 수행해 실행 환경의 메모리와 디스크 상태를 Firecracker microVM 스냅샷으로 캡처해 두고, 첫 호출과 스케일업 시 그 스냅샷에서 재개(resume)하는 방식입니다. Java 11, Python 3.12, .NET 8 이상의 관리형 런타임만 지원하고, Java는 추가 비용이 없지만 Python과 .NET은 스냅샷 캐싱과 복원 요금이 발생합니다.

리소스 한도 – 메모리가 CPU와 대역폭을 정합니다

Lambda Functions에는 CPU를 따로 설정하는 항목이 없습니다. 메모리를 128MB에서 10,240MB까지 1MB 단위로 설정하면 CPU가 비례해 붙고 1,769MB에서 vCPU 1개 상당이 됩니다. 타임아웃은 최대 900초이고 임시 스토리지 /tmp는 512MB에서 10,240MB까지입니다.

네트워크 대역폭은 기본 625Mbps입니다. VPC에 연결하지 않은 함수는 Service Quotas에서 “Network bandwidth per execution environment” 할당량 상향을 요청할 수 있는데, 활성화되면 메모리 2GB에서 625Mbps를 시작으로 메모리에 비례해 늘어나 10,240MB에서 최대 3,000Mbps에 이릅니다(2026년 8월 5일 발표).

네트워크, Layers, 권한, 기타 한도

네트워크 축은 VPC 연결 여부로 갈립니다. VPC 연결 함수는 ENI(Elastic Network Interface)를 사용하는데, ENI는 VPC당 500개이고 이 한도를 Amazon EFS 등 다른 서비스와 공유합니다. MicroVMs가 Lambda Network Connector(LNC)라는 별도 리소스로 VPC에 나가는 것과 달리 기본 함수는 ENI 방식입니다.

확장과 권한 축에도 한도가 있습니다. Layers는 함수당 최대 5개이고 Extensions를 지원합니다. 리소스 기반 정책은 20KB이며, 2026년 8월 25일부터는 단일 정책 문서에 여러 principal과 action을 담고 IAM condition key 전체를 쓸 수 있는 완전한 IAM 리소스 기반 정책이 지원됩니다.

나머지 한도는 숫자만 기억해 두면 됩니다. 환경 변수는 총 4KB, 파일 디스크립터와 프로세스·스레드는 각 1,024개입니다. 컨트롤 플레인 API는 합산 15 RPS이고 GetFunction(100 RPS)과 GetPolicy(15 RPS)는 별도 할당량입니다.

6. 선택 가이드와 운영 시 주의사항

지금까지의 내용을 선택 기준으로 접어 보면, 출발점은 워크로드가 이벤트 단발인지, 상시 병렬인지, 장기 워크 플로우인지, 코드 샌드박스인지입니다. 표 5는 대표 상황별로 어느 모델에서 시작할지 정리합니다.

표 5. 상황별 실행 모델 선택 가이드

주의: 앞단 10,000 RPS, 뒷단 동시성 1,000의 미스매치

API Gateway의 기본 스로틀은 10,000 RPS인데 Lambda의 기본 동시성은 리전당 1,000입니다. 기본값 그대로 조합하면 앞단이 뒷단보다 커서, 트래픽이 몰릴 때 API Gateway는 통과시키고 Lambda에서 스로틀링이 걸리는 병목이 생깁니다. 프로덕션 전에 Lambda 동시성 할당량을 예상 트래픽에 맞춰 상향해야 합니다.

할당량은 계정 상태에 따라서도 다릅니다. 신규 계정은 동시성과 메모리 할당량이 축소된 상태로 시작하고 사용량이 늘어나면 AWS가 자동으로 상향합니다. 새 계정에서 부하 테스트가 예상보다 일찍 스로틀되면 이 축소 상태부터 확인하는 것이 순서입니다.

그림 2. AWS Lambda의 실행 모델 4종과 호출 경로. 이벤트 소스는 기본 모델인 Lambda Functions를 호출하고, 직접 접속 클라이언트는 MicroVMs의 VM별 HTTPS 엔드포인트로 접속합니다. 오른쪽 배지는 각 모델의 최대 지속 시간으로, 15분에서 최대 1년까지 벌어지는 차이를 한눈에 보여줍니다.

마치며

도입에서 던진 3가지 질문으로 돌아가 보겠습니다. 15분을 넘는 장기 워크 플로우는 Durable Functions가 step과 wait, replay로 최대 1년까지 감당합니다. 다만 실행당 durable operation 3,000개라는 상향 불가 한도는 설계 단계에서 먼저 확인할 대목입니다. freeze 동작이 맞지 않는 상시 병렬 워크로드는 Managed Instances가 받아 주지만, 타임아웃이 발생해도 코드가 종료되지 않는 동작 차이를 마이그레이션 단계에서 반드시 검토해야 합니다. 사용자나 AI가 생성한 코드는 MicroVMs가 VM 수준 격리와 스냅샷 부팅으로 실행하되, 스냅샷을 모든 MicroVM이 공유한다는 점은 lifecycle hook 설계에 반영할 부분입니다. 다만 서울 리전에는 아직 제공되지 않아 국내 리전이 필수인 워크로드에는 이 선택지가 당장 열려 있지 않습니다.

Lambda는 이제 단일 실행 모델이 아니라 Functions, Managed Instances, Durable Functions, MicroVMs 4가지 컴퓨트 프리미티브의 묶음입니다. 서버리스 설계의 첫 질문도 “메모리를 얼마로 할당할 것인가?”에서 “어느 실행 모델에서 시작할 것인가?”로 바뀌었습니다. 본문의 수치와 기본값은 2026년 8월 기준이므로, 최신 값은 아래 공식 문서에서 확인하시기 바랍니다.

참고 자료

1차 출처

• Lambda quotas – AWS 공식 문서 (본문 한도 수치의 기준)
• Lambda Managed Instances execution environment – AWS 공식 문서
• Lambda Durable Functions – AWS 공식 문서
• Supported runtimes for durable functions – AWS 공식 문서 (런타임 하한과 .NET, 컨테이너 이미지 지원)
• AWS introduces Lambda MicroVMs for isolated execution of user and AI-generated code – AWS What’s New (2026-06-22)
• Announcing Lambda MicroVMs: serverless compute environments with VM-level isolation and near-instant startup – AWS Compute Blog (2026-07-10)

What’s New 발표

• AWS Lambda functions now support full IAM resource-based policies – AWS What’s New (2026-08-25)
• Node.js 26, Python 3.15 관리형 런타임 퍼블릭 프리뷰 – AWS What’s New (2026-08-25)
• Lambda 네트워크 대역폭 상향 (VPC 미연결 함수, 최대 3,000Mbps) – AWS What’s New (2026-08-05)
• Lambda Managed Instances 스케줄 기반 스케일링 – AWS What’s New (2026-05-12)
• AWS Lambda durable functions are now available in 16 additional AWS Regions – AWS What’s New (2026-04-22, 활성화 런타임 하한 명시)
• AWS Lambda Managed Instances expands to additional AWS Regions – AWS What’s New (2026-06)
• AWS Lambda MicroVMs is now available in 5 additional AWS regions – AWS What’s New (2026-08)
• AWS Lambda MicroVMs now supports AWS PrivateLink – AWS What’s New (2026-08-25)

본문의 수치와 기본값은 2026년 8월 26일 기준이며, AWS Lambda 공식 문서(quotas, Managed Instances, Durable Functions)와 AWS Compute Blog, What’s New 발표를 기반으로 작성했습니다.