SNS 이메일 알림이 안 올 때 — 구독 확인 링크부터 점검하라

SNS 토픽을 만들고 이메일 구독까지 등록했는데 알림이 하나도 안 온다. 가장 먼저 의심해야 할 건 코드도 IAM도 아니다 — 구독 확인(Subscription Confirmation) 이메일을 클릭했는지 여부다. 이 단계를 건너뛰면 SNS는 메시지를 발행해도 해당 엔드포인트로 전달하지 않는다.

TL;DR — SNS 이메일 알림 미수신 핵심 체크리스트

점검 항목확인 방법조치
구독 상태가 'PendingConfirmation'AWS 콘솔 또는 CLI로 구독 목록 조회확인 이메일의 링크 클릭 또는 재발송
확인 이메일이 스팸함에 있음수신 이메일함 스팸 폴더 확인스팸 해제 후 링크 클릭
토픽에 메시지가 실제로 발행되지 않음CloudWatch 지표 NumberOfMessagesSent 확인Publish API 또는 콘솔에서 테스트 메시지 발행
구독 필터 정책이 메시지를 차단구독 속성의 FilterPolicy 확인필터 정책 제거 또는 메시지 속성 추가
잘못된 이메일 주소로 구독 등록구독 엔드포인트 값 확인구독 삭제 후 올바른 주소로 재등록

SNS 이메일 구독의 동작 원리

SNS 이메일 알림이 왜 안 오는지 이해하려면 구독 생성부터 메시지 전달까지의 흐름을 알아야 한다. SNS는 이메일 엔드포인트를 등록할 때 즉시 활성화하지 않는다. 반드시 수신자가 확인 이메일의 링크를 클릭해야 구독이 'Confirmed' 상태로 전환된다. 이 설계는 동의 없이 타인의 이메일로 메시지를 보내는 것을 방지하기 위한 것이다.

sequenceDiagram participant User as 사용자 participant SNS as Amazon SNS participant Email as 이메일 수신함 User->>SNS: subscribe() 호출
(protocol: email) SNS-->>Email: 확인 이메일 발송
(Subscription Confirmation) Note over SNS: 구독 상태: PendingConfirmation Email-->>User: 확인 링크 클릭 User->>SNS: 확인 링크 GET 요청 SNS-->>SNS: 구독 상태 변경
PendingConfirmation → Confirmed Note over SNS: 이제부터 메시지 전달 활성화 SNS-->>Email: 토픽 메시지 전달
  1. 구독 생성 요청: subscribe API 호출 시 SNS는 구독을 'PendingConfirmation' 상태로 등록한다.
  2. 확인 이메일 발송: SNS가 등록된 이메일 주소로 확인 링크가 담긴 이메일을 자동 발송한다.
  3. 수신자 확인: 수신자가 이메일의 'Confirm subscription' 링크를 클릭해야 상태가 'Confirmed'로 바뀐다.
  4. 메시지 전달 활성화: 상태가 'Confirmed'인 구독에만 토픽 메시지가 전달된다. 'PendingConfirmation' 상태에서는 메시지가 전달되지 않는다.
구독 확인 링크는 발송 후 3일간 유효하다. 기간이 지나면 링크가 만료되고, 구독은 자동으로 삭제된다. 다시 구독을 등록해야 한다.

SNS 이메일 알림 미수신 — 단계별 진단

1단계: 구독 상태 확인

가장 먼저 해야 할 일은 구독이 실제로 'Confirmed' 상태인지 확인하는 것이다. 콘솔에서 확인할 수도 있지만, CLI로 조회하면 모든 구독의 상태를 한눈에 볼 수 있다. 'PendingConfirmation'이 보이면 이메일을 확인하지 않은 것이다.

# 특정 토픽의 모든 구독 목록과 상태 조회
aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic

출력 결과에서 SubscriptionArn 값이 PendingConfirmation으로 표시되면 아직 확인이 완료되지 않은 상태다. 'Confirmed' 상태라면 구독 ARN이 정상적으로 출력된다.

2단계: 확인 이메일 재발송

확인 이메일을 못 찾겠거나 링크가 만료됐다면, 구독을 삭제하고 다시 등록하는 것이 가장 빠르다. SNS 콘솔에서 직접 재발송하는 버튼은 없다. 구독을 재생성하면 확인 이메일이 다시 발송된다.

# 기존 PendingConfirmation 구독 삭제
# (SubscriptionArn이 'PendingConfirmation'인 경우 ARN이 없으므로 콘솔에서 삭제)
# 구독 재등록 — 확인 이메일이 다시 발송됨
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --protocol email \
  --notification-endpoint your-email@example.com

명령 실행 후 수신 이메일함(스팸 포함)에서 'AWS Notification - Subscription Confirmation' 제목의 이메일을 찾아 링크를 클릭한다.

3단계: 토픽에 테스트 메시지 발행

구독이 'Confirmed' 상태인데도 이메일이 안 온다면, 토픽에 메시지가 실제로 발행되고 있는지 확인해야 한다. 알람 조건이 충족되지 않아서 메시지 자체가 발행되지 않는 경우도 흔하다. CLI로 직접 테스트 메시지를 발행해서 전달 경로를 검증한다.

# 토픽에 테스트 메시지 직접 발행
aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --subject 'SNS 테스트 알림' \
  --message 'SNS 이메일 전달 테스트 메시지입니다.'

이 명령 실행 후 이메일이 도착하면 SNS 자체는 정상이다. 문제는 알람 소스(CloudWatch Alarm, EventBridge 등)가 SNS를 트리거하지 않는 것이다.

4단계: CloudWatch 지표로 메시지 전달 현황 확인

SNS는 메시지 발행 및 전달 성공/실패에 대한 CloudWatch 지표를 제공한다. 테스트 메시지는 도착하는데 실제 알람 메시지가 안 온다면, 알람 소스 설정을 점검해야 한다는 신호다.

# SNS 토픽의 메시지 발행 수 확인 (최근 1시간)
aws cloudwatch get-metric-statistics \
  --namespace AWS/SNS \
  --metric-name NumberOfMessagesPublished \
  --dimensions Name=TopicName,Value=MyAlertTopic \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Sum

5단계: 구독 필터 정책 확인

구독에 필터 정책(Filter Policy)이 설정되어 있으면, 메시지 속성이 필터 조건과 일치하지 않는 경우 해당 구독으로 메시지가 전달되지 않는다. 이 설정은 조용히 메시지를 차단하기 때문에 놓치기 쉽다.

# 구독 ARN으로 필터 정책 포함 구독 속성 조회
aws sns get-subscription-attributes \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

출력에서 FilterPolicy 키가 있고 값이 비어 있지 않다면, 발행하는 메시지에 해당 속성이 포함되어야 한다. 테스트 목적으로 필터 정책을 제거하려면 아래 명령을 사용한다.

# 구독에서 필터 정책 제거
aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --attribute-name FilterPolicy \
  --attribute-value '{}'

실제 사례 — CloudWatch Alarm이 SNS를 트리거하지 않는 경우

증상은 이랬다. SNS 구독은 'Confirmed' 상태고, CLI로 직접 발행한 테스트 메시지는 이메일로 잘 도착한다. 그런데 EC2 CPU 사용률이 임계값을 넘어도 알림이 오지 않는다.

처음엔 SNS 토픽 정책 문제라고 생각했다. 토픽 정책을 열어봤지만 CloudWatch가 Publish 권한을 가지고 있었다. 그 다음엔 CloudWatch Alarm 상태를 확인했는데 — Alarm 상태가 'INSUFFICIENT_DATA'였다. CPU 지표 데이터 포인트가 부족해서 알람 자체가 ALARM 상태로 전환되지 않은 것이었다.

실제 원인은 EC2 인스턴스의 세부 모니터링(Detailed Monitoring)이 비활성화된 상태에서 알람 평가 기간을 1분으로 설정한 것이었다. 기본 모니터링은 5분 단위로 지표를 수집하므로, 1분 평가 기간에는 데이터가 없어 'INSUFFICIENT_DATA'가 유지됐다.

# CloudWatch Alarm 현재 상태 확인
aws cloudwatch describe-alarms \
  --alarm-names MyEC2CpuAlarm \
  --query 'MetricAlarms[*].{Name:AlarmName,State:StateValue,Reason:StateReason}'

알람 상태가 'INSUFFICIENT_DATA'라면 SNS 문제가 아니다. 알람 평가 기간을 지표 수집 주기에 맞게 조정하거나, EC2 세부 모니터링을 활성화해야 한다.

graph TD A[CloudWatch Alarm
ALARM 상태 전환] -->|sns:Publish| B[SNS Topic] B --> C{구독 상태 확인} C -->|Confirmed| D[이메일 전달] C -->|PendingConfirmation| E[전달 안 됨] A2[CloudWatch Alarm
INSUFFICIENT_DATA] -->|트리거 없음| F[SNS 미호출] F --> G[이메일 미수신] style E fill:#f66,color:#fff style G fill:#f66,color:#fff style D fill:#6a6,color:#fff

SNS 토픽 정책 — CloudWatch Alarm 연동 시 필수 권한

CloudWatch Alarm이 SNS 토픽에 메시지를 발행하려면 토픽 정책에 CloudWatch 서비스 주체(Principal)에 대한 sns:Publish 권한이 있어야 한다. AWS 콘솔에서 CloudWatch Alarm을 생성할 때 SNS 토픽을 지정하면 이 정책이 자동으로 추가되지만, CLI나 IaC로 직접 구성할 때는 누락되기 쉽다.

🔽 SNS 토픽 정책 예시 (CloudWatch Alarm 연동) — 클릭하여 펼치기 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudWatchAlarmPublish",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudwatch.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:MyAlertTopic",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:*"
        }
      }
    }
  ]
}

# 현재 토픽 정책 확인
aws sns get-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --query 'Attributes.Policy'

SNS 이메일 알림 설정 — 전체 진단 흐름

graph TD Start[이메일 알림 미수신] --> Q1{구독 상태 확인} Q1 -->|PendingConfirmation| A1[확인 이메일 링크 클릭
또는 구독 재등록] Q1 -->|Confirmed| Q2{테스트 메시지
직접 발행} Q2 -->|이메일 미수신| A2[토픽 정책 확인
필터 정책 확인] Q2 -->|이메일 수신| Q3{CloudWatch Alarm
상태 확인} Q3 -->|INSUFFICIENT_DATA| A3[평가 기간 조정
세부 모니터링 활성화] Q3 -->|OK 유지| A4[알람 임계값 및
조건 재검토] Q3 -->|ALARM 전환됨| A5[SNS 토픽 ARN
연결 설정 재확인] A1 --> End[알림 수신 확인] A2 --> End A3 --> End A4 --> End A5 --> End style Start fill:#e8a,color:#fff style End fill:#6a6,color:#fff
  1. 구독 상태가 'PendingConfirmation'이면 이메일 확인이 첫 번째 해결책이다.
  2. 구독이 'Confirmed'이면 테스트 메시지로 SNS 전달 경로를 검증한다.
  3. 테스트 메시지도 안 오면 토픽 정책과 필터 정책을 점검한다.
  4. 테스트 메시지는 오는데 알람 메시지가 안 오면 알람 소스(CloudWatch 등) 설정을 점검한다.

SNS 이메일 알림 — 마무리 및 다음 단계

SNS 이메일 알림 미수신의 대부분은 구독 확인 단계를 건너뛴 것에서 시작한다. 구독 상태를 CLI로 먼저 확인하는 습관을 들이면 불필요한 디버깅 시간을 줄일 수 있다. 구독이 정상 확인됐는데도 알림이 안 온다면, SNS 자체보다 알람 소스와 토픽 정책을 먼저 의심하라.

다음 단계로 고려할 수 있는 설정:

  • SNS 메시지 전달 실패 로깅: 토픽 속성에서 전달 상태 로깅(Delivery Status Logging)을 활성화하면 CloudWatch Logs에서 전달 성공/실패 상세 내역을 확인할 수 있다.
  • Dead-Letter Queue(DLQ) 설정: 이메일 전달 실패 시 메시지를 보존하려면 SQS DLQ를 구독에 연결할 수 있다. 단, 이메일 프로토콜 구독에 대한 DLQ 지원 여부는 공식 문서에서 확인하라.
  • 관련 AWS 공식 문서: Amazon SNS 이메일 알림, SNS 구독 필터 정책

핵심 용어 정리

용어설명
PendingConfirmation구독 등록 후 수신자가 확인 링크를 클릭하기 전의 상태. 이 상태에서는 메시지가 전달되지 않는다.
Subscription ConfirmationSNS가 이메일 엔드포인트 등록 시 발송하는 확인 이메일. 링크 클릭으로 구독을 활성화한다.
Filter Policy구독 단위로 설정하는 메시지 필터링 규칙. 조건에 맞지 않는 메시지는 해당 구독으로 전달되지 않는다.
Topic PolicySNS 토픽에 대한 리소스 기반 정책. 어떤 AWS 서비스나 계정이 토픽에 메시지를 발행할 수 있는지 제어한다.
INSUFFICIENT_DATACloudWatch Alarm 상태 중 하나. 알람을 평가하기 위한 지표 데이터가 충분하지 않을 때 표시된다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기