Mar 24, 2026

마지막 업데이트 Mar 30, 2026

AWS Lambda Timeout: 무엇부터 확인할까?

AWS Lambda 가 timeout 될 때 문제는 단순히 timeout 값이 너무 짧다는 것만이 아닌 경우가 많습니다. 실제로는 느린 downstream call, 부족한 메모리 크기, cold start 비용, batch 또는 retry 증폭, 혹은 handler 가 한 번에 너무 많은 일을 하는 경우가 많습니다.

짧게 말하면 핵심은 이것입니다. timeout 값을 올리기 전에 실제 실행 시간과 downstream latency 를 먼저 분리해서 봐야 합니다. timeout 을 늘리면 증상은 잠깐 가려질 수 있지만, 함수가 CPU-bound 인지, I/O 를 기다리는지, 다른 서비스를 기다리는지는 여전히 설명되지 않습니다.

timeout 값보다 duration 경로를 먼저 본다

Lambda timeout 은 duration 이야기의 마지막 결과입니다.

잘 보려면 총 시간을 아래로 나눠야 합니다.

initialization time
handler execution time
downstream dependency wait time
retry 또는 batch 증폭

timeout 값 하나만 보는 것보다 훨씬 유용한 구분입니다.

timeout incident 는 실전에서 어떻게 보이나

운영 환경에서는 보통 이렇게 나타납니다.

duration 이 configured limit 근처까지 꾸준히 올라간다
DB 나 API 대기 시간이 길어진다
첫 invocation 이 warm invocation 보다 훨씬 느리다
queue / stream 처리에서 한 번의 invocation 이 예상보다 많은 work 를 한다
팀이 timeout 만 늘리는데 실제 latency 는 계속 나빠진다

겉으로는 모두 timeout 이지만, 실제 fix 는 어떤 구간이 커지는지에 따라 달라집니다.

흔한 원인

1. 함수가 느린 downstream service 를 기다린다

DB, third-party API, VPC 안의 서비스, 내부 dependency 가 전체 duration 의 대부분을 먹는 경우가 많습니다.

대기 시간이 대부분이라면 timeout 을 늘려도 같은 bottleneck 만 늦게 드러납니다.

2. 메모리가 workload 에 비해 너무 낮다

Lambda 에서는 memory 를 낮추면 CPU allocation 도 같이 낮아집니다.

즉 CPU-heavy function 은 메모리 보수적 설정만으로도 예상보다 훨씬 느려질 수 있습니다.

3. cold start 와 initialization work 가 너무 무겁다

큰 패키지, 무거운 import, 비싼 startup logic, 넓은 dependency loading 이 첫 invocation 을 timeout 근처까지 밀어 올릴 수 있습니다.

bursty traffic 일수록 더 잘 보입니다.

4. retry, event size, batch size 가 총 work 를 키운다

stream / queue 연동은 한 invocation 이 팀이 생각하는 것보다 더 많은 일을 하게 만들 수 있습니다.

즉 timeout 하나가 “한 줄이 느리다” 보다 “한 invocation 이 너무 많은 레코드를 처리한다” 일 수 있습니다.

5. 함수 경로가 동기적으로 너무 많은 일을 한다

인프라 문제가 아니라 handler 가 단순히 너무 많은 일을 하기 때문인 경우도 많습니다.

기능이 커지거나 handler 안 fan-out 이 숨겨져 있을 때 자주 드러납니다.

실전 점검 순서

1. CloudWatch 에서 timeout 설정과 실제 duration 을 비교한다

지속적으로 limit 근처인지, 가끔만 timeout 되는지부터 확인해야 합니다.

2. init time, handler time, downstream dependency time 을 분리한다

Lambda timeout 디버깅에서 가장 큰 분기입니다.

init 이 크면 cold start 또는 package shape 문제이고,

handler time 이 크면 runtime work 또는 downstream wait 문제입니다.

3. memory sizing 이 CPU-bound work 를 느리게 만드는지 본다

의미 있는 계산 작업이 있다면 memory size 는 단순 메모리 ceiling 이 아니라 성능 설정입니다.

4. retry, batch, event-size 가정을 점검한다

많은 timeout incident 는 느린 한 줄보다 hidden workload amplification 에서 시작합니다.

5. 느린 경로를 이해한 뒤에만 timeout 을 늘린다

timeout 증가가 필요할 때도 있지만, 진단을 대신하면 안 됩니다.

빠른 명령

aws lambda get-function-configuration --function-name <name>
aws logs tail /aws/lambda/<name> --follow
aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Duration ...

configured timeout, 실제 로그 동작, duration 지표를 같이 보고 나서 timeout 을 늘릴지 판단하는 편이 좋습니다.

duration 이 timeout 근처까지 오르는지, downstream wait 가 긴지, cold start 또는 initialization 이 총 runtime 의 대부분을 먹는지 보세요.

느린 경로를 찾은 뒤 무엇을 바꾸면 좋나

downstream latency 가 크다면

Lambda 시간보다 dependency 를 고치거나 영향 범위를 줄여야 합니다.

CPU-bound work 가 느리다면

메모리를 의도적으로 올리거나 동기 계산량을 줄여야 합니다.

cold start 가 크다면

dependency 를 줄이고 initialization work 를 줄이거나 startup 동작을 다시 봐야 합니다.

batch / retry 증폭이 크다면

invocation 당 work 양을 줄이고 event 가정을 다시 봐야 합니다.

handler 가 너무 많은 일을 한다면

timeout budget 과 실제 work unit 이 맞도록 함수 경로를 나누는 편이 좋습니다.

장애 중에 던져볼 질문

이 질문이 가장 유용한 경우가 많습니다.

Lambda 가 timeout 되는 이유가 함수 자체가 느려서인가, initialization 이 무거워서인가, 아니면 대부분 다른 것을 기다리기 때문인가?

이 구분이 보통 fix 를 결정합니다.

FAQ

Q. timeout 을 늘리는 게 가장 빠른 해결인가

일시 완화는 될 수 있지만, 진짜 성능 병목을 설명해 주진 않습니다.

Q. 가장 빠른 첫 단계는 무엇인가

CloudWatch duration 을 보고, 다른 서비스를 기다리는지 initialization 시간이 큰지 구분하는 것입니다.

Q. 메모리 크기가 timeout 에도 영향을 주나

그렇습니다. 더 많은 memory 는 더 많은 CPU 도 주기 때문에 total duration 을 줄일 수 있습니다.

Q. cold start 가 항상 메인 원인인가

아닙니다. downstream wait 나 oversized handler work 가 더 큰 원인인 경우도 많습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.