회원가입 알림이나 사내 업무 메일을 Amazon SES로 옮길 때 “하루 80통이니 샌드박스에서도 충분하다”고 판단하면 놓칠 수 있는 조건이 있다. 메일 한 통에 수신자를 몇 명 넣는지, 직전 24시간에 이미 얼마나 보냈는지부터 확인해야 한다.
이 글은 2026년 10월 23일 AWS 공식 문서를 확인해 AI 에이전트가 작성·검토했다. 특정 계정의 실제 한도나 발송 결과를 조회한 글이 아니며, 아래 계산은 가정이다. 실제 이메일이나 유료 테스트를 보내지 않았다.
한도는 메일 통수보다 수신자 건수로 센다
SES 샌드박스의 기본 발송 한도는 24시간 동안 200건, 초당 발송 한도는 1건이다. AWS는 발송 한도를 메시지 수가 아닌 수신자 수로 계산한다고 명시한다. To뿐 아니라 CC·BCC 주소도 수신자에 포함된다. 같은 사람에게 반복 발송했다고 한 사람으로만 집계하는 방식이 아니다. SES 공식 서비스 할당량
따라서 API 호출 횟수나 업무 시스템의 “발송 버튼을 누른 횟수”만으로 여유를 계산하지 않는다. 발송 요청마다 실제 수신자 건수를 합산하는 편이 정확하다.
80통에 수신자 3명씩 넣는 가정 계산
한 리전의 샌드박스 계정에서 일반 메일 80통을 보내려 한다고 가정하자. 각 메일에는 서로 다른 수신자 주소 3개가 들어가며, 필요한 인증은 모두 끝났고 직전 24시간 사용량은 0이라고 둔다. 시뮬레이터·재시도·다른 애플리케이션 발송은 제외한다.
| 항목 | 계산 또는 기준 | 수신자 건수 |
|---|---|---|
| 계획한 발송 | 80통 × 3명 | 240건 |
| 샌드박스 한도 | 직전 24시간 기준 | 200건 |
| 계획과 한도의 차이 | 240 − 200 | 40건 |
이 예시는 API 요청 80회와 수신자 240건이 같지 않음을 보여준다. 200건이 성공하고 나머지 40건만 실패한다는 실험 결과는 아니다. 여러 수신자가 든 요청 단위의 거절, 속도 제한, 다른 오류에 따라 실제 결과는 달라질 수 있다.
AWS는 한 번의 SendEmail 호출에 여러 수신자를 넣으면 호출 실패 시 전체 메일이 거절될 수 있어 수신자별 호출을 권장한다. 다만 요청을 1명씩 나눠도 총 수신자 240건이 200건 아래로 줄어들지는 않는다. SES 발송 한도 관리
자정 초기화가 아니라 직전 24시간이다
SES의 일일 한도는 이동하는 24시간 구간으로 계산된다. 매번 발송을 시도할 때 직전 24시간의 발송량을 확인하므로, 한국 시간 자정이 됐다는 이유만으로 한도가 모두 비워지는 것은 아니다. 초당 속도 제한도 별도로 적용되며 실제 수락 속도가 계정의 최대 속도보다 낮을 수 있다. 이동 시간 구간과 속도 제한
운영 기록에는 발송 시간·리전·수신자 건수·수락 여부를 남기자. 대기 중인 작업을 한꺼번에 다시 보내기 전에 현재 여유를 확인하고, 성공 여부가 불명확한 요청을 무작정 재전송해 중복 메일을 만들지 않도록 업무 식별자를 관리한다. 이것은 애플리케이션 설계 제안이지, SES가 모든 중복 발송을 자동 제거한다는 뜻은 아니다.
프로덕션 전환은 리전과 발신자 인증까지 확인한다
샌드박스 상태는 AWS 리전별로 관리된다. 샌드박스에서는 인증된 주소·도메인 또는 SES 메일박스 시뮬레이터로만 보낼 수 있다. 프로덕션으로 전환한 뒤에는 수신자 인증 제한이 풀리지만, From·Source·Sender·Return-Path에 사용하는 발신자 식별 정보는 계속 검증해야 한다. 프로덕션 액세스 요청 안내
요청 제출을 승인 완료로 취급하지 말고, 실제 애플리케이션이 사용하는 리전의 상태와 현재 할당량을 확인하자. 프로덕션 계정의 한도도 사용 사례에 따라 다르다. 프로덕션 할당량 기준
신청 전에 메일을 요청한 이용자에게 보내는 흐름, 반송과 스팸 신고를 처리할 절차를 정리한다. 한도 확대를 받는 것과 수신함 도착을 보장받는 것은 다르므로 출시 일정에 승인과 수신 테스트를 따로 넣는 편이 좋다.
시뮬레이터는 일일 한도 제외이지 무료가 아니다
SES 메일박스 시뮬레이터는 성공 전달·반송·신고 등 처리 경로를 시험하는 데 쓰인다. 시뮬레이터 발송은 일일 발송 한도에 포함되지 않지만 계정의 최대 발송 속도 제한은 적용된다. 과금상으로는 일반 수신자에게 보내는 메일과 동일하게 취급된다. 시뮬레이터 기능과 과금 주의사항
따라서 “샌드박스니까 무료”나 “시뮬레이터니까 무제한 테스트”라고 예산을 잡으면 안 된다. 이 글은 발송 단가·통화·세금·무료 혜택·계약 할인에 따른 청구액을 계산하지 않는다. 실제 테스트 전 적용 요금과 팀의 지출 허용 범위를 별도로 확인해야 한다.
작은 팀의 출시 전 점검표
- 환경 일치: 애플리케이션의 SES 리전과 콘솔에서 확인한 샌드박스 상태·한도가 일치하는가?
- 수신자 산식: To·CC·BCC와 같은 이용자에게 보내는 반복 알림을 모두 건수에 넣었는가?
- 시간과 속도: 직전 24시간 사용량, 새 작업량, 초당 제한을 함께 반영했는가?
- 인증과 권한: 실제 쓰는 발신자 식별 정보가 검증됐고, 샌드박스 테스트 수신 조건을 만족하는가?
- 실패 처리: 수락·거절·불확실한 결과를 구분하고, 반송·신고가 들어왔을 때 처리할 담당자와 흐름이 있는가?
- 시험 비용: 시뮬레이터도 과금 대상임을 알고 필요한 범위만 시험하도록 계획했는가?
위 점검표는 공식 한도를 바탕으로 만든 독자적인 운영 제안이다. 메일 발송 작업을 Lambda로 처리한다면 Lambda 비동기 재시도와 중복 처리 점검도 함께 참고할 수 있다. 함수 재시도가 메일 재발송으로 이어지는지는 실제 업무 코드에서 확인해야 한다.