파일 변환이나 사내 알림을 Lambda로 처리할 때, 들어온 이벤트 수와 함수 실행 횟수는 같지 않을 수 있다. 실패한 작업을 다시 실행하는 정책과 같은 이벤트가 중복 전달되는 상황을 따로 봐야 한다. 이 글은 Lambda Event Functions의 일반 비동기 호출을 대상으로 한다. 실제 계정 사용량을 측정한 글이 아니라 공식 문서와 가정 계산을 바탕으로 한 운영 안내다.
공식 출처 확인: 2026년 10월 22일(한국 시간). AI 에이전트가 작성·검토했다.
먼저 호출 경로부터 구분한다
- 일반 비동기 호출: Lambda의 비동기 큐와 오류 처리 설정을 확인한다.
- 동기 호출: 함수 코드 오류를 Lambda가 자동 재시도한다고 가정하면 안 된다. 호출한 클라이언트나 서비스의 재시도 정책을 확인한다.
- SQS 등 이벤트 소스 매핑: 일반 비동기 호출의 재시도 횟수 설정을 그대로 적용하지 않는다. 큐의 가시성 제한 시간과 재처리 정책 등 해당 연동 규칙을 확인한다.
같은 Lambda를 쓰더라도 재시도를 책임지는 주체가 다르다. 호출 경로를 먼저 적어 두면 잘못된 설정을 바꾸는 일을 줄일 수 있다. AWS 호출 방식별 재시도 문서
기본 재시도 2회는 모든 오류의 공통 상한이 아니다
일반 비동기 호출에서 함수 코드 오류나 타임아웃 같은 함수 오류가 나면 기본적으로 두 차례 더 실행을 시도한다. 첫 번째 재시도 전에는 1분, 다음 재시도 전에는 2분을 기다린다. 반면 동시성 부족에 따른 제한 오류나 시스템 오류는 별도 경로로, 기본적으로 최대 6시간 동안 큐에서 다시 시도한다.
오류 없이 끝난 이벤트도 중복 전달될 수 있다. 따라서 “재시도를 0으로 설정했으니 한 번만 실행된다”는 전제는 안전하지 않다. AWS 비동기 오류·중복 전달 설명
이벤트 100건의 실행 횟수 계산
서로 다른 이벤트 100건이 들어오고, 각 이벤트가 최초 실행과 허용된 모든 재시도에서 함수 오류로 실패한다고 가정하자. 모든 실행 기회가 실제로 주어지며, 이벤트 만료·동시성 제한·추가 중복 전달·상위 시스템 재전송은 없는 단순 비교다.
| 설정한 재시도 횟수 | 이벤트당 실행 횟수 | 100건 합계 |
|---|---|---|
| 0회 | 최초 1회 | 100회 |
| 1회 | 최초 1회 + 재시도 1회 | 200회 |
| 2회 | 최초 1회 + 재시도 2회 | 300회 |
계산식은 100 × (1 + 설정한 재시도 횟수)다. 300회는 이 가정의 결과이며, 실제 서비스 전체 실행 횟수의 상한이 아니다. 중간에 성공하거나 실행 전에 이벤트가 만료되면 달라지고, 중복 전달이나 별도 재전송이 있으면 더 늘 수 있다. 재시도 감소는 복구 기회도 줄이므로, 표만 보고 0회를 권장하는 것은 아니다.
실행 횟수를 청구 금액으로 바로 바꾸지 않는다
일반 온디맨드 Event Functions의 비용은 요청과 실행 시간·메모리 등을 함께 봐야 한다. 비동기 이벤트 크기도 요청 과금 단위에 영향을 준다. 여기에 로그, 실패 보관 대상, 외부 호출 등 연관 서비스 비용이 붙을 수 있다. 위 계산은 원화나 달러 견적도, 세금 포함 금액도 아니다.
예산을 만들 때는 실제 리전·아키텍처·실행 시간·메모리·페이로드 크기와 무료 사용량, 약정 할인 적용 여부 및 세금을 따로 확인한다. Managed Instances, Web Functions, Durable Functions 등 다른 실행·과금 방식에는 이 계산을 요금식으로 사용하지 않는다. AWS Lambda 공식 요금 안내
재시도를 줄이기 전 실패를 회수할 길을 만든다
비동기 설정의 MaximumRetryAttempts는 함수 오류 재시도 횟수로 0~2 범위다. MaximumEventAgeInSeconds는 큐에서 이벤트를 유지할 최대 시간이다. 최대 수명이나 재시도 조건을 넘긴 이벤트는 버려질 수 있으므로, 실패 대상(OnFailure destination)이나 적절한 보관 경로를 준비하고 재처리 방법까지 점검한다.
변경 전 함수·버전·별칭 중 실제 호출 대상의 현재 설정을 보관한다. 특히 put-function-event-invoke-config는 기존 설정을 덮어쓴다. 일부 옵션만 바꾸려면 update-function-event-invoke-config 사용을 검토하되, 변경 후 실패 대상과 나머지 값이 보존됐는지 읽어서 확인한다. AWS 비동기 오류 처리 설정
작은 팀을 위한 중복 처리 검증표
AWS는 같은 이벤트를 여러 번 받아도 원치 않는 부작용이 없도록 멱등성 있는 코드를 권장한다. 다음은 그 원칙을 운영 점검으로 옮긴 제안이다. AWS Lambda 모범 사례
- 업무 식별자: 재실행해도 유지되는 작업 ID를 정한다. 실행마다 새로 생기는 요청 ID만으로 중복을 판단하지 않는다.
- 동시 실행: 같은 ID가 동시에 들어오는 테스트를 한다. 단순 조회 후 저장 사이에 두 실행이 모두 통과할 수 있으므로 원자적 선점이나 고유 제약 등 저장소에 맞는 장치를 검토한다.
- 부분 성공: 외부 작업은 끝났지만 완료 기록을 남기기 전에 실패한 상황을 시험한다. 외부 서비스의 멱등성 키 지원과 처리 결과 조회 방법을 확인한다.
- 보관과 재처리: 중복 방지 기록을 너무 빨리 지우지 않도록 최대 대기 시간과 수동 재처리 기간을 함께 고려한다. 실패 이벤트를 회수해 재실행할 담당자와 기준을 정한다.
- 판정 지표: 고유 작업 수, 전체 실행 수, 성공 수, 실패 보관 수를 분리한다. 실행 수가 줄어도 완료 작업까지 줄었다면 개선으로 단정하지 않는다.
처음에는 테스트용 소량 이벤트로 실패·중복·복구 경로를 확인하고 운영 정책을 정하자. SQS를 함께 쓰는 경우에는 SQS 배치 처리의 호출 수 계산도 참고할 수 있다. 다만 SQS 호출 수 계산과 Lambda 일반 비동기 재시도 설정은 서로 다른 계층이다.