AWS LAMBDA / FEATURE ANALYSIS

Lambda는 이제 하나가 아니다 - 실행 모델 4종과 설정 축 전부 정리

AWS Lambda는 이제 단일 실행 모델이 아니라 Functions, Managed Instances, Durable Functions, MicroVMs 네 가지 컴퓨트 프리미티브의 묶음입니다. 실행 모델 4종을 1층, 기본 함수 내부의 설정 축을 2층으로 나누어 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)

요약

01실행 모델 4종 한눈에

2026년 8월 현재 Lambda라는 이름 아래에는 서로 다른 실행 모델 네 가지가 있습니다. 우리가 알던 호출당 실행 모델은 이제 그중 하나인 Lambda Functions이고, 나머지 셋은 실행 단위와 격리 수준 자체가 다릅니다. 이 섹션은 네 모델을 한 표로 비교하고, 어느 모델에서 시작할지 판단하는 분기를 제시합니다.

네 모델은 무엇이 얼마나 다를까요? 표 1은 실행 단위, 최대 지속 시간, 격리, 상태 유지, 주 용도 다섯 축으로 차이를 요약합니다. 최대 지속 시간만 봐도 15분에서 최대 1년까지 벌어집니다.

표 1. Lambda 실행 모델 4종 비교 (2026-08 기준)
모델 실행 단위 최대 지속 격리 상태 유지 주 용도
Lambda Functions (기본) 호출(invocation) 15분 Firecracker microVM (관리형) 없음 이벤트 기반 단발 처리
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 가상화 기술입니다.

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에서 시작하고, 상시 병렬 처리, 장기 워크플로, 코드 샌드박스일 때만 나머지 모델로 넘어갑니다.

02Lambda Managed Instances

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

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

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

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

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

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

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

2.2 backpressure와 컨테이너 폐기 정책

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

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

2.3 한도와 스케일링

기본 Lambda와 한도는 어떻게 다를까요? 초기화는 최대 15분까지 허용되고, 파일 디스크립터 한도는 4,096개로 기본 Lambda의 1,024개보다 큽니다. 실행 환경 OS는 Bottlerocket 기반입니다.

스케일링은 최소/최대 실행 환경 제한 안에서 트래픽에 따라 자동으로 이루어지고, 유휴 시 0으로 축소하는 scale-to-zero도 지원합니다. 2026-05-12부터는 Amazon EventBridge Scheduler로 일회성 또는 반복 일정을 정의해 용량 한도를 사전에 조정하는 스케줄 기반 스케일링이 추가되었습니다.

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 네 언어를 지원합니다. 워크플로를 별도 DSL이 아니라 이 언어들의 일반 코드로 그대로 쓴다는 점이 이 모델의 핵심입니다.

3.2 Step Functions와 어떻게 가를까

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

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

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

한도는 세 가지만 기억하면 됩니다. 리전당 실행은 500만 건이고, 버지니아, 오레곤, 아일랜드 리전은 1,000만 건입니다. 실행당 durable operation은 3,000개, 실행당 영속 데이터는 100MB이며 이 두 한도는 상향 신청이 불가능합니다.

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

04Lambda MicroVMs

MicroVMs는 Lambda의 격리 계층이던 Firecracker를 프리미티브로 직접 노출하는 모델입니다. AWS Compute Blog가 2026-07-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개까지입니다.

05기본 Lambda Functions의 설정 축

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

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

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

표 3. 패키징, 스토리지, 런타임, 아키텍처 축 요약
축 선택지 한도와 비고
패키징 - zip zip 아카이브 업로드 압축 50MB(API/콘솔 직접 업로드), 압축 해제 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는 프로덕션 워크로드 사용을 금지한다고 명시합니다(2026-08-25 발표).

5.2 호출 형태 5종 - 입구가 페이로드 한도를 정합니다

같은 함수라도 어떤 입구로 호출하느냐에 따라 페이로드 한도와 실패 처리 방식이 달라집니다. 입구는 크게 다섯 가지입니다.

  • 동기(RequestResponse) - 호출자가 응답을 기다리는 방식입니다. 요청과 응답 페이로드는 각 6MB까지입니다.
  • 비동기(Event) - 페이로드는 1MB이고 Lambda가 기본 2회 재시도합니다. 최종 실패 시 이벤트를 DLQ(Dead Letter Queue) 또는 on-failure destination으로 보냅니다.
  • 이벤트 소스 매핑 - 이벤트 폴러(event poller)라는 Lambda 측 리소스가 소스를 폴링해 함수를 호출합니다. 지원 소스는 SQS, Kinesis, DynamoDB, MSK, Amazon MQ, self-managed Apache Kafka, Amazon DocumentDB 7종입니다.
  • 응답 스트리밍 - 응답을 최대 200MB까지 스트리밍합니다. 첫 6MB는 대역폭 제한이 없고 이후 2MBps로 제한됩니다.
  • Function URL과 Lambda@Edge - Function URL은 함수에 부여되는 전용 HTTP(S) 엔드포인트로, 퍼블릭 인터넷 전용이라 PrivateLink를 지원하지 않습니다. Lambda@Edge는 CloudFront와 함께 동작합니다.

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

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

표 4. 동시성 3종과 스케일링 속도
항목 기본값과 한도 비고
온디맨드 동시성 리전당 기본 1,000 수만 단위까지 상향 요청 가능
예약 동시성 (reserved) 기본 최대 900 특정 함수 전용 몫을 확보. 100은 항상 unreserved로 남음. 추가 요금 없음
프로비저닝드 동시성 (provisioned) 초당 호출 한도 = 동시성 할당량의 10배 10배 규칙은 계정 레벨과 온디맨드에도 동일 적용
스케일링 속도 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가 자동으로 상향합니다. 새 계정에서 부하 테스트가 예상보다 일찍 스로틀되면 이 축소 상태를 먼저 확인해야 합니다.

결론: 한 문장으로 요약하면, Lambda는 이제 단일 실행 모델이 아니라 Functions, Managed Instances, Durable Functions, MicroVMs 네 가지 컴퓨트 프리미티브의 묶음이며, 서버리스 설계의 첫 질문은 "메모리를 얼마로 잡을까"가 아니라 "어느 실행 모델에서 시작할까"로 바뀌었습니다.

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

--참고 자료

1차 출처

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

AWS LAMBDA / FEATURE ANALYSIS

Lambda Is No Longer One Thing - All Four Execution Models and Every Configuration Axis

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 organizes them as of 2026-08 in two layers: the four execution models as layer 1, and the configuration axes inside base functions as layer 2.

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)

TL;DR

01The four execution models at a glance

As of August 2026, four distinct execution models live under the Lambda name. The per-invocation execution model we knew is now just one of them, Lambda Functions, and the other three differ in their very execution unit and isolation level. This section compares the four models in a single table and presents the branching logic for deciding which model to start from.

How much do the four models differ, and in what? 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) None 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.

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.

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.

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 and scaling

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.

Scaling happens automatically with traffic within minimum/maximum execution environment bounds, and scale-to-zero on idle is also supported. 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.

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 four languages: JavaScript, TypeScript, Python, and Java. The heart of this model is that you write workflows as plain code in these languages, not in a separate DSL.

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

Only three limits need remembering. Executions per region: 5 million, and 10 million in the Virginia, Oregon, and Ireland regions. Durable operations per execution: 3,000; persistent data per execution: 100MB - and these two limits cannot be raised.

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. The AWS Compute Blog announced it on 2026-07-10, and 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.

05Configuration axes of base Lambda Functions

Once you have chosen an execution model on layer 1, layer 2 is the set of 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 API/console upload), 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 explicitly prohibits their use for production workloads (announced 2026-08-25).

5.2 The five invocation types - the entry point sets the payload limit

Even for the same function, the payload limit and failure handling differ by which entry point invokes it. There are broadly five entry points.

  • Synchronous (RequestResponse) - the caller waits for the response. Request and response payloads are up to 6MB each.
  • 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.
  • Event source mapping - a Lambda-side resource called an event poller polls the source and invokes the function. Seven sources are supported: SQS, Kinesis, DynamoDB, MSK, Amazon MQ, self-managed Apache Kafka, and Amazon DocumentDB.
  • Response streaming - streams responses up to 200MB. The first 6MB has no bandwidth cap; after that, it is limited to 2MBps.
  • Function URLs and Lambda@Edge - 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.

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 900 by default Carves out a dedicated share for a specific function. 100 always remains unreserved. No extra charge
Provisioned concurrency Invocations-per-second limit = 10x the concurrency allocation The 10x rule applies equally at the account level and to on-demand
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
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.

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

Primary sources

What's New announcements (full text verified)