AWS Lambda 90분 실행 시대: 서버리스와 배치의 경계가 바뀌었다
AWS는 2026년 9월 9일 Lambda Managed Instances에서 함수 실행 제한을 최대 90분으로 확대했습니다. 기존 15분보다 6배 긴 시간입니다. 데이터 처리, 미디어 변환, 금융 계산, AI 추론처럼 한 작업이 15분을 넘기기 쉬운 워크로드도 Lambda의 이벤트 기반 프로그래밍 모델로 처리할 선택지가 생겼습니다.
그러나 모든 Lambda 함수가 곧바로 90분 동안 실행되는 것은 아닙니다. 이번 변화에는 두 가지 중요한 조건이 있습니다.
- 실행 환경이 일반 Lambda가 아니라 Lambda Managed Instances(LMI)여야 합니다.
- 비동기 호출 또는 이벤트 소스 매핑(ESM)이어야 합니다. 동기 호출은 여전히 최대 15분입니다.
따라서 이번 발표의 핵심은 단순히 제한 숫자가 커졌다는 데 있지 않습니다. Lambda가 짧고 간헐적인 함수뿐 아니라, 예측 가능한 부하에서 오래 실행되는 데이터·AI 작업까지 포괄하는 방향으로 확장됐다는 점이 더 중요합니다.
이 글은 AWS의 2026년 9월 9일 공식 발표와 Lambda 개발자 문서를 기준으로 작성했습니다. 기능은 Lambda Managed Instances가 제공되는 리전에서 사용할 수 있으며, 실제 도입 전에는 대상 리전·인스턴스 유형·가격을 최신 문서에서 다시 확인해야 합니다.
1. 무엇이 정확히 90분으로 늘어났나?
Lambda 함수의 Timeout을 최대 5,400초로 설정할 수 있습니다. 다만 호출 방식에 따라 실제 상한이 다릅니다.
| 호출 방식 | Lambda Managed Instances 최대 실행 시간 | 주의점 |
|---|---|---|
| 비동기 호출 | 90분 | 실패·시간 초과 시 재시도와 실패 대상 설정 필요 |
| 이벤트 소스 매핑 | 90분 | 큐·스트림의 재시도와 배치 설정을 함께 조정 |
| 동기 호출 | 15분 | 함수 설정이 15분을 넘어도 동기 호출에는 15분 적용 |
| Amazon MQ·DocumentDB ESM | 15분 | 이번 90분 확장 대상에서 제외 |
함수 초기화 단계(Init phase)도 LMI에서 최대 15분으로 유지됩니다. 90분은 실제 함수 호출의 연속 실행 시간에 대한 상한이지, 초기화 제한까지 모두 늘어난 것은 아닙니다.
AWS CLI에서는 다음처럼 설정합니다.
aws lambda update-function-configuration \
--function-name my-data-processor \
--timeout 5400 \
--region ap-northeast-2
AWS SAM에서는 일반 함수와 같은 Timeout 속성을 사용합니다.
MyFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: my-data-processor
Runtime: python3.12
Handler: app.handler
Timeout: 5400
MemorySize: 10240
기존 런타임, 핸들러, IAM 실행 역할, VPC 설정 방식은 그대로 사용할 수 있습니다. 설정 변경은 이후 호출부터 적용되며, 이벤트 소스 매핑에는 전파 시간이 조금 걸릴 수 있습니다.
2. Lambda Managed Instances는 일반 Lambda와 무엇이 다른가?
Lambda Managed Instances는 Lambda 함수를 AWS 계정 안의 관리형 EC2 인스턴스에서 실행하는 용량 방식입니다. 사용자는 적합한 최신 EC2 인스턴스 계열과 네트워크 구성을 선택하지만, 인스턴스 수명 주기, 운영체제와 런타임 패치, 라우팅, 로드 밸런싱, 확장은 Lambda가 관리합니다.
일반 Lambda와의 차이를 요약하면 다음과 같습니다.
| 항목 | Lambda 기본 컴퓨팅 | Lambda Managed Instances |
|---|---|---|
| 실행 기반 | AWS의 멀티테넌트 Lambda 플릿 | 사용자 계정의 관리형 EC2 인스턴스 |
| 동시성 | 실행 환경 하나가 한 번에 호출 하나 처리 | 실행 환경 하나가 여러 호출을 동시에 처리 |
| 가격 모델 | 요청 수와 실행 시간 중심 | EC2 인스턴스 비용 + 관리 수수료 |
| 확장 방식 | 요청 증가에 맞춰 실행 환경 생성, 0까지 축소 가능 | CPU 사용률과 다중 동시성 포화를 보고 비동기 확장 |
| 적합한 부하 | 짧고 급격하게 변하는 이벤트 | 예측 가능한 고부하, 특수 하드웨어·네트워크가 필요한 작업 |
| 장시간 비동기 실행 | 최대 15분 | 최대 90분 |
LMI는 용량 공급자(capacity provider)를 중심으로 구성됩니다. 새 함수 버전을 게시하면 Lambda가 기본적으로 가용 영역 복원력을 위해 세 개의 인스턴스와 실행 환경을 준비한 뒤 버전을 활성화합니다. 트래픽이 없어도 최소 용량이 유지될 수 있으므로, 일반 Lambda처럼 “호출이 없으면 비용도 거의 0”이라는 가정을 그대로 적용하면 안 됩니다.
AWS 문서에 따르면 LMI 가격은 기반 EC2 인스턴스 비용에 15% 관리 수수료가 더해지는 구조입니다. Savings Plans와 Reserved Instances의 EC2 할인은 기반 컴퓨팅 비용에 적용될 수 있지만 관리 수수료에는 적용되지 않습니다. 90분 제한 자체에 별도 기능 요금은 없고 기존 LMI 가격이 적용됩니다.
3. 왜 이 변화가 중요한가?
기존 15분 제한은 Lambda 아키텍처를 결정하는 강한 경계였습니다. 처리 시간이 경계를 넘으면 작업을 잘게 나누거나 Step Functions로 연결하고, 컨테이너 기반의 ECS·Fargate 또는 AWS Batch로 옮기는 경우가 많았습니다.
90분 실행은 다음과 같은 작업의 선택지를 넓힙니다.
- 큰 파일을 읽어 변환하고 다른 저장소로 이동하는 ETL
- 고해상도 영상·음성의 인코딩과 후처리
- 몬테카를로 시뮬레이션과 대규모 금융 계산
- 모델 로딩과 전처리·후처리가 포함된 AI 추론
- 외부 시스템 응답이 느린 웹 수집과 대용량 파일 전송
- SQS, Kinesis, DynamoDB Streams에서 전달되는 긴 배치 처리
- 과학 계산과 문서 묶음 분석
기존 Lambda 코드와 이벤트 통합을 유지하면서 연속 실행 시간을 늘릴 수 있다는 점은 마이그레이션 비용을 줄입니다. 하지만 “90분 이내”라는 이유만으로 모든 배치 작업이 Lambda에 적합해지는 것은 아닙니다. 부하 형태, 실패 복구 방식, 컴퓨팅 비용, 필요한 운영 제어가 여전히 서비스 선택의 기준입니다.
4. 90분 실행과 Durable Functions는 어떻게 다른가?
함수 timeout과 durable execution timeout은 서로 다른 개념입니다.
- 함수 timeout: 한 번의 실제 함수 호출이 계속 실행될 수 있는 시간
- durable execution timeout: 여러 단계와 대기를 포함한 전체 워크플로의 경과 시간
Lambda Durable Functions는 step()과 wait() 같은 연산으로 실행 상태를 체크포인트에 저장합니다. 인프라 장애가 발생하면 처음부터 모든 계산을 반복하지 않고, 완료된 단계를 건너뛰며 마지막 체크포인트 이후 작업을 재생할 수 있습니다.
비동기로 호출된 다단계 durable execution은 전체 수명 주기가 최대 1년까지 이어질 수 있습니다. 이번 확장으로 LMI에서 그 안의 개별 비동기 호출이 최대 90분 연속 실행될 수 있게 됐습니다.
예를 들어 40분 걸리는 AI 추론이 35분째 장애로 중단됐다고 가정해 보겠습니다.
- 90분 timeout만 사용하면 새 호출이 처음부터 40분 작업을 다시 시작할 수 있습니다.
- Durable Functions와 중간 체크포인트를 사용하면 완료된 전처리나 추론 구간을 건너뛰고 복구할 수 있습니다.
작업을 다시 실행해도 비용과 결과에 문제가 없는 멱등 처리라면 긴 timeout만으로 충분할 수 있습니다. 재실행 비용이 크거나 외부 시스템에 부수 효과를 만드는 작업이라면 체크포인트와 보상 로직을 함께 설계해야 합니다.
5. 가장 먼저 점검할 것: 재시도와 멱등성
실행 가능 시간이 길어져도 “한 번만 정확히 실행”되는 것은 아닙니다. 호스트 장애, 네트워크 오류, timeout, 이벤트 소스의 재전달 때문에 같은 입력이 다시 처리될 수 있습니다.
비동기 Lambda는 실패하거나 시간 초과하면 설정된 정책에 따라 재시도하며, 기본적으로 최대 두 번 재시도합니다. 최종 실패 이벤트는 dead-letter queue 또는 on-failure destination으로 보낼 수 있습니다.
90분 작업이 재시작되면 컴퓨팅 시간뿐 아니라 외부 API 호출, 데이터 쓰기, 결제·메일 발송 같은 부수 효과도 반복될 수 있습니다. 다음 패턴이 필요합니다.
- 이벤트마다 안정적인 작업 ID를 부여합니다.
- 처리 시작·완료 상태를 DynamoDB 같은 외부 저장소에 기록합니다.
- 결과 저장에는 조건부 쓰기나 upsert를 사용합니다.
- 외부 API가 지원하면 idempotency key를 전달합니다.
- 긴 작업은 의미 있는 단위마다 체크포인트를 남깁니다.
- 종료 직전 남은 실행 시간을 확인해 안전하게 상태를 저장합니다.
- DLQ와 실패 대상에 쌓인 이벤트를 운영자가 재처리할 절차를 만듭니다.
긴 timeout은 실패 확률을 없애지 않습니다. 오히려 실패했을 때 잃는 시간이 커지므로 복구 설계의 중요성이 더 커집니다.
6. SQS에서는 가시성 제한 시간이 9시간까지 필요하다
AWS는 SQS 이벤트 소스 매핑의 visibility timeout을 Lambda 함수 timeout의 최소 6배로 설정하도록 권장합니다. Lambda가 앞선 배치를 처리하거나 throttling을 겪을 때 재시도할 시간을 확보하기 위해서입니다.
함수 timeout을 90분으로 설정하면 계산상 최소 가시성 제한 시간은 다음과 같습니다.
90분 × 6 = 540분 = 9시간
이 값이 맞지 않으면 동일 메시지가 첫 호출이 끝나기 전에 다시 보이거나, 이벤트 소스 매핑 설정이 실패할 수 있습니다. 함수 timeout만 늘리고 SQS 설정을 그대로 두면 중복 처리 가능성이 커집니다.
배치에 여러 레코드가 들어 있을 때 한 레코드의 실패 때문에 전체 배치를 다시 처리하지 않도록 partial batch failure reporting도 검토해야 합니다. 이 기능은 SQS, Kinesis, DynamoDB Streams, Amazon MSK, 자체 관리 Kafka 이벤트 소스 매핑에서 사용할 수 있습니다.
Kinesis와 DynamoDB Streams에서는 처리 시간이 길수록 샤드 뒤에 레코드가 쌓일 수 있으므로 다음 항목을 함께 측정해야 합니다.
- 최대 배치 윈도와 배치 크기
- 샤드당 처리량과 iterator age
- parallelization factor
- 실패 레코드 재시도와 bisect on error
- 전체 배치 재처리 비용
시간 제한을 늘리는 것만으로 스트림 처리량이 늘어나는 것은 아닙니다.
7. 다중 동시성이 만드는 새로운 코드 위험
일반 Lambda에서는 하나의 실행 환경이 한 시점에 호출 하나만 처리합니다. LMI에서는 하나의 실행 환경이 여러 호출을 동시에 처리할 수 있습니다. I/O 중심 서비스나 배치에서는 인스턴스 활용률을 높이는 장점이 있지만, 기존 함수 코드의 전제가 달라질 수 있습니다.
특히 다음 코드를 점검해야 합니다.
- 모듈 전역의 변경 가능한 변수
- 호출마다 구분되지 않는 임시 파일 이름
- 스레드 안전하지 않은 라이브러리와 클라이언트
- 요청별 인증 정보와 사용자 컨텍스트
- 프로세스 내부 캐시의 갱신 경쟁
- 연결 풀과 파일 디스크립터 상한
- CPU·메모리·디스크를 동시에 많이 쓰는 작업
예를 들어 전역 변수에 현재 사용자 ID를 저장하거나 /tmp/output.json처럼 고정 파일명을 사용하면 동시 호출끼리 데이터를 덮어쓸 수 있습니다. 요청 ID를 포함한 격리된 경로를 사용하고, 공유 상태에는 동시성 제어와 명확한 수명 주기를 적용해야 합니다.
LMI는 CPU 사용률과 동시성 포화 신호에 따라 비동기로 확장합니다. AWS 문서는 트래픽이 5분 안에 두 배보다 빠르게 증가하면 확장이 따라가는 동안 throttling이 보일 수 있다고 설명합니다. 갑작스러운 대규모 버스트보다는 예측 가능한 고부하에 더 잘 맞는 이유입니다.
8. 관측성은 “성공 횟수”보다 진행률이 중요하다
90분짜리 호출을 운영하면 완료와 실패 횟수만으로는 문제를 빨리 발견하기 어렵습니다. 작업이 살아 있지만 실제로 진전하지 않는 정지 상태를 구분해야 합니다.
CloudWatch, CloudTrail, X-Ray는 긴 호출의 전체 수명 주기를 기존 방식으로 기록합니다. 여기에 애플리케이션 수준 지표를 추가하는 것이 좋습니다.
- 전체 작업 중 완료된 항목 수와 비율
- 마지막 체크포인트 시간
- 항목당 처리 시간과 처리량
- 외부 API의 지연·오류·재시도 횟수
- 남은 Lambda 실행 시간
- SQS 메시지 연령과 재수신 횟수
- Kinesis iterator age
- LMI의 CPU·메모리·디스크·동시성 throttling
- 작업 ID별 비용과 재실행 시간
90분 timeout은 목표 실행 시간이 아닙니다. 정상 작업 시간이 20분이라면 25~30분을 운영 상한으로 두고, 그보다 오래 걸리는 호출을 별도 경보로 감지하는 편이 안전합니다.
9. 언제 LMI 90분을 선택해야 하나?
다음 조건이 많을수록 LMI의 긴 실행이 적합합니다.
- 기존 Lambda 이벤트 통합과 함수 코드를 유지하고 싶다.
- 작업이 비동기이며 15~90분 안에 안정적으로 끝난다.
- 부하가 지속적이거나 예측 가능하다.
- 특정 EC2 인스턴스 유형, CPU, 메모리, 네트워크 특성이 필요하다.
- 한 실행 환경의 다중 동시성을 안전하게 처리할 수 있다.
- 인스턴스 기반 비용과 최소 용량을 충분히 활용할 트래픽이 있다.
- 재시도, 멱등성, 체크포인트를 설계할 수 있다.
반대로 다음 상황에서는 다른 서비스가 더 자연스러울 수 있습니다.
| 요구사항 | 검토할 서비스·패턴 |
|---|---|
| 호출이 짧고 매우 간헐적이며 0까지 축소가 중요 | Lambda 기본 컴퓨팅 |
| 여러 단계를 시각적으로 조정하고 분기·대기가 많음 | Step Functions 또는 Durable Functions |
| 90분을 자주 넘기거나 실행 시간 예측이 어려움 | ECS/Fargate, AWS Batch |
| 프로세스·네트워크·운영체제를 세밀하게 제어해야 함 | ECS 또는 EC2 |
| GPU 중심의 대규모 학습 작업 | AWS Batch, SageMaker 등 목적형 서비스 |
| 사용자 요청에 대한 긴 동기 응답이 필요 | 작업 접수 후 상태 조회·콜백으로 비동기화 |
이는 절대적인 규칙이 아니라 설계 출발점입니다. 같은 작업을 작은 표본으로 실행해 완료 시간 분포, 인스턴스 활용률, 재시도 비용, 운영 복잡도를 비교해야 합니다.
10. 도입 순서
1단계: 현재 15분 우회 구조를 찾는다
시간 제한 때문에 파일을 인위적으로 잘게 나누거나, 중간 큐와 함수를 지나치게 많이 연결한 작업을 찾습니다. 그중 90분 안에 일관되게 끝나는 비동기 작업을 후보로 고릅니다.
2단계: 실행 시간의 평균이 아니라 상위 백분위를 본다
평균 40분이어도 일부 작업이 90분을 넘으면 timeout과 재시도가 반복됩니다. 입력 크기별 p95·p99 실행 시간과 외부 서비스 지연을 측정합니다.
3단계: LMI 비용 모델을 비교한다
기존 Lambda의 요청·실행 시간 비용, LMI의 EC2 기반 비용과 관리 수수료, ECS/Fargate 또는 Batch의 비용을 동일한 처리량으로 비교합니다. 유휴 시간과 최소 용량도 포함해야 합니다.
4단계: 동시성 안전성을 시험한다
같은 실행 환경에서 여러 호출이 동시에 실행된다는 전제로 부하 테스트를 합니다. 전역 상태, 임시 파일, 연결 풀, 메모리 압박을 확인합니다.
5단계: 실패를 의도적으로 주입한다
10분, 40분, 종료 직전 단계에서 프로세스 장애와 네트워크 오류를 만들어 봅니다. 데이터 중복 여부, 체크포인트 복구, DLQ 이동, 재처리 절차를 검증합니다.
6단계: 이벤트 소스 설정을 함께 배포한다
SQS 가시성 제한, 배치 실패 보고, 스트림 병렬화와 재시도 설정을 함수 timeout과 하나의 변경 단위로 관리합니다.
7단계: 점진적으로 트래픽을 옮긴다
작은 비율의 이벤트부터 새 버전으로 보내 처리량, throttling, 오류율, 비용을 비교합니다. 긴 timeout을 켰다는 이유로 처음부터 모든 배치를 옮기지 않습니다.
11. 실무 체크리스트
- Lambda Managed Instances가 대상 리전에서 제공되는가?
- 호출 방식이 비동기 또는 지원되는 이벤트 소스 매핑인가?
- 동기 호출의 최대 15분 제한을 혼동하지 않았는가?
- 작업의 p99 실행 시간이 90분보다 충분히 짧은가?
- 함수 초기화가 15분 안에 끝나는가?
- 동일 이벤트 재처리에 안전한 멱등성을 갖췄는가?
- 의미 있는 간격으로 체크포인트를 남기는가?
- SQS visibility timeout을 함수 timeout의 최소 6배로 맞췄는가?
- 부분 배치 실패 보고와 DLQ를 구성했는가?
- 스트림 iterator age와 backlog를 감시하는가?
- 코드와 라이브러리가 다중 동시성에 안전한가?
- 요청별 상태와 임시 파일이 격리돼 있는가?
- LMI의 최소 용량과 인스턴스 기반 비용을 반영했는가?
- 정상 처리 시간보다 오래 걸리는 정지 작업을 감지하는가?
- 90분을 넘기는 작업의 대체 실행 경로가 있는가?
결론
AWS Lambda의 90분 timeout은 서버리스 함수의 적용 범위를 크게 넓혔습니다. 특히 기존 15분 제한 때문에 Lambda 밖으로 밀려났던 데이터 처리, 미디어 변환, 금융 계산, AI 추론을 이벤트 기반 함수 모델 안에서 실행할 현실적인 경로가 생겼습니다.
동시에 이번 기능은 일반 Lambda의 단순한 상향 조정이 아닙니다. Lambda Managed Instances의 EC2 기반 비용, 최소 용량, 비동기 확장, 다중 동시성을 이해해야 하며, 동기 호출은 여전히 15분입니다.
가장 중요한 설계 원칙은 timeout을 늘리는 것보다 실패 비용을 줄이는 것입니다. 멱등성, 체크포인트, 큐 가시성 제한, 부분 배치 실패, 진행률 관측을 함께 설계해야 90분 실행이 운영상의 이점이 됩니다.
서버리스와 배치의 경계는 넓어졌지만 사라진 것은 아닙니다. 앞으로의 클라우드 설계자는 “15분을 넘으면 컨테이너”라는 고정 규칙 대신, 호출 방식·부하 형태·복구 모델·비용 구조를 기준으로 컴퓨팅 방식을 선택해야 합니다.
참고 자료
- AWS Compute Blog, Announcing 90-minute function timeout on AWS Lambda Managed Instances (2026-09-09)
- AWS What’s New, AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances (2026-09-09)
- AWS Lambda Developer Guide, Lambda Managed Instances
- AWS Lambda Developer Guide, Scaling Lambda Managed Instances
- AWS Lambda Developer Guide, Understanding the Lambda Managed Instances execution environment
- AWS Lambda Developer Guide, Event source mappings with durable functions
기능 제공 지역, 지원되는 이벤트 소스, 한도와 가격은 변경될 수 있습니다. 실제 운영 환경에 적용하기 전에 AWS의 최신 개발자 문서와 대상 리전의 콘솔 표시를 함께 확인해야 합니다.