AWS LAMBDA / FEATURE ANALYSIS

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

AWS Lambda는 이제 단일 실행 모델이 아니라 Functions, Managed Instances, Durable Functions, MicroVMs 네 가지 컴퓨트 프리미티브의 묶음입니다. 실행 모델 4종의 구조 차이와 기본 함수 내부의 설정 축, 워크로드별 선택 기준을 2026-08 기준으로 정리합니다.

01. 작성 기준일 - 2026-08-26

02. 적용 대상 - AWS Lambda로 서버리스 워크로드를 설계하거나 운영하는 팀

03. 문서 범위 - 실행 모델 4종과 기본 함수 설정 축, 2026-08 기준

04. 주 출처 - AWS 공식 문서(quotas, Managed Instances, Durable Functions)와 Compute Blog(2026-07-10)

05. 게시 - 이 글은 AWS 기술 블로그에 게시되었습니다(2026-08-28).

요약

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 공식 문서 기준으로 정리합니다. 마지막에는 워크로드 성격에 따라 어느 모델에서 시작할지 판단하는 기준을 제시합니다.

01실행 모델 4종 한눈에

4가지 모델은 이름만 나란할 뿐 실행 단위와 격리 수준부터 다릅니다. 표 1은 실행 단위, 최대 지속 시간, 격리, 상태 유지, 주 용도 다섯 축으로 차이를 요약합니다. 최대 지속 시간만 봐도 15분에서 최대 1년까지 벌어집니다.

표 1. Lambda 실행 모델 4종 비교 (2026-08 기준)
모델 실행 단위 최대 지속 격리 상태 유지 주 용도
Lambda Functions (기본) 호출(invocation) 15분 Firecracker microVM (관리형) 보장 없음 (웜 재사용 시 /tmp, 전역 변수 유지) 이벤트 기반 단발 처리
Lambda Managed Instances 고객 소유 EC2 인스턴스 인스턴스 상주 컨테이너 환경 상주 상시 활성, 병렬 처리 워크로드
Lambda Durable Functions durable execution 최대 1년 기본 Lambda와 동일 체크포인트 다단계 워크 플로우, AI 오케스트레이션
Lambda MicroVMs MicroVM 인스턴스 8시간 VM 수준 (Firecracker 직접) 메모리, 디스크 스냅샷 사용자/AI 생성 코드 샌드박스

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

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

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

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

모델 선택의 출발점은 워크로드 성격입니다. 그림 1은 네 가지 대표 상황을 각 실행 모델로 잇는 분기를 보여줍니다.

flowchart LR Q{"워크로드 성격은?"} -->|"이벤트 단발 처리"| F["Lambda Functions (최대 15분)"] Q -->|"상시 활성, 병렬 처리"| MI["Managed Instances (인스턴스 상주)"] Q -->|"장기 워크 플로우"| DF["Durable Functions (최대 1년)"] Q -->|"코드 샌드박스"| MV["MicroVMs (최대 8시간, VM 격리)"]
그림 1. 워크로드 성격에 따른 실행 모델 선택 분기. 이벤트 단발이면 기본 Functions에서 시작하고, 상시 병렬 처리, 장기 워크 플로우, 코드 샌드박스일 때만 나머지 모델로 넘어갑니다.

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

02Lambda Managed Instances

Managed Instances는 코드를 고객 소유 EC2 인스턴스에서 실행하고 운영은 Lambda가 담당하는 모델입니다. 같은 함수 코드를 올려도 실행 환경의 동작이 기본 Lambda와 근본적으로 다릅니다. 이 섹션은 그 동작 차이와, 기존 함수를 그대로 옮길 때 걸리는 함정을 정리합니다.

2.1 freeze가 없고, 한 환경이 여러 호출을 동시에 처리합니다

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

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

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

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

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

주의 - 타임아웃이 나도 코드는 종료되지 않습니다

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

2.2 backpressure와 컨테이너 폐기 정책

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

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

2.3 한도, 스케일링, 과금

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

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

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

03Lambda Durable Functions

Durable Functions는 실행 도중 체크포인트를 남기고, 중단되면 그 지점부터 이어가는 durable execution을 Lambda 함수 안에 구현한 모델입니다. 이 메커니즘 덕분에 하나의 실행이 15분이 아니라 최대 1년까지 이어집니다. 이 섹션은 두 프리미티브와 결정론 요구, Step Functions와의 선택 기준, 한도를 정리합니다.

3.1 step과 wait, 그리고 replay

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

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

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

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

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

3.2 Step Functions와 어떻게 가를까

다단계 워크 플로우에는 이미 Step Functions가 있습니다. 언제 무엇을 쓸까요? 표 2는 두 선택지를 실행 위치, 정의 방식, 어울리는 상황으로 비교합니다.

표 2. Durable Functions와 Step Functions 선택 기준
기준 Lambda Durable Functions Step Functions
실행 위치 Lambda 함수 안 독립 서비스
워크 플로우 정의 일반 프로그래밍 언어 코드 그래프 DSL, 비주얼 디자이너
어울리는 경우 워크 플로우가 비즈니스 로직과 밀결합일 때 220개 이상 서비스 통합과 무보수 운영이 필요할 때

3.3 한도 - 상향 불가 항목이 설계 기준입니다

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

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

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

04Lambda MicroVMs

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

4.1 Dockerfile에서 스냅샷까지

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

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

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

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

4.2 리소스, 과금, 네트워크

리소스는 어디까지 쓸 수 있을까요? 기본은 메모리 2GB에 1vCPU이고, 베이스라인은 최대 8GB/4vCPU까지 설정할 수 있습니다. 부하가 오르면 베이스라인의 4배까지 자동 수직 확장되어 피크 기준 32GB/16vCPU에 이릅니다.

메모리와 vCPU 비율은 2:1로 고정이고 아키텍처는 ARM64입니다. 과금은 baseline-plus-consumption 방식입니다. 베이스라인 용량을 평균 사용량에 맞춰 두고, 이를 넘는 초과분은 실제로 사용할 때만 과금됩니다.

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

4.3 용도와 한도

주 용도는 사용자나 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건입니다. 이 두 한도는 상향 신청이 불가능합니다.

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

05기본 Lambda Functions의 설정 축

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

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

코드를 어떤 형태로 만들어 무엇 위에서 실행할지 정하는 축부터 봅니다. 표 3은 네 축의 선택지와 한도를 요약합니다.

표 3. 패키징, 스토리지, 런타임, 아키텍처 축 요약
축 선택지 한도와 비고
패키징 - zip zip 아카이브 업로드 압축 50MB(직접 업로드), 콘솔 편집기는 별도 3MB, 압축 해제 250MB(레이어와 커스텀 런타임 포함). 초과 시 S3 경유
패키징 - 컨테이너 컨테이너 이미지 비압축 10GB, Amazon ECR에 저장
코드 스토리지 Lambda 관리형 스토리지 리전당 300GB, 상향 불가. 초과가 예상되면 자체 관리 S3로 전환
런타임 관리형 5계열 + OS-only Node.js, Python, Java, .NET, Ruby와 provided.al2023(커스텀 런타임용). Node.js 26과 Python 3.15는 퍼블릭 프리뷰
아키텍처 x86_64 / arm64 arm64는 Graviton2 프로세서. 지원 런타임 전체가 두 아키텍처를 모두 지원

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

5.2 호출 방식 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 측 리소스가 소스를 폴링해 함수를 호출합니다. 작성 시점 문서 기준 지원 소스는 SQS, Kinesis, DynamoDB, MSK, Amazon MQ, self-managed Apache Kafka, Amazon DocumentDB 7종입니다.

응답 스트리밍은 별도 호출 방식이 아니라 동기 호출의 변형입니다. 응답을 최대 200MB까지 스트리밍하고, 첫 6MB는 대역폭 제한이 없으며 이후 2MBps로 제한됩니다.

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

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

트래픽이 몰리면 함수는 얼마나 많이, 얼마나 빨리 늘어날 수 있을까요? 표 4는 동시성 3종과 스케일링 속도를 요약합니다.

표 4. 동시성 3종과 스케일링 속도
항목 기본값과 한도 비고
온디맨드 동시성 리전당 기본 1,000 수만 단위까지 상향 요청 가능
예약 동시성 (reserved) 계정 동시성에서 100을 뺀 값까지 특정 함수 전용 몫을 확보. 기본 계정 동시성 1,000 기준 최대 900이고, 계정 동시성을 상향하면 함께 커짐. 100 유닛은 항상 unreserved로 남음. 추가 요금 없음
프로비저닝드 동시성 (provisioned) 동기 호출 한도 = 할당 동시성의 10배 10배 규칙은 동기 호출 한정. 온디맨드 함수의 동기 호출도 환경당 10 RPS로 동일. 비동기는 환경당 요청 수 무제한
스케일링 속도 10초당 실행 환경 1,000개 함수별로 적용

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

5.4 리소스 한도 - 메모리가 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-08-05 발표).

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

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

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

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

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

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

표 5. 상황별 실행 모델 선택 가이드
상황 선택 이유
API 백엔드, 이벤트 기반 단발 처리 Lambda Functions 호출당 실행과 15분 한도로 충분한 대부분의 서버리스 워크로드
상시 활성 환경에서 여러 요청을 병렬 처리 Managed Instances freeze 없이 동시 호출 처리. 타임아웃 시 코드 미종료 함정 주의
승인 대기가 낀 장기 다단계 워크 플로우, AI 오케스트레이션 Durable Functions step/wait와 replay로 최대 1년. 워크 플로우가 비즈니스 로직과 밀결합일 때
220개 이상 서비스 통합, 무보수 운영이 우선 Step Functions 그래프 DSL과 비주얼 디자이너를 갖춘 독립 워크 플로우 서비스
사용자나 AI가 생성한 코드의 격리 실행 MicroVMs VM 수준 격리와 스냅샷 부팅, 최대 8시간 세션. 서울 리전은 미제공
주의 - 앞단 10,000 RPS, 뒷단 동시성 1,000의 미스매치

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

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

도입에서 던진 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 네 가지 컴퓨트 프리미티브의 묶음이며, 서버리스 설계의 첫 질문은 "메모리를 얼마로 잡을까"가 아니라 "어느 실행 모델에서 시작할까"로 바뀌었습니다.

인터랙티브 아키텍처 맵 전체 이미지 - Lambda 실행 모델 4종의 구조와 접속 경로
그림 2. 인터랙티브 아키텍처 맵 전체 보기. 이미지를 클릭하면 노드 탐색, 경로 추적, 다크/라이트 테마를 지원하는 인터랙티브 버전 ↗이 열립니다.

--참고 자료

게시본

1차 출처

What's New 발표 (본문 확인 완료)

AWS LAMBDA / FEATURE ANALYSIS

The Four AWS Lambda Execution Models - Structure and Selection Criteria

AWS Lambda is no longer a single execution model but a bundle of four compute primitives: Functions, Managed Instances, Durable Functions, and MicroVMs. This document covers the structural differences among the four execution models, the configuration axes inside base functions, and selection criteria by workload, as of 2026-08.

01. Written as of - 2026-08-26

02. Audience - teams designing or operating serverless workloads on AWS Lambda

03. Scope - the four execution models and base function configuration axes, as of 2026-08

04. Primary sources - official AWS documentation (quotas, Managed Instances, Durable Functions) and the Compute Blog (2026-07-10)

05. Published - this article appeared on the AWS Tech Blog (Korean) on 2026-08-28.

TL;DR

Designing serverless workloads on Lambda, you keep running into the same questions. How do you handle long-running workflows that exceed the 15-minute limit? Does the freeze behavior - the execution environment pausing between invocations - suit an always-on service? Where do you safely run user- or AI-generated code? Until now the answers were often found outside Lambda: move workflows to AWS Step Functions, rebuild always-on workloads as containers, and stand up your own infrastructure for code sandboxes.

As of August 2026, four distinct execution models live under the Lambda name. The per-invocation model we knew is one of them, Lambda Functions, and with Lambda Managed Instances, Lambda Durable Functions, and Lambda MicroVMs added, the execution limit now spans from 15 minutes to up to 1 year. This post first compares the structural differences among the four execution models, then organizes the configuration axes and limits inside base functions against the official AWS documentation, and closes with criteria for deciding which model to start from by workload.

01The four execution models at a glance

The four models share little beyond the name - they differ from the execution unit and isolation level up. Table 1 summarizes the differences along five axes: execution unit, maximum duration, isolation, state retention, and primary use. Maximum duration alone spans from 15 minutes to up to 1 year.

Table 1. The four Lambda execution models compared (as of 2026-08)
Model Execution unit Max duration Isolation State retention Primary use
Lambda Functions (base) Invocation 15 min Firecracker microVM (managed) Not guaranteed (/tmp and global variables persist on warm reuse) One-shot event-driven processing
Lambda Managed Instances Customer-owned EC2 instance Instance-resident Container Environment-resident Always-on, parallel workloads
Lambda Durable Functions Durable execution Up to 1 year Same as base Lambda Checkpoints Multi-step workflows, AI orchestration
Lambda MicroVMs MicroVM instance 8 hours VM-level (Firecracker directly) Memory, disk snapshot Sandbox for user/AI-generated code

Lambda Functions is the Lambda we knew. When an event arrives, it runs per invocation, and between invocations the execution environment is frozen (paused). Isolation is handled by Firecracker, the lightweight microVM virtualization technology that has served as Lambda's isolation layer. When a frozen environment is reused for the next invocation, the /tmp directory and global variable state outside the handler are preserved as-is. This is why the optimization of creating a DB connection in initialization code and reusing it works - but execution environments are replaced every few hours, so state retention across invocations must not be assumed as a guarantee.

Lambda Managed Instances runs your code on customer-owned EC2 instances while Lambda handles only operations. The execution environment is never frozen and stays active, and multiple invocations run concurrently within a single environment. It targets always-on, parallel workloads; the behavioral differences are covered in detail in section 02.

Lambda Durable Functions adds durable execution to Lambda - an execution style that leaves checkpoints and resumes from the point of interruption. With the checkpoint and replay mechanism, a single execution can last up to 1 year. Multi-step workflows and AI orchestration are the primary uses, covered in section 03.

Lambda MicroVMs exposes Firecracker directly as a primitive. Instead of the handler-and-event model, you connect directly to a dedicated HTTPS endpoint assigned to each MicroVM, so the mental model itself differs from the Lambda we knew. Its primary use is a sandbox that isolates user- or AI-generated code at the VM level, covered in section 04.

The starting point for model selection is workload characteristics. Figure 1 shows the branching that maps four representative situations to each execution model.

flowchart LR Q{"What is the workload like?"} -->|"One-shot event processing"| F["Lambda Functions (up to 15 min)"] Q -->|"Always-on, parallel processing"| MI["Managed Instances (instance-resident)"] Q -->|"Long-running workflow"| DF["Durable Functions (up to 1 year)"] Q -->|"Code sandbox"| MV["MicroVMs (up to 8 hours, VM isolation)"]
Figure 1. Execution model selection by workload characteristics. Start from base Functions for one-shot events, and move to the other models only for always-on parallel processing, long-running workflows, or code sandboxes.

The four models are not entirely mutually exclusive. The AWS documentation describes Durable Functions as regular Lambda functions that use the checkpoint/replay mechanism, so Durable Functions is not separate infrastructure but an execution mode that operates on top of base Functions. Whether Durable Functions can be combined with Managed Instances or MicroVMs, on the other hand, is not mentioned in the official documentation at the time of writing, so this document makes no claim either way.

02Lambda Managed Instances

Managed Instances is a model that runs your code on customer-owned EC2 instances while Lambda handles operations. Even with the same function code, the execution environment behaves fundamentally differently from base Lambda. This section lays out those behavioral differences and the traps you hit when migrating an existing function as-is.

2.1 No freeze, and one environment handles multiple invocations concurrently

Base Lambda freezes the execution environment when an invocation ends, but a Managed Instances execution environment stays active with no freeze. That means the execution environment keeps running even between invocations.

Invocation handling also differs. Within one execution environment, multiple invocations run concurrently, one per runtime worker. Base Lambda's equation - one execution environment handles one concurrent invocation - does not hold here.

Caution - isolation between invocations goes away

In base Lambda, one execution environment handles only one concurrent invocation and the environment itself is isolated as a Firecracker microVM, but on Managed Instances concurrent invocations share the same container's process space, divided per runtime worker. Global variable pollution, thread safety, and one invocation's memory leak spilling into another become items you must newly review when migrating. The AWS documentation also states that thread safety, state management, and context isolation must be handled differently in this execution model.

Timeouts apply independently per invocation. Even if one invocation times out, other invocations in the same environment keep running unaffected.

Caution - your code is not terminated on timeout

When an invocation times out on Managed Instances, Lambda returns an error to the caller, but your code is not forcibly terminated and keeps running in the background. Unless your code checks the remaining time on context and stops itself, an invocation already treated as failed can complete late and produce side effects such as duplicate writes or duplicate notifications. This is a difference you must be aware of when migrating base Lambda functions.

2.2 Backpressure and the container disposal policy

Behavior under overload also differs. Managed Instances uses backpressure: instead of queuing requests beyond its processing capacity, it rejects them up front. When all runtime workers are busy, new requests are rejected.

The error handling policy is equally simple. When an execution environment errors, Lambda does not attempt a reset or recovery; it discards the container and replaces it with a new one. A design that accumulates long-lived state inside the execution environment must assume this disposal policy.

2.3 Limits, scaling, and billing

How do the limits differ from base Lambda? Initialization is allowed up to 15 minutes, and the file descriptor limit is 4,096, larger than base Lambda's 1,024. The execution environment OS is based on Bottlerocket. Regional availability covers every commercial region including Seoul, with only four exceptions: Tel Aviv, Bahrain, UAE, and Auckland.

Scaling happens automatically based on resource usage signals, within the configured minimum/maximum execution environment bounds. There is, however, no automatic scale-to-zero. Even with no traffic, capacity shrinks only down to the configured minimum execution environments (3 by default). Setting both the minimum and maximum to 0 disables the function and terminates the underlying instances, and it does not come back automatically when traffic returns - you must set them back to non-zero values. Since 2026-05-12, schedule-based scaling has been added: you define one-time or recurring schedules with Amazon EventBridge Scheduler to adjust capacity limits in advance.

The billing structure also differs from base Lambda. A request charge of $0.20 per million requests is combined with the provisioned EC2 instance cost and a management fee equal to 15% of the EC2 on-demand price. There is no per-invocation duration charge; instead, as the instance-resident label in Table 1 implies, billing continues while instances are up even with no traffic. EC2 Savings Plans and Reserved Instance discounts apply only to the underlying EC2 cost, not to the management fee.

03Lambda Durable Functions

Durable Functions is a model that implements durable execution inside a Lambda function: it leaves checkpoints during execution and, if interrupted, resumes from that point. Thanks to this mechanism, a single execution can last up to 1 year instead of 15 minutes. This section covers the two primitives and the determinism requirement, the criteria for choosing between this and Step Functions, and the limits.

3.1 step and wait, and replay

Developers use two primitives. step is a unit of business logic with built-in retries and progress tracking, and wait suspends execution without incurring charges. Handle long approval waits or external event waits with wait, and no charges accrue during that time.

When execution resumes, the code runs again from the beginning. However, already-completed steps are skipped using their saved checkpoint results - this re-execution style is called replay.

Note - the determinism that replay demands

Replay rests on the premise that re-running the same code follows the same path. The function must therefore be deterministic. If logic that yields a different value on each run creeps in, the execution path at resume time can diverge from the original execution.

The SDK supports JavaScript, TypeScript, Python, and Java, and the current developer guide also lists an SDK for C# (.NET). The heart of this model is that you write workflows as plain code in these languages, not in a separate DSL. There is, however, a floor on the runtimes you can enable it on. Per the 2026-04-22 announcement, durable execution can be enabled on functions based on Python 3.13 and 3.14, Node.js 22 and 24, and Java 17 or later - so for an existing function on something older, such as Python 3.11, a runtime upgrade comes first. If you need a version not offered as a managed runtime, durable functions can also be built from OCI container images.

3.2 How to choose between this and Step Functions

Step Functions already exists for multi-step workflows. When do you use which? Table 2 compares the two options by execution location, definition style, and the situations each suits.

Table 2. Choosing between Durable Functions and Step Functions
Criterion Lambda Durable Functions Step Functions
Execution location Inside a Lambda function Independent service
Workflow definition Plain programming language code Graph DSL, visual designer
Suits when The workflow is tightly coupled with business logic You need 220+ service integrations and hands-off operation

3.3 Limits - the non-raisable items are your design constraints

Start with the aggregate limits. Concurrently running durable executions are capped at 5 million per region by default, and 10 million in only three regions: Virginia, Oregon, and Ireland. Durable operations per execution: 3,000; persistent data per execution: 100MB - and these two limits cannot be raised.

The entry rate is limited too. Function invocations that start a durable execution are limited to 300 RPS per region, and this limit can be raised on request. In flows where one request starts one execution - orders or payments, say - you hit this entry ceiling before the 5-million-per-region cap. Observability APIs such as GetDurableExecutionHistory and ListDurableExecutionsByFunction are also limited to 15 RPS each, so factor dashboard polling intervals into the design.

Non-raisable limits are design-stage constraints, not operational ones. A workflow whose durable operation count approaches 3,000 should consider execution splitting at design time.

04Lambda MicroVMs

MicroVMs expose Firecracker - previously Lambda's isolation layer - directly as a primitive. It reached general availability in June 2026 in five regions - Virginia, Ohio, Oregon, Ireland, and Tokyo, and Mumbai, Singapore, Sydney, Frankfurt, and Stockholm followed in August, for a total of ten regions (the Seoul Region is not yet covered). The familiar Lambda mindset of handlers and events does not apply here. Each MicroVM is assigned a dedicated HTTPS endpoint, and you connect to the application directly over HTTPS, WebSocket, or gRPC.

4.1 From Dockerfile to snapshot

The deployment pipeline starts from a Dockerfile. Once you define the image with a Dockerfile, Lambda performs the build, app initialization, and snapshot creation. At run time it boots from this snapshot, so it starts instantly with all dependencies already loaded.

A running MicroVM is automatically suspended according to the idle policy. While suspended, memory and disk state are preserved and only storage charges accrue; when needed again, it resumes automatically.

Caution - the snapshot is shared by every MicroVM

Any value baked into the image is shared as-is by every MicroVM that boots from that snapshot. Unique IDs, secrets, and random seeds must not go into the image - generate them after the MicroVM starts - and credentials and network connections must also be re-established after startup. Handle this in a lifecycle hook.

4.2 Resources, billing, and networking

How far do the resources go? The default is 2GB of memory with 1 vCPU, and the baseline can be set up to 8GB/4vCPU. Under load it scales vertically and automatically up to 4x the baseline, reaching 32GB/16vCPU at peak.

The memory-to-vCPU ratio is fixed at 2:1 and the architecture is ARM64. Billing is baseline-plus-consumption. You set the baseline capacity to your average usage, and anything above it is billed only when actually used.

Network connectivity splits into two features by direction. Outbound traffic from a MicroVM into a VPC goes through a new resource called the Lambda Network Connector (LNC). Inbound traffic from a VPC into MicroVMs supports AWS PrivateLink (announced 2026-08-25), so MicroVM API calls and connections to each MicroVM's HTTPS endpoint can be made without public internet exposure.

4.3 Uses and limits

The primary use is sandboxes that run user- or AI-generated code with VM-level isolation. Representative cases include browser IDEs, notebooks, AI coding agent sandboxes, vulnerability scanners, and isolated CI/CD environments, and it can also serve as the self-hosted sandbox provider for Claude Managed Agents.

Limits exist on both duration and totals. The maximum duration of a single MicroVM is 8 hours. Total memory per account and region is 400GB (1,024GB in Virginia, Oregon, Ohio, and Tokyo) with 4x burst, and you get up to 100 images and 50 versions per image.

Throughput limits exist at both the VM level and the API level. Concurrent connections per VM scale with vCPU, from 8 at 1 vCPU to 128 at 16 vCPU, and requests per second per VM are 40 on a 4vCPU/8GB configuration and 160 on a 16vCPU/32GB configuration. These two limits cannot be raised.

API rate limits apply per account and region and can be raised on request. Launch (RunMicrovm) and resume (ResumeMicrovm) are 5 TPS each, and suspend (SuspendMicrovm) is 2 TPS. Launching at 5 TPS amounts to roughly 300 per minute at the defaults, so sandbox launches on the order of a few hundred per minute fit within the default limits. Concurrent image builds default to 5 per account and region (10 in Virginia, Oregon, Ohio, and Tokyo).

05Configuration axes of base Lambda Functions

Once you have chosen an execution model, next come the configuration axes inside base Lambda Functions. Even within the same Functions model, behavior and limits change with the combination of packaging, invocation type, concurrency, and resources. This section organizes those axes together with the figures from the quotas documentation.

5.1 Packaging, storage, runtimes, and architecture

Start with the axes that decide what shape your code takes and what it runs on. Table 3 summarizes the options and limits along four axes.

Table 3. Packaging, storage, runtime, and architecture axes
Axis Options Limits and notes
Packaging - zip zip archive upload Compressed 50MB (direct upload) with a separate 3MB limit for the console editor, uncompressed 250MB (including layers and custom runtimes). Go through S3 beyond that
Packaging - container Container image Uncompressed 10GB, stored in Amazon ECR
Code storage Lambda-managed storage 300GB per region, cannot be raised. Switch to self-managed S3 if you expect to exceed it
Runtimes 5 managed families + OS-only Node.js, Python, Java, .NET, Ruby, plus provided.al2023 (for custom runtimes). Node.js 26 and Python 3.15 are in public preview
Architecture x86_64 / arm64 arm64 uses Graviton2 processors. All supported runtimes support both architectures

The public preview runtimes come with a caveat. Node.js 26 and Python 3.15 are not covered by the Lambda SLA or AWS technical support plans, and AWS states they should not be used for production workloads (announced 2026-08-25). This is documented guidance, not a technical block.

5.2 The three invocation types and entry points - the entrance sets the payload limit

Even for the same function, the payload limit and failure handling differ by which entrance invokes it. Sorted into layers, there are three invocation types - synchronous, asynchronous, and event source mapping; response streaming is a variant of synchronous, and Function URLs or Lambda@Edge are entry points, not invocation types.

  • Synchronous (RequestResponse) - the caller waits for the response. Request and response payloads are up to 6MB each. Each execution environment instance handles up to 10 requests per second, so the total invocation ceiling is 10x the concurrency. With a concurrency of 1,000, the synchronous invocation ceiling is 10,000 RPS.
  • Asynchronous (Event) - the payload is 1MB and Lambda retries twice by default. On final failure, the event goes to a DLQ (Dead Letter Queue) or an on-failure destination. There is no per-environment request cap, so the total ceiling depends only on the concurrency available to the function - the synchronous 10x math does not apply here.
  • Event source mapping - a Lambda-side resource called an event poller polls the source and invokes the function. Per the documentation at the time of writing, seven sources are supported: SQS, Kinesis, DynamoDB, MSK, Amazon MQ, self-managed Apache Kafka, and Amazon DocumentDB.

Response streaming is not a separate invocation type but a variant of synchronous invocation. It streams responses up to 200MB; the first 6MB has no bandwidth cap, after which it is limited to 2MBps.

Function URLs, Lambda@Edge, and API Gateway are entry points that decide where the function is invoked from. A Function URL is a dedicated HTTP(S) endpoint assigned to a function; it is public-internet-only and does not support PrivateLink. Lambda@Edge works together with CloudFront, and API Gateway adds its own throttle in front (see section 06). Whatever the entry point, requests reach the function through one of the invocation types above, so the combination at the entrance determines the payload limits and throughput ceilings.

5.3 The three concurrency types and scaling rate

When traffic surges, how many instances can a function grow to, and how fast? Table 4 summarizes the three concurrency types and the scaling rate.

Table 4. The three concurrency types and scaling rate
Item Default and limit Notes
On-demand concurrency 1,000 per region by default Can be raised into the tens of thousands on request
Reserved concurrency Up to the account concurrency minus 100 Carves out a dedicated share for a specific function. At the default account concurrency of 1,000 that is at most 900, and it grows as the account concurrency is raised. 100 units always remain unreserved. No extra charge
Provisioned concurrency Synchronous invocation limit = 10x the allocated concurrency The 10x rule applies to synchronous invocations only. Synchronous invocations of on-demand functions are likewise 10 RPS per environment. Asynchronous invocations have no per-environment request cap
Scaling rate 1,000 execution environments per 10 seconds Applied per function

SnapStart is the axis for reducing cold starts. When a function version is published, initialization runs ahead of time and the execution environment's memory and disk state is captured as a Firecracker microVM snapshot; on first invocation and scale-up, execution resumes from that snapshot. Only managed runtimes at Java 11, Python 3.12, and .NET 8 or later are supported; Java has no extra cost, while Python and .NET incur snapshot caching and restore charges.

5.4 Resource limits - memory sets CPU and bandwidth

Lambda Functions has no separate CPU setting. Set memory anywhere from 128MB to 10,240MB in 1MB increments and CPU scales proportionally, with 1,769MB corresponding to 1 vCPU. The timeout maxes out at 900 seconds, and ephemeral storage /tmp ranges from 512MB to 10,240MB.

How far can network bandwidth grow? The default is 625Mbps, but functions not attached to a VPC can request an increase of the "Network bandwidth per execution environment" quota in Service Quotas. Once enabled, bandwidth starts at 625Mbps at 2GB and grows proportionally with memory, reaching up to 3,000Mbps at 10,240MB (announced 2026-08-05).

5.5 Networking, Layers, permissions, and other limits

The network axis splits on VPC attachment. VPC-attached functions use ENIs (Elastic Network Interfaces); the limit is 500 ENIs per VPC, shared with other services such as EFS. Unlike MicroVMs, which reach into a VPC through the separate LNC resource as seen earlier, base functions use the ENI approach.

The extension and permission axes have limits too. Layers are capped at 5 per function, and Extensions are supported. Resource-based policies are 20KB, and since 2026-08-25, full IAM resource-based policies are supported - a single policy document can hold multiple principals and actions and use the entire set of IAM condition keys.

For the remaining limits, just remember the numbers. Environment variables total 4KB, and file descriptors and processes/threads are 1,024 each. Control plane APIs share a combined 15 RPS, while GetFunction (100 RPS) and GetPolicy (15 RPS) have separate quotas.

06Selection guide and operational cautions

Finally, let us fold everything so far into selection criteria and operational cautions. The starting point for selection is whether the workload is one-shot event processing, always-on parallel processing, a long-running workflow, or a code sandbox. Table 5 organizes which model to start from for representative situations.

Table 5. Execution model selection guide by situation
Situation Choice Why
API backends, one-shot event-driven processing Lambda Functions Most serverless workloads, where per-invocation execution and the 15-minute limit suffice
Parallel processing of multiple requests in an always-active environment Managed Instances Handles concurrent invocations with no freeze. Watch the pitfall of code not terminating on timeout
Long multi-step workflows with approval waits, AI orchestration Durable Functions Up to 1 year with step/wait and replay. When the workflow is tightly coupled with business logic
220+ service integrations, hands-off operation first Step Functions An independent workflow service with a graph DSL and a visual designer
Isolated execution of user- or AI-generated code MicroVMs VM-level isolation and snapshot boot, sessions up to 8 hours. Not yet available in the Seoul Region
Caution - the mismatch of 10,000 RPS in front and concurrency 1,000 behind

API Gateway's default throttle is 10,000 RPS, while Lambda's default concurrency is 1,000 per region. Combined with defaults as-is, the front end is larger than the back end, so when traffic surges, API Gateway lets requests through and Lambda becomes the throttling bottleneck. Before production, raise the Lambda concurrency quota to match expected traffic.

Quotas also vary with account status. New accounts start with reduced concurrency and memory quotas, and AWS raises them automatically as usage grows. If a load test on a fresh account throttles earlier than expected, check this reduced state first.

Back to the three questions from the opening. Long workflows past 15 minutes are handled by Durable Functions with step, wait, and replay, for up to 1 year - though the non-raisable limit of 3,000 durable operations per execution is something to check at design time. Always-on parallel workloads that the freeze behavior does not suit are taken by Managed Instances, but the behavioral difference that code is not terminated on timeout must be reviewed during migration. User- or AI-generated code runs on MicroVMs with VM-level isolation and snapshot boot, keeping in mind that the snapshot is shared by every MicroVM - a point to reflect in lifecycle hook design. Note it is not yet available in the Seoul Region, so this option is not immediately open to workloads that require a domestic region.

Conclusion: In one sentence, Lambda is no longer a single execution model but a bundle of four compute primitives - Functions, Managed Instances, Durable Functions, and MicroVMs - and the first question of serverless design has changed from “how much memory should I allocate” to “which execution model should I start from”.

Full interactive architecture map - the four Lambda execution models and their access paths
Figure 2. Full view of the interactive architecture map. Click the image to open the interactive version ↗ with node exploration, path tracing, and dark/light themes.

--References

Published version

Primary sources

What's New announcements (full text verified)