Gửi Email Alert qua SNS: Tại Sao Tôi Không Nhận Được Email?

Bạn vừa tạo xong một SNS topic, gắn subscription email, deploy xong Lambda hoặc CloudWatch Alarm — rồi ngồi chờ. Không có gì. Đây là lỗi cực kỳ phổ biến khi mới làm việc với Amazon SNS email alert: subscription ở trạng thái PendingConfirmation và AWS đã gửi một email xác nhận đến inbox của bạn, nhưng bạn chưa click vào link đó.

TL;DR — Tóm Tắt Nhanh

Vấn đềNguyên nhânHành động
Không nhận được email alertSubscription chưa được xác nhậnKiểm tra inbox, click link xác nhận
Email xác nhận không đếnSai địa chỉ email hoặc bị spam filterKiểm tra spam/junk, tạo lại subscription
Subscription vẫn Pending sau 3 ngàyToken xác nhận đã hết hạnXóa subscription cũ, tạo mới
Đã confirm nhưng vẫn không nhậnTopic policy hoặc IAM chặn publishKiểm tra resource policy của topic

Amazon SNS Email Subscription Hoạt Động Như Thế Nào

SNS không gửi email trực tiếp ngay khi bạn tạo subscription. Thay vào đó, nó thực hiện một quy trình xác nhận hai bước để đảm bảo địa chỉ email hợp lệ và chủ sở hữu đồng ý nhận thông báo. Đây là điểm mà hầu hết mọi người bị vấp.

sequenceDiagram participant U as Bạn (User/CLI) participant SNS as Amazon SNS participant Email as Email Inbox U->>SNS: sns:Subscribe (protocol=email) SNS-->>U: SubscriptionArn: PendingConfirmation SNS->>Email: Gửi email xác nhận (Confirmation Token) Note over Email: Trạng thái: PendingConfirmation
Message publish sẽ bị bỏ qua Email->>SNS: Click link xác nhận SNS-->>U: SubscriptionArn: arn:aws:sns:... Note over SNS: Trạng thái: Confirmed U->>SNS: sns:Publish (message) SNS->>Email: Gửi email alert
  1. Subscribe: Bạn gọi sns:Subscribe với protocol email và endpoint là địa chỉ email.
  2. PendingConfirmation: SNS gửi email chứa một URL xác nhận duy nhất đến địa chỉ đó. Subscription ở trạng thái PendingConfirmation — mọi message publish lên topic trong giai đoạn này sẽ không được gửi đến email này.
  3. Confirm: Người dùng click vào link trong email. SNS chuyển subscription sang trạng thái Confirmed.
  4. Deliver: Từ đây, mọi message publish lên topic mới được SNS gửi đến email.

Token xác nhận có thời hạn hiệu lực. Nếu bạn không xác nhận trong thời gian đó, subscription sẽ tự động bị xóa và bạn cần tạo lại từ đầu.

Bước 1: Kiểm Tra Trạng Thái Subscription Hiện Tại

Trước khi làm bất cứ điều gì khác, hãy xác nhận chính xác subscription của bạn đang ở trạng thái nào. Đây là điểm khởi đầu duy nhất có ý nghĩa — mọi hướng xử lý tiếp theo đều phụ thuộc vào kết quả của bước này.

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic

Kết quả trả về sẽ có trường SubscriptionArn. Nếu giá trị là PendingConfirmation, subscription chưa được xác nhận. Nếu là một ARN đầy đủ (ví dụ arn:aws:sns:us-east-1:123456789012:MyAlertTopic:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), subscription đã được xác nhận.

Bước 2: Xử Lý Subscription Đang Ở Trạng Thái PendingConfirmation

Nếu subscription đang PendingConfirmation, bước đầu tiên là kiểm tra inbox của địa chỉ email bạn đã đăng ký — bao gồm cả thư mục spam/junk. Email xác nhận có tiêu đề dạng 'AWS Notification - Subscription Confirmation', gửi từ no-reply@sns.amazonaws.com. Click vào link 'Confirm subscription' trong email đó.

Giống như đăng ký newsletter — dù bạn điền form xong, bạn vẫn phải click link trong email xác nhận thì mới thực sự được nhận bài. SNS hoạt động theo cùng cơ chế đó.

Nếu email xác nhận không đến hoặc token đã hết hạn, bạn cần xóa subscription cũ và tạo lại. Lưu ý quan trọng: lệnh aws sns unsubscribe chỉ hoạt động với các subscription đã ở trạng thái Confirmed (có ARN đầy đủ). Subscription đang ở trạng thái PendingConfirmation phải được xóa thông qua AWS Management Console (SNS → Topics → chọn topic → Subscriptions → chọn subscription pending → Delete).

Sau khi xóa subscription cũ, tạo lại subscription mới:

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --protocol email \
  --notification-endpoint your-email@example.com

Kiểm tra inbox ngay lập tức và click link xác nhận trước khi token hết hạn.

Bước 3: Xác Minh Topic Tồn Tại và Có Đúng ARN

Subscription đã confirmed nhưng vẫn không nhận được email? Lúc này cần kiểm tra xem alarm hoặc service của bạn có đang publish đúng topic ARN không. Một lỗi hay gặp là copy nhầm ARN từ region khác hoặc từ một topic test cũ.

aws sns get-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic

Lệnh này trả về các thuộc tính của topic, bao gồm TopicArn để bạn đối chiếu với ARN đang được cấu hình trong CloudWatch Alarm hoặc Lambda.

Bước 4: Kiểm Tra Topic Policy Có Cho Phép Publish Không

Đây là lớp hay bị bỏ qua nhất. Nếu CloudWatch Alarm hoặc một AWS service khác publish lên topic nhưng bị chặn bởi resource policy của topic, message sẽ bị drop hoàn toàn — không có error log rõ ràng ở phía người nhận.

aws sns get-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --query 'Attributes.Policy' \
  --output text

Kiểm tra trường Policy trong output. Nếu bạn muốn CloudWatch publish lên topic này, policy cần có statement tương tự:

🔽 Xem ví dụ Topic Policy cho CloudWatch Alarms 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudWatchPublish",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudwatch.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:MyAlertTopic"
    }
  ]
}

Nếu topic được tạo mà không chỉnh sửa policy, mặc định chỉ có account owner mới có quyền publish. Các AWS service như CloudWatch cần được cấp quyền tường minh trong resource policy.

Bước 5: Kiểm Tra IAM Permission Của Người Thực Hiện

Nếu bạn đang tạo subscription hoặc publish message bằng CLI/SDK với một IAM role hoặc user cụ thể, role đó cần có đủ quyền. Thiếu quyền ở bước này thường biểu hiện bằng lỗi AuthorizationError trong CLI — nhưng nếu bạn dùng console và không để ý, lỗi có thể bị bỏ qua.

🔽 Xem ví dụ IAM Policy tối thiểu cho SNS email alert 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SNSTopicActions",
      "Effect": "Allow",
      "Action": [
        "sns:Subscribe",
        "sns:Publish",
        "sns:GetTopicAttributes",
        "sns:Unsubscribe"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:MyAlertTopic"
    },
    {
      "Sid": "SNSListSubscriptions",
      "Effect": "Allow",
      "Action": [
        "sns:ListSubscriptionsByTopic"
      ],
      "Resource": "*"
    }
  ]
}

Action sns:ListSubscriptionsByTopic được tách ra một Statement riêng với "Resource": "*" vì theo AWS Service Authorization Reference, action này không hỗ trợ resource-level restriction — nếu đặt chung với ARN cụ thể, policy sẽ không hoạt động đúng.

Luồng Chẩn Đoán Toàn Bộ

graph TD A["Không nhận được email alert"] --> B["Kiểm tra trạng thái subscription
list-subscriptions-by-topic"] B --> C{"SubscriptionArn?"} C -->|"PendingConfirmation"| D["Kiểm tra inbox + spam"] D --> E{"Tìm thấy email xác nhận?"} E -->|"Có"| F["Click link xác nhận"] E -->|"Không / Token hết hạn"| G["Xóa qua AWS Console
Tạo lại subscription"] G --> F F --> H["Subscription Confirmed"] C -->|"ARN đầy đủ (Confirmed)"| I["Kiểm tra topic ARN
có khớp với publisher?"] I -->|"Sai ARN"| J["Sửa ARN trong CloudWatch
hoặc Lambda config"] I -->|"ARN đúng"| K["Kiểm tra Topic Resource Policy
get-topic-attributes"] K -->|"Policy chặn publish"| L["Cập nhật policy
cho phép service publish"] K -->|"Policy OK"| M["Kiểm tra IAM permission
của principal"] H --> N["Publish test message
sns:Publish"] J --> N L --> N M --> N N --> O["Nhận email thành công ✓"]
  1. Kiểm tra trạng thái subscription bằng list-subscriptions-by-topic.
  2. Nếu PendingConfirmation: kiểm tra inbox, click link xác nhận. Nếu token hết hạn, xóa qua Console và tạo lại subscription.
  3. Nếu đã Confirmed nhưng không nhận email: kiểm tra topic ARN đang được publish có khớp không.
  4. Kiểm tra topic resource policy có cho phép service publish không.
  5. Kiểm tra IAM permission của principal thực hiện publish/subscribe.

Kinh Nghiệm Thực Tế: Sai Lầm Hay Gặp Nhất

Tình huống điển hình: CloudWatch Alarm được cấu hình đúng, SNS topic tồn tại, subscription hiển thị Confirmed trong console — nhưng không có email nào đến khi alarm trigger. Kiểm tra CloudWatch Alarm history thấy trạng thái chuyển sang ALARM bình thường. Không có lỗi nào được log.

Nguyên nhân thực tế: topic được tạo bởi một account member, nhưng CloudWatch Alarm lại ở một account khác trong AWS Organizations. Topic policy không có statement cho phép cloudwatch.amazonaws.com từ account đó publish. Message bị drop hoàn toàn ở lớp resource policy — không có notification, không có CloudWatch metric nào cho thấy publish thất bại từ phía người nhận.

Bài học: khi cross-account hoặc cross-service publish, resource policy của topic là lớp đầu tiên cần kiểm tra, không phải IAM của publisher.

Gửi Test Message Để Xác Nhận End-to-End

Sau khi đã xác nhận subscription và kiểm tra policy, publish một message test để xác minh toàn bộ luồng hoạt động trước khi dựa vào đây cho production alert.

aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --subject "Test Alert" \
  --message "Day la email test tu SNS topic MyAlertTopic"

Nếu email đến trong vòng vài giây, toàn bộ luồng từ publish đến delivery đang hoạt động đúng.

Tổng Kết và Bước Tiếp Theo với SNS Email Alert

Phần lớn các trường hợp không nhận được SNS email alert đều quy về một trong ba nguyên nhân: subscription chưa được xác nhận, topic resource policy chặn publisher, hoặc sai ARN. Quy trình chẩn đoán theo thứ tự — trạng thái subscription → topic policy → IAM — sẽ xác định được nguyên nhân trong hầu hết các tình huống.

Để đi sâu hơn, tham khảo tài liệu chính thức:

Glossary — Các Thuật Ngữ Chính

Thuật ngữGiải thích
SNS TopicKênh truyền thông điệp trung tâm trong Amazon SNS. Publisher gửi message vào topic, SNS phân phối đến tất cả subscriber.
SubscriptionLiên kết giữa một topic và một endpoint (email, SQS, Lambda, v.v.). Phải ở trạng thái Confirmed mới nhận được message.
PendingConfirmationTrạng thái của subscription email sau khi tạo, trước khi người dùng click link xác nhận. Message sẽ không được gửi đến endpoint này.
Topic Resource PolicyJSON policy gắn trực tiếp vào SNS topic, kiểm soát principal nào được phép thực hiện action (publish, subscribe) lên topic đó.
Confirmation TokenMã duy nhất trong link xác nhận email. Có thời hạn hiệu lực; sau khi hết hạn, subscription phải được tạo lại.

Related Posts

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

EC2 Không Có Internet Trong Custom VPC: Cách Gắn Internet Gateway và Cập Nhật Route Table

Bạn tạo một custom VPC, launch EC2 instance vào public subnet, SSH vào được — nhưng ping google.com trả về timeout hoàn toàn. Đây là một trong những lỗi phổ biến nhất khi làm việc với EC2 không có internet trong custom VPC, và nguyên nhân gần như luôn nằm ở một trong ba lớp: thiếu Internet Gateway, route table chưa có default route, hoặc Security Group/NACL chặn traffic ra ngoài. TL;DR — EC2 Không Có Internet Trong Custom VPC Lớp kiểm tra Triệu chứng Fix Internet Gateway Không có IGW hoặc IGW chưa attach vào VPC Tạo IGW, attach vào VPC Route Table Không có route 0.0.0.0/0 → igw-xxx Thêm default route trỏ vào IGW Subnet Association Subnet dùng main route table không có IGW route Associate subnet với route table đúng Public IP EC2 không có public IP hoặc Elastic IP Enable auto-assign public IP hoặc gắn EIP Security Group Outbound rule bị xóa hoặc quá hạn chế Thêm outbound rule cho port 80/443 hoặc all...
Đọc thêm

RDS Multi-AZ: Lợi Ích Thực Sự Là Gì và Khi Nào Nên Bật?

Một trong những câu hỏi hay gặp nhất khi thiết kế hệ thống trên AWS là: bật Multi-AZ cho RDS có giúp tăng hiệu năng đọc không, hay nó chỉ phục vụ mục đích failover? Câu trả lời ngắn gọn là: Multi-AZ không cải thiện hiệu năng đọc — nhưng nếu bạn đang vận hành hệ thống production mà thiếu nó, bạn đang chấp nhận một rủi ro downtime không cần thiết. TL;DR — RDS Multi-AZ là gì và có lợi ích gì? Multi-AZ là cơ chế high availability của RDS, không phải cơ chế scale-out. Bảng dưới tóm tắt những điểm quan trọng nhất: Khía cạnh Multi-AZ Read Replica Mục đích chính High availability, failover tự động Scale-out đọc, giảm tải primary Standby có nhận traffic đọc không? Không (với Multi-AZ DB Instance) Có Replication Synchronous Asynchronous Failover tự động Có Không (thủ công) RTO mục tiêu Thường dưới 2 phút (tùy engine) Không áp dụng Ảnh hưởng hiệu năng ghi Có thể tăng nhẹ latency do sync replication Không...
Đọc thêm

Lỗi CORS trên API Gateway: Cách bật CORS và Lambda phải trả về header gì

Frontend gọi API Gateway và nhận ngay lỗi 'Access-Control-Allow-Origin' — đây là một trong những lỗi phổ biến nhất khi tích hợp React/Vue với backend AWS, và cũng là lỗi dễ chẩn đoán sai nhất. Vấn đề không chỉ nằm ở việc bật CORS trong console, mà còn ở chỗ Lambda của bạn có thực sự trả về đúng headers trong response hay không. TL;DR — Tóm tắt nhanh Vấn đề Nguyên nhân Fix CORS error trên preflight OPTIONS API Gateway chưa có method OPTIONS hoặc chưa enable CORS Enable CORS trong console hoặc thêm OPTIONS method thủ công CORS error trên request thực (GET/POST) Lambda response thiếu header Access-Control-Allow-Origin Thêm header vào Lambda response body CORS error khi Lambda trả về lỗi (4xx/5xx) Lambda Proxy Integration không tự inject CORS headers vào error response Lambda phải tự trả về CORS headers ngay cả khi có lỗi CORS hoạt động như thế nào với API Gateway Trước khi đi vào fix, cần hiểu đún...
Đọc thêm