SQS vs SNS vs EventBridge: 메시징 서비스 어떻게 선택할까?

핵심 요약 (BLUF)

SQS는 1:1 메시지 큐(디커플링), SNS는 1:N Pub/Sub(팬아웃), EventBridge는 이벤트 기반 라우팅(규칙 기반 필터링 + SaaS 통합)에 사용합니다. 셋을 조합하여 사용하는 것이 일반적입니다 (예: SNS → SQS 팬아웃).

3가지 메시징 패턴

1. 메시지 큐 (SQS):
[생산자] → [큐] → [소비자]
→ 1:1, 소비자가 메시지를 가져감 (Pull)

2. Pub/Sub (SNS):
[게시자] → [토픽] → [구독자 1]
                   → [구독자 2]
                   → [구독자 3]
→ 1:N, 토픽이 메시지를 밀어냄 (Push)

3. 이벤트 버스 (EventBridge):
[이벤트 소스] → [이벤트 버스] → 규칙 1 → [대상 A]
                              → 규칙 2 → [대상 B]
→ 규칙 기반 라우팅, 콘텐츠 필터링

Amazon SQS

핵심 특징

항목	설명
패턴	메시지 큐 (Point-to-Point)
전달 방식	Pull (소비자가 메시지를 가져감)
메시지 보존	최대 14일 (기본 4일)
메시지 크기	최대 256KB
순서 보장	Standard: ❌, FIFO: ✅
중복 제거	Standard: ❌, FIFO: ✅
처리량	Standard: 무제한, FIFO: 초당 3,000건 (배치)

Standard vs FIFO

Standard Queue:
[메시지 A, B, C] → 순서 보장 ❌, 최소 1회 전달
→ 처리량 무제한
→ 대부분의 사용 사례에 적합

FIFO Queue:
[메시지 A, B, C] → 순서 보장 ✅, 정확히 1회 전달
→ 초당 300건 (배치 시 3,000건)
→ 주문 처리, 금융 트랜잭션
→ 큐 이름이 .fifo로 끝나야 함

DLQ (Dead-Letter Queue)

[SQS 메인 큐]
      │
      ├── 처리 성공 → 메시지 삭제
      │
      └── 처리 실패 (maxReceiveCount 초과)
              │
              ▼
         [DLQ] ← 실패 메시지 격리
              → 나중에 분석/재처리

가시성 제한 시간 (Visibility Timeout)

소비자 A가 메시지를 가져감
→ 메시지가 다른 소비자에게 안 보임 (기본 30초)
→ 30초 내 처리 완료 + 삭제 → 정상
→ 30초 초과 시 다시 보임 → 다른 소비자가 처리 가능

Amazon SNS

핵심 특징

항목	설명
패턴	Pub/Sub (게시/구독)
전달 방식	Push (구독자에게 밀어냄)
구독자 수	토픽당 최대 12,500,000
메시지 크기	최대 256KB
메시지 보존	❌ (전달 실패 시 유실)
필터링	구독 필터 정책

구독 프로토콜

프로토콜	설명
SQS	SQS 대기열로 전달
Lambda	Lambda 함수 호출
HTTP/S	HTTP 엔드포인트로 POST
Email	이메일 전송
SMS	문자 메시지 전송
Kinesis Data Firehose	스트림으로 전달

SNS + SQS 팬아웃 패턴

주문 완료 이벤트:

[주문 서비스] → [SNS 토픽: 주문완료]
                      │
                      ├── [SQS: 결제 큐] → [결제 서비스]
                      ├── [SQS: 재고 큐] → [재고 서비스]
                      ├── [SQS: 알림 큐] → [알림 서비스]
                      └── [Lambda: 분석 기록]

→ 각 서비스가 독립적으로 처리
→ 하나가 실패해도 다른 서비스에 영향 없음

메시지 필터링

SNS 토픽: 주문 이벤트

구독 1 (결제 서비스):
필터: {"order_type": ["premium"]}
→ 프리미엄 주문만 수신

구독 2 (일반 처리):
필터: 없음
→ 모든 주문 수신

Amazon EventBridge

핵심 특징

항목	설명
패턴	이벤트 버스
이벤트 소스	AWS 서비스, SaaS, 커스텀 앱
대상	18+ AWS 서비스
필터링	이벤트 패턴 (콘텐츠 기반)
스키마	스키마 레지스트리 + 코드 생성
아카이빙	✅ 이벤트 아카이빙 및 재생

이벤트 규칙

EventBridge 규칙 예시:

규칙 1: EC2 상태 변경
이벤트 패턴: {"source": ["aws.ec2"], "detail-type": ["EC2 Instance State-change"]}
대상: SNS → 관리자 알림

규칙 2: S3 객체 생성
이벤트 패턴: {"source": ["aws.s3"], "detail": {"bucket": {"name": ["my-bucket"]}}}
대상: Lambda → 파일 처리

규칙 3: 스케줄
스케줄: cron(0 9 * * ? *)
대상: Lambda → 매일 9시 리포트 생성

EventBridge의 차별점

SNS에는 없는 EventBridge만의 기능:

1. SaaS 통합 (Zendesk, Shopify, Datadog 등)
2. 스키마 레지스트리 (이벤트 구조 자동 검색)
3. 이벤트 아카이빙 & 재생
4. 스케줄 기반 트리거 (cron)
5. API Destinations (외부 API 호출)
6. 글로벌 엔드포인트 (크로스 리전)

3가지 서비스 비교

항목	SQS	SNS	EventBridge
패턴	큐 (1:1)	Pub/Sub (1:N)	이벤트 버스
전달	Pull	Push	Push
메시지 보존	최대 14일	❌	아카이빙 가능
필터링	❌	구독 필터	이벤트 패턴 (강력)
순서 보장	FIFO만	FIFO 토픽	❌
SaaS 통합	❌	❌	✅
스케줄	❌	❌	✅ (cron/rate)
대상 수	1	12.5M 구독자	5 대상/규칙
비용	요청 기반	게시 + 전달	이벤트당 $1/백만

선택 가이드

메시징 서비스 선택:
        │
        ▼
1:1 비동기 처리 + 디커플링?
        │
       Yes → [SQS]
        │     ├── 순서 필요? → FIFO
        │     └── 순서 불필요? → Standard
        No
        │
        ▼
1:N 메시지 브로드캐스트?
        │
       Yes → [SNS]
        │     └── 여러 SQS로 팬아웃? → SNS + SQS
        No
        │
        ▼
이벤트 기반 아키텍처 / SaaS 통합 / 스케줄?
        │
       Yes → [EventBridge]
        │
        No
        │
        ▼
실시간 스트리밍 데이터?
        │
       Yes → [Kinesis]

조합 패턴

SNS + SQS (가장 일반적)

[생산자] → [SNS] → [SQS 1] → [소비자 1]
                  → [SQS 2] → [소비자 2]
→ 팬아웃 + 각 소비자 독립 처리 + 메시지 보존

EventBridge + SQS

[AWS 서비스 이벤트] → [EventBridge] → 규칙 → [SQS] → [Lambda]
→ 이벤트 필터링 + 안정적 처리

SAA-C03 시험 출제 포인트

1. ✅ 디커플링: "컴포넌트 분리 + 비동기 = SQS"
2. ✅ 팬아웃: "1:N 브로드캐스트 = SNS, SNS + SQS 조합"
3. ✅ FIFO: "순서 보장 + 중복 제거 = SQS FIFO"
4. ✅ DLQ: "처리 실패 메시지 격리 = Dead-Letter Queue"
5. ✅ EventBridge: "SaaS 통합, 스케줄, 이벤트 기반 = EventBridge"

자주 묻는 질문 (FAQ)

Q: SQS와 SNS를 같이 사용해야 하나요?

팬아웃이 필요하면 SNS + SQS를 조합합니다. SNS가 여러 SQS 큐로 메시지를 전달하면, 각 소비자가 독립적으로 처리하고 실패 시 메시지가 큐에 남아 재처리 가능합니다.

Q: EventBridge가 SNS를 대체할 수 있나요?

많은 경우 가능하지만, SNS는 SMS/이메일 전송, 대량 구독자 지원 등 고유 기능이 있습니다. AWS 서비스 이벤트 기반 라우팅에는 EventBridge가, A2P 알림에는 SNS가 적합합니다.

Q: SQS 메시지가 중복 전달될 수 있나요?

Standard Queue는 최소 1회 전달로 중복이 가능합니다. 정확히 1회 전달이 필요하면 FIFO Queue를 사용하세요. 또는 소비자 측에서 멱등성을 구현하세요.

Q: SQS의 가시성 제한 시간은 얼마로 설정해야 하나요?

메시지 처리에 걸리는 시간보다 충분히 길게 설정하세요. 너무 짧으면 처리 중인 메시지가 다른 소비자에게 다시 전달됩니다. 기본값은 30초이며 최대 12시간입니다.

Q: Lambda를 SQS와 연동할 때 주의할 점은?

Lambda는 SQS를 이벤트 소스로 사용하여 자동으로 메시지를 폴링합니다. 배치 크기, 동시 실행 수, 오류 처리(DLQ 설정)를 적절히 구성해야 합니다. FIFO 큐는 메시지 그룹 ID당 하나의 Lambda만 처리합니다.

관련 글

• S3 이벤트 알림: Lambda, SQS, SNS 연동
• Lambda 함수 최적화
• Auto Scaling 그룹 설정 및 정책

참고 자료

• Amazon SQS, SNS, or EventBridge 결정 가이드
• 서버리스 메시징 서비스 선택
• Amazon SQS FAQ