Amazon SNS for SAA-C03

One-Line Summary

SNS는 하나의 메시지를 여러 구독자(subscriber)에게 동시에 밀어 보내는(push) 발행/구독(pub/sub) 서비스다. 하나의 이벤트를 이메일·Lambda·SQS 등 여러 대상이 동시에 받아 각자 처리해야 할 때 쓴다. 이 1:N 구조를 팬아웃(fan-out) 이라 부른다.

Why It Exists

한 이벤트가 발생했을 때 여러 시스템이 반응해야 하면, 생산자가 각 대상을 하나씩 직접 호출해야 한다. 대상이 늘 때마다 생산자 코드를 고쳐야 하고, 한 곳이 느리면 전체가 지연된다.

SNS는 생산자가 토픽(Topic)에 한 번만 발행하면, 토픽이 모든 구독자에게 알아서 밀어 보낸다.

직접 호출
  Producer -> Email
           -> Lambda
           -> SQS
  대상 추가 시마다 생산자 수정, 강하게 결합

SNS 사용
  Producer -> [SNS Topic] -> Email 구독
                          -> Lambda 구독
                          -> SQS 구독
  생산자는 토픽에만 발행, 구독자는 자유롭게 추가/제거

시험 감각:

"하나의 이벤트를 여러 대상에 동시에 알린다 / 팬아웃" = SNS.

Abbreviations

약어	풀네임	의미
`SNS`	Simple Notification Service	완전관리형 발행/구독 알림 서비스
`Pub/Sub`	Publish/Subscribe	발행자와 구독자를 토픽으로 분리하는 메시징 모델
`Topic`	Topic	메시지를 발행하는 채널, 구독자들이 여기에 붙음
`Subscriber`	Subscriber	토픽 메시지를 받는 대상(Endpoint)
`Fan-out`	Fan-out	한 메시지를 여러 대상에 동시에 퍼뜨리는 패턴
`SES`	Simple Email Service	이메일 발송 전용 서비스 (SNS와 별개)

어떻게 여러 대상에 전달하나 (Fan-out)

생산자는 토픽에 한 번만 발행하고, 구독자들은 각자 토픽을 구독한다. SNS가 메시지를 복제해 모든 구독자에게 push한다.

주문 완료 이벤트 -> [SNS Topic "order-completed"]
                    -> SES / 이메일   : 고객에게 주문 완료 메일
                    -> Lambda         : 주문 처리 로직 실행
                    -> SQS            : 로그 저장 큐에 적재

항목	의미
발행 방식	생산자는 토픽에 1회 발행
전달 방식	SNS가 모든 구독자에게 push
구독 대상 예시	Lambda, SQS, HTTP/HTTPS 엔드포인트, 이메일(SES 아님), SMS
결합도	구독자 추가/삭제해도 생산자 코드 불변 (느슨한 결합)

지원하는 구독 대상(Endpoint)

대상	용도
`SQS`	메시지를 큐에 넣어 나중에 안정적으로 처리 (fan-out 표준)
`Lambda`	이벤트로 함수 실행
`HTTP/HTTPS`	외부 웹훅으로 전달
Email / Email-JSON	이메일 알림
SMS	문자 알림
Mobile Push	모바일 앱 푸시 알림

SNS + SQS Fan-out 패턴 (자주 출제)

SNS 하나로 여러 SQS 큐에 뿌리면, 각 소비자가 자기 큐에서 자기 속도로 안정적으로 처리할 수 있다. push의 즉시성과 queue의 완충/재처리를 동시에 얻는 조합이다.

Producer -> SNS Topic -> SQS 큐 A -> 서비스 A
                      -> SQS 큐 B -> 서비스 B
                      -> SQS 큐 C -> 서비스 C

SNS만 쓰면 구독자가 순간에 push를 다 받아야 함(다운되면 유실 위험)
SQS를 끼우면 메시지가 큐에 보관 → 소비자 장애/지연에도 안전
시험에서 "reliably deliver one event to multiple systems"면 이 조합을 떠올린다

Message Filtering (빈출)

기본적으로 구독자는 토픽의 모든 메시지를 받는다. 필터 정책(Filter Policy) 을 구독에 걸면, 메시지 속성(attribute)이 조건에 맞는 것만 그 구독자에게 전달된다. 토픽을 여러 개 만들지 않고 하나로 라우팅할 수 있다.

[SNS Topic "orders"]  (메시지 속성 예: type = "premium" | "normal")
  -> 구독 A (filter: type = premium) : 프리미엄 주문만 수신
  -> 구독 B (filter: type = normal)  : 일반 주문만 수신
  -> 구독 C (필터 없음)              : 전체 수신

항목	내용
기준	메시지 속성(attribute) 값 (기본), 또는 본문(payload) 기반 필터
효과	구독자별로 관심 있는 메시지만 선별 수신
이점	토픽 수를 줄이고, 구독자가 불필요한 메시지 처리를 안 해도 됨
시험 키워드	"route only certain messages", "subscribers receive only relevant messages"

시험 감각:

"한 토픽에서 구독자마다 다른 종류의 메시지만 받게 하라" = SNS Message Filtering.

SNS vs SQS

구분	SNS	SQS
모델	발행/구독 (pub/sub)	큐 (queue)
전달 방식	push (밀어 보냄)	pull (소비자가 꺼내 감)
대상 수	1:N (여러 구독자 동시)	보통 1개 소비자군이 순차 소비
메시지 보관	즉시 전달, 오래 보관 안 함	삭제 전까지 큐에 보관
대표 키워드	fan-out, notify many, broadcast	decouple, buffer, process in order

SNS vs SES (헷갈리기 쉬움)

구분	SNS	SES
목적	이벤트를 여러 대상/채널에 알림 (pub/sub)	이메일 전송 전용 (마케팅/트랜잭션 메일)
대상	Lambda·SQS·SMS·HTTP·이메일 등	이메일 수신자
시험 키워드	notification, fan-out	send bulk/transactional email

Common Wrong Directions

오답 방향	왜 부족한가
하나의 이벤트를 여러 시스템에 알리는데 SQS 하나만	SQS 단독은 보통 1소비자군, 1:N 팬아웃은 SNS
대량 이메일 발송인데 SNS로 처리	이메일 캠페인/트랜잭션 메일은 SES
SNS만으로 구독자 장애 시 유실 걱정 없다고 생각	안정 처리엔 SNS + SQS 조합
순서 보장이 필요한데 일반 SNS 사용	순서·중복 제어가 필요하면 SNS FIFO (+ SQS FIFO)

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"fan-out", "notify multiple systems/subscribers"	`SNS`
"one event triggers several actions at once"	`SNS`
"reliably deliver one message to multiple queues"	`SNS + SQS`
"send email/SMS/push notification"	`SNS` (대량 이메일은 `SES`)
"decouple but only one consumer processes"	`SQS`
"route only certain messages to specific subscribers"	SNS Message Filtering (filter policy)

Memory Sentence

SNS는 토픽에 한 번 발행하면 여러 구독자(Lambda·SQS·이메일·SMS)에게 동시에 push하는 1:N 팬아웃이다. 안정적 다중 처리는 SNS+SQS, 대량 이메일 전송은 SES.

[Compute] SNS 컨셉 노트