SQS vs SNS vs EventBridge: 메시징 서비스 선택 기준
서비스를 나누기 시작하면 곧바로 만나는 질문이 있습니다. “이 메시지를 SQS, SNS, EventBridge 중 어디로 보내야 하나요?“입니다. 결론을 먼저 적으면, 소비자 하나가 처리할 작업을 쌓아 두는 버퍼는 SQS, 같은 메시지를 여러 구독자에게 즉시 밀어주는 팬아웃은 SNS, 이벤트 내용을 보고 규칙으로 라우팅하거나 SaaS 연동·스케줄이 필요하면 EventBridge입니다. 그리고 실무 정답은 하나를 고르는 것이 아니라 조합인 경우가 많습니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | SQS | SNS | EventBridge |
|---|---|---|---|
| 모델 | 큐 (1:1) | pub/sub (1:N 푸시) | 이벤트 버스 (규칙 라우팅) |
| 전달 방식 | 소비자가 폴링 | 구독자에게 푸시 | 규칙 매칭 후 대상 호출 |
| 메시지 보존 | 기본 4일, 최대 14일 | 없음 (전달 실패 시 재시도만) | 없음 (아카이브는 별도 기능) |
| 순서 보장 | FIFO 큐로 가능 | FIFO 토픽으로 가능 | 없음 |
| 요금 (100만 건당) | 약 $0.40 (FIFO $0.50) | 발행 약 $0.50 | 커스텀 이벤트 약 $1.00 |
모델 차이: 누가 가져가고, 언제 사라지는가 #
SQS는 큐입니다. 생산자가 메시지를 넣으면 소비자가 폴링으로 꺼내 처리하고 삭제합니다. 소비자가 죽어도 메시지는 큐에 남고(기본 4일, 최대 14일), 처리 중인 메시지는 visibility timeout 동안 다른 소비자에게 보이지 않다가 처리 실패 시 다시 나타납니다. 지정 횟수만큼 실패한 메시지를 DLQ(데드 레터 큐)로 빼는 재시도 체계까지, “한 번 받은 작업을 잃어버리지 않는 것“에 최적화된 서비스입니다. 트래픽 스파이크를 큐 길이로 흡수하는 버퍼 역할이 본업입니다.
SNS는 pub/sub입니다. 토픽에 발행하면 구독자 전원에게 즉시 푸시됩니다. 구독자는 SQS 큐, Lambda, HTTP 엔드포인트, 이메일, 모바일 푸시까지 다양하고, 필터 정책으로 구독자마다 받을 메시지를 거를 수 있습니다. 핵심 제약은 보존이 없다는 것입니다. 전달에 실패하면 재시도 정책만큼 다시 시도하고 끝이며, 나중에 구독을 추가해도 과거 메시지는 받을 수 없습니다.
EventBridge는 이벤트 버스입니다. 발행자는 버스에 이벤트를 던질 뿐 누가 받는지 모르고, 수신 측은 이벤트 JSON 내용을 조건으로 하는 규칙을 만들어 매칭되는 이벤트만 받습니다. 차별점은 셋입니다. S3, EC2 같은 AWS 서비스 이벤트가 기본 버스로 자동 유입되고, Datadog, Stripe 같은 SaaS 파트너 이벤트를 받을 수 있으며, 아카이브·리플레이와 스케줄러(cron 대체)가 붙어 있습니다. 대상도 Lambda, SQS, Step Functions 등 20종 이상입니다.
요금: 단가 차이보다 과금 단위를 봅니다 #
- SQS: 100만 요청당 약 $0.40(FIFO $0.50), 매월 100만 요청 무료. 요청은 64KB 청크 단위라 256KB 메시지 하나는 요청 4건으로 계산됩니다. 또 하나, 빈 큐를 짧은 간격으로 폴링하는 것도 전부 요청 수에 들어가므로 롱 폴링(WaitTimeSeconds 20초)이 기본값이어야 합니다.
- SNS: 발행 100만 건당 약 $0.50, 매월 100만 발행 무료. SQS와 Lambda로의 전달은 무료이고 HTTP 전달은 100만 건당 약 $0.60이 추가됩니다.
- EventBridge: 커스텀 이벤트 100만 건당 약 $1.00으로 셋 중 가장 비싸고 무료 티어도 없습니다. 대신 기본 버스로 들어오는 AWS 서비스 이벤트는 과금되지 않습니다. 과금은 역시 64KB 단위입니다.
셋 다 100만 건에 $1 안팎이라 웬만한 규모에서는 요금이 결정 변수가 아닙니다. 요금이 문제가 되는 것은 억 단위 이벤트를 다루는 경우이고, 그때는 EventBridge와 SQS의 2.5배 단가 차이가 청구서에 그대로 나타납니다.
조합 패턴: 고르는 것이 아니라 잇는 것 #
- SNS → SQS 팬아웃: 주문 이벤트를 SNS 토픽에 발행하고 결제, 배송, 알림 서비스가 각자의 SQS 큐로 구독합니다. 팬아웃(SNS)과 유실 방지 버퍼(SQS)를 동시에 얻는, 이 조합이 가장 흔한 정석입니다. 소비자가 죽어 있어도 메시지는 각자의 큐에 쌓여 있습니다.
- EventBridge → SQS: 규칙 라우팅으로 거른 이벤트를 큐에 쌓아 소비 속도를 소비자가 정하게 합니다. S3 이벤트를 받아 처리하는 파이프라인의 표준형입니다.
- 트리거로서의 Lambda 연계: 셋 모두 Lambda를 직접 호출할 수 있고, 이벤트 기반 워크로드라면 컴퓨팅 쪽 선택은 Lambda vs Fargate에서 다룬 기준을 그대로 적용합니다.
걸러야 할 함정 #
- EventBridge의 지연: 이벤트가 규칙을 거쳐 대상에 닿기까지 평균 0.5초 안팎이 걸립니다. 사용자 요청의 동기 경로에는 넣지 않습니다.
- SNS만 단독으로 쓰는 중요 메시지: 보존이 없으므로 구독자 장애 시간만큼 메시지가 사라집니다. 잃으면 안 되는 메시지는 반드시 뒤에 SQS를 둡니다.
- FIFO의 처리량 한계: FIFO 큐는 초당 300건(배치 시 3,000건)이 기본 한도입니다. 높은 처리량 모드로 올릴 수 있지만, 순서 보장이 정말 전체 메시지에 필요한지부터 다시 묻는 것이 먼저입니다. 대부분 메시지 그룹 단위 순서면 충분합니다.
- 큰 페이로드: 셋 다 최대 256KB입니다. 파일이나 대용량 JSON은 S3에 올리고 메시지에는 키만 담는 포인터 방식이 표준이고, 64KB 청크 과금 때문에 요금도 이쪽이 쌉니다.
선택 순서 #
- 받는 쪽이 하나인지 봅니다: 작업을 쌓고 소비자가 제 속도로 처리하는 구조면 SQS로 끝입니다. 백그라운드 작업, 배치 투입, 스파이크 흡수가 여기입니다.
- 같은 메시지를 여럿이 받아야 하면 SNS를 앞에 둡니다: 구독자마다 SQS 큐를 붙이는 팬아웃이 기본형입니다.
- 이벤트 내용으로 라우팅해야 하면 EventBridge입니다: 필드 값 조건, AWS 서비스 이벤트 수신, SaaS 연동, 스케줄, 아카이브·리플레이 중 하나라도 필요하면 여기입니다.
- 지연과 순서 요구를 검산합니다: 동기 경로에는 셋 다 넣지 않는 것이 원칙이고, 순서가 필요하면 FIFO의 처리량 한도를 함께 확인합니다.
- 요금은 과금 단위로 봅니다: 64KB 청크, 폴링 요청 수, HTTP 전달 추가분까지 넣어야 실제 청구서가 나옵니다. 안 쓰는 구독과 규칙이 남아 있지 않은지는 상시 점검 목록과 함께 봅니다.
정리 #
- 소비자 하나의 작업 버퍼는 SQS, 여러 구독자로의 팬아웃은 SNS, 내용 기반 라우팅과 SaaS 연동·스케줄은 EventBridge입니다.
- 보존과 재시도, DLQ는 SQS에만 있습니다. 잃으면 안 되는 메시지는 어떤 구성이든 마지막에 SQS가 받게 합니다.
- 요금은 100만 건당 SQS $0.40, SNS $0.50, EventBridge $1.00 수준이고 과금은 64KB 청크 단위입니다. 대량 이벤트에서만 단가 차이가 의미를 갖습니다.
- EventBridge는 평균 0.5초 안팎의 지연이 있어 동기 경로에 넣지 않습니다. FIFO는 초당 300건(배치 3,000건)이 기본 한도입니다.
- 실무 정답은 조합입니다. SNS → SQS 팬아웃, EventBridge → SQS가 가장 흔한 두 형태입니다.