Lambda로 서버리스 워크로드를 설계하다 보면 비슷한 고민을 반복해서 만나게 됩니다. 15분 한도를 넘는 장기 워크 플로우는 어떻게 처리할지, 호출 사이에 실행 환경이 멈추는 freeze(일시 정지) 동작이 상시 트래픽 서비스에 맞는지, 사용자나 AI가 생성한 코드를 어디서 안전하게 실행할지 같은 질문입니다. 지금까지는 이 답을 Lambda 외부에서 찾는 경우가 많았습니다. 워크 플로우는 AWS Step Functions로 옮기고, 상시 워크로드는 […] ||
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가지 축으로 놓고 보면 차이가 분명해집니다.
모델
실행 단위
최대 지속
격리
상태 유지
주 용도
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가 생성한 코드의 샌드박스
표 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는 운영
AWS Lambda의 4가지 실행 모델 – 구조와 선택 기준
생성 일시
2026/08/28 07:06
최종 편집 일시
2026/08/28 07:06
태그
AWS
파일과 미디어