예약된 동시성은 함수가 사용할 동시 실행 용량을 확보하면서 상한을 정하는 설정이고, 프로비저닝된 동시성은 실행 환경을 미리 초기화해 시작 지연을 줄이는 유료 설정입니다. API의 첫 응답이 느리다는 이유로 예약된 동시성만 늘려도 콜드 스타트가 사라지지는 않습니다. 이 글은 일반적인 리전 내 Lambda 함수의 동기 API 호출을 기준으로, 두 설정의 선택과 적용 후 확인 방법을 설명합니다. 이벤트 소스별 별도 제한은 따로 확인해야 합니다.
혼동의 원인: 동시 실행 상한과 시작 준비를 같은 것으로 보기
동시성은 처리 중인 요청의 수이고 초당 요청 수와 다릅니다. 같은 요청률이라도 실행 시간이 길어지면 동시에 필요한 환경이 늘어납니다. 먼저 느린 시간이 초기화, 핸들러 실행, DB 연결 또는 외부 호출 중 어디에서 생기는지 나눕니다. 초기화와 무관한 느린 SQL이나 긴 네트워크 대기는 미리 준비한 환경에서도 남습니다. 공식 동시성 설명을 기준으로 기능 이름보다 해결할 증상을 먼저 정하세요.
| 판단 항목 | 예약된 동시성 | 프로비저닝된 동시성 |
| 주된 목적 | 함수 용량 확보와 동시 실행 상한 | 미리 초기화한 실행 환경 준비 |
| 콜드 스타트 | 새 환경 초기화가 필요할 수 있음 | 시작 지연 완화; 모든 지연 제거 보장 아님 |
| 적용 단위 | 함수 | 게시한 버전 또는 별칭 |
| 비용 확인 | 설정 자체 추가 요금 없음; 실행 비용 별도 | 준비 용량·활성 시간과 실행 요금 확인 |
| 설정 초과 | 함수 상한에서 스로틀링 | 남는 일반 용량 사용 가능 여부와 상한 확인 |
1. 오류율과 지연을 먼저 나누고 기준값을 기록한다
배포 버전·메모리·리전·호출 별칭과 관찰 시간을 기록하고 API의 응답 지연, 오류, Lambda 실행 시간을 같은 구간에서 봅니다. 함수 실행 시간만 보고 사용자가 기다린 전체 시간을 같다고 가정하지 않습니다. DB 연결 풀의 최대 연결 수와 하위 서비스 처리 한도도 함께 적어야 동시성을 늘린 뒤 발생하는 부하를 판단할 수 있습니다.
설정 검토용 가상 예시 — 운영 측정값 아님
문제 A: 특정 시간의 첫 요청만 느림 → 초기화 여부 확인
문제 B: 부하가 커질 때 Throttles 증가 → 동시성 상한·계정 풀 확인
문제 C: 모든 요청의 DB 대기가 증가 → 하위 DB 원인 먼저 확인예약된 동시성은 다른 함수가 쓰는 공유 용량에도 영향을 줍니다. 값을 0으로 두면 함수 처리를 의도적으로 막는 설정이 되므로 “자동 조절”이나 “제한 없음”으로 해석하지 않습니다. 계정 전체의 여유를 확인한 뒤 함수별 상한을 선택합니다. 설정 절차와 영향은 예약된 동시성 공식 문서에서 확인할 수 있습니다.
2. 시작 지연이 문제라면 실제 호출 버전까지 연결한다
프로비저닝된 동시성은 $LATEST에 설정할 수 없습니다. 게시한 버전 또는 별칭을 선택하고 API Gateway나 호출자가 바로 그 대상을 호출하는지 확인합니다. 별칭에 준비 용량을 설정해도 호출 경로가 다른 버전이나 $LATEST로 향하면 기대한 환경을 사용하지 않습니다. 할당 요청 직후가 아니라 준비 상태가 완료된 뒤 검증해야 합니다. 버전·별칭 적용 조건이 이 단계의 기준입니다.
가령 별칭 live가 버전 7을 가리키고 준비 용량을 설정한 상황을 가정해 보겠습니다. 배포 후 live가 새 버전으로 바뀌면 해당 배포의 준비 상태와 트래픽 전환 순서를 다시 확인합니다. 준비 용량보다 많은 동시 요청은 일반 환경으로 넘어가거나 예약 상한에서 제한될 수 있습니다. 두 값을 함께 쓰면 준비 용량이 함수의 예약 상한을 넘지 않는지도 확인합니다. 예시 버전 번호는 설명용이며 실제 배포 결과가 아닙니다.
3. 준비 용량의 시간과 실행 요금을 따로 계산한다
프로비저닝된 동시성은 요청이 없을 때도 활성화된 준비 용량의 비용을 검토해야 합니다. 메모리, 준비한 동시성, 활성 기간, 실제 요청과 실행 시간을 견적 입력값으로 나눕니다. 일정이 뚜렷하다면 필요한 구간의 사전 준비와 해제 책임도 정합니다. 이 글은 특정 리전의 금액이나 절감률을 가정하지 않습니다. 공식 가격표에서 선택한 리전·아키텍처와 과금 항목을 확인하세요.
확인 방법: 같은 별칭의 지표와 API 응답을 함께 본다
비운영 함수 또는 영향이 통제된 트래픽에서 같은 버전·메모리·요청 패턴으로 비교합니다. ConcurrentExecutions와 Throttles를 보고, 준비 용량에는 ProvisionedConcurrencyUtilization과 ProvisionedConcurrencySpilloverInvocations도 확인합니다. spillover는 준비된 환경 외의 일반 동시성에서 실행된 호출을 나타내므로 그 자체를 실패 건수로 세지 않습니다. 지표별 집계 방식은 공식 모니터링 문서를 따릅니다.
성공 기준은 “설정 저장”이 아니라 준비 완료, 올바른 호출 대상, 같은 조건의 응답 지연과 오류율, 하위 DB 상태, 예상하지 못한 비용 여부입니다. 문제가 생기면 이전 별칭·준비 용량·예약 상한을 기록한 변경 계획으로 복원합니다. 무조건 상한을 풀거나 요청 재시도를 늘리는 방식은 하위 시스템의 과부하와 중복 실행을 만들 수 있습니다.
FAQ
예약된 동시성을 켜면 항상 따뜻한 환경이 유지되나요? 아닙니다. 용량 제어와 실행 환경 사전 초기화는 다른 기능입니다.
프로비저닝된 동시성을 쓰면 콜드 스타트가 완전히 없어지나요? 초과 호출이나 환경 재설정 등의 조건을 확인해야 합니다. 모든 API 지연이 없어지는 것으로 설명하면 안 됩니다.
동시성을 늘리면 API가 항상 빨라지나요? DB나 외부 서비스가 병목이면 오히려 대기가 늘 수 있습니다. 원인을 나눈 뒤 같은 조건에서 확인하세요.
공식 출처와 관련 글
공식 자료 확인일은 2026년 10월 15일입니다. 설정·명령 예시는 문서로 확인했으며 AWS 계정이나 운영 서버에서 직접 실행한 결과가 아닙니다. 실제 적용 전 설치 버전·권한·대상 환경을 확인하세요. 가격과 기능은 확인일 기준으로 설명합니다.
관련 문제를 함께 확인하려면 EventBridge Scheduler와 서버 cron의 재시도·중복 실행 비교 글을 참고하세요.
'소프트웨어개발' 카테고리의 다른 글
| EBS gp3와 io2 비교: EC2 데이터베이스 지연·IOPS·비용 선택 기준 (0) | 2026.10.16 |
|---|---|
| PostgreSQL statement timeout 해결: 잠금 대기·세션 설정·트랜잭션 범위 점검 (0) | 2026.10.15 |
| Nginx 정적 파일 404 해결: root·alias 경로와 try_files 점검 순서 (0) | 2026.10.15 |
