การผสานรวม SNS และ SQS กับ CloudWatch

การติดตามและแก้ไขปัญหาบน AWS

John Q. Martin

Principal Consultant

เชื่อมต่อ CloudWatch alarm กับ SNS

aws cloudwatch put-metric-alarm \
  --alarm-name HighCPUUtilization \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts \
  --ok-actions arn:aws:sns:us-east-1:123456789012:recovery-notifications

ไดอะแกรม: CloudWatch Alarm ส่งผ่าน --alarm-actions ไปยัง SNS topic ซึ่งกระจายไปยังผู้รับ — Email, SMS, Lambda และ SQS

แนวคิดหลักของ SNS

องค์ประกอบ

SNS ใช้รูปแบบ publisher/subscriber: topics, publishers, subscribers
Topic: ช่องทางที่มีชื่อ; publisher ส่ง, subscriber รับ
เผยแพร่ครั้งเดียว ส่งพร้อมกันถึงทุก subscriber

โปรโตคอลของ subscriber (หนึ่ง topic, หลาย endpoint):

Email, SMS
HTTP / HTTPS
Lambda, SQS
Mobile push, Kinesis Firehose

ประเภทของ SNS topic

เปรียบเทียบประเภท SNS topic แบบ Standard และ FIFO ในด้านลำดับ throughput และการรับประกันการส่ง

สร้าง SNS topic ด้วย AWS CLI

Standard topic

aws sns create-topic \
  --name production-alerts

FIFO topic

aws sns create-topic \
  --name production-alerts.fifo \
  --attributes FifoTopic=true,\
    ContentBasedDeduplication=true

With encryption

aws sns create-topic \
  --name production-alerts \
  --attributes KmsMasterKeyId=alias/aws/sns

เพิ่ม subscriber แบบ Lambda และ SMS

Lambda

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:production-alerts \
  --protocol lambda \
  --notification-endpoint arn:aws:lambda:us-east-1:123456789012:function:ProcessAlert

SMS

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:critical-alerts \
  --protocol sms \
  --notification-endpoint +1234567890

รูปแบบข้อความ SNS จาก CloudWatch alarm

{
  "AlarmName": "HighCPUUtilization",
  "NewStateValue": "ALARM",
  "OldStateValue": "OK",
  "NewStateReason": "Threshold Crossed: 2 datapoints [85.0, 90.0] were greater than the threshold (80.0).",
  "StateChangeTime": "2026-03-27T10:30:45.123+0000",
  "Trigger": {
    "MetricName": "CPUUtilization",
    "Namespace": "AWS/EC2",
    "Statistic": "AVERAGE",
    "Period": 300,
    "Threshold": 80.0,
    "ComparisonOperator": "GreaterThanThreshold"
  }
}

การกรองข้อความ SNS

aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:...:production-alerts:abc123 \
  --attribute-name FilterPolicy \
  --attribute-value '{"AlarmName":["HighCPUUtilization"],"NewStateValue":["ALARM"]}'

aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:...:production-alerts:abc123 \
  --attribute-name FilterPolicyScope \
  --attribute-value MessageBody

จัดรูปแบบการแจ้งเตือนด้วย Lambda

def lambda_handler(event, context):
    alarm = json.loads(event['Records'][0]['Sns']['Message'])

    message = f"""
ALERT: {alarm['AlarmName']}
Status: {alarm['NewStateValue']}
Reason: {alarm['NewStateReason']}
Resource: {alarm['Trigger']['Dimensions'][0]['value']}
Runbook: https://wiki.example.com/runbooks/high-cpu
    """

    sns.publish(
        TopicArn='arn:aws:sns:...:formatted-alerts',
        Subject=f"{alarm['AlarmName']}",
        Message=message
    )

ห่วงโซ่: raw alarm topic ส่งไปยัง Lambda เพื่อจัดรูปแบบข้อความแล้วเผยแพร่ไปยัง formatted-alerts topic สำหรับวิศวกรเวร ขณะที่ผู้บริโภคฝั่งเครื่องยังคงรับจาก raw topic

สถาปัตยกรรม fan-out กับ SQS

สถาปัตยกรรม fan-out ที่ SNS message หนึ่งข้อความส่งไปยัง SQS queue หลายคิวและ Lambda consumer

ตั้งค่า Fan-Out

4 ขั้นตอน

สร้าง SQS queue (หนึ่งคิวต่อ consumer)
กำหนด queue policy (อนุญาตให้ SNS ส่งข้อความ)
Subscribe queue เข้ากับ SNS topic
สร้าง consumer (poll, process, delete)

Queue policy

{
  "Effect": "Allow",
  "Principal": { "Service": "sns.amazonaws.com" },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:...:alarm-logging-queue",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:sns:...:production-alerts"
    }
  }
}

การ Subscribe Queue

aws sns subscribe \
  --topic-arn arn:aws:sns:...:production-alerts \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:...:alarm-logging-queue

การประมวลผลข้อความ

รูปแบบ consumer

response = sqs.receive_message(
    QueueUrl=queue_url,
    MaxNumberOfMessages=10,
    WaitTimeSeconds=20       # Long polling
)
for message in response.get('Messages', []):
    sns_msg = json.loads(message['Body'])
    alarm = json.loads(sns_msg['Message'])
    # Process alarm data
    sqs.delete_message(QueueUrl=queue_url,
                       ReceiptHandle=message['ReceiptHandle'])

Fan-Out พร้อมการกรองและ dead letter queue

ส่งตรงตาม subscription

Ticketing queue: {"NewStateValue":["ALARM"],"Severity":["Critical"]}
Logging queue: ไม่มีตัวกรอง (รับทุกข้อความ)
Metrics queue: {"MessageType":["Metric"]}

Dead letter queue (DLQ)

aws sqs set-queue-attributes \
  --queue-url https://sqs..../alarm-logging-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:...:alarm-logging-dlq\",\"maxReceiveCount\":\"3\"}"
  }'

SNS vs. SQS: เลือกใช้เมื่อไหร่

เปรียบเทียบการส่งแบบ push ของ SNS กับการจัดคิวข้อความแบบ pull ของ SQS

ตัวอย่างสถาปัตยกรรม

รูปแบบการแจ้งเตือนแบบง่าย ส่ง SNS notification ไปยัง email

รูปแบบ async processing ที่ API ส่งไปยัง SQS queue แล้ว worker ดึงไปประมวลผล

รูปแบบการแจ้งเตือนหลายช่องทาง ที่ alarm หนึ่งตัวกระจายไปยังช่องทางการแจ้งเตือนหลายช่อง

รูปแบบ event pipeline ที่กำหนดเส้นทาง event ไปยัง SQS queue หลายคิวเพื่อประมวลผล

สรุปวิดีโอ

SNS topic ส่งการแจ้งเตือนผ่าน email, SMS, HTTP, Lambda และ SQS
รูปแบบ fan-out: SNS message หนึ่งข้อความ → SQS queue หลายคิวเพื่อประมวลผลแบบขนานและเชื่อถือได้
การกรองข้อความลดสัญญาณรบกวนต่อ subscriber
Dead letter queue รองรับข้อความที่ส่งไม่สำเร็จ
ใช้ SNS สำหรับ push notification, SQS สำหรับการประมวลผลที่เชื่อถือได้ และใช้ทั้งคู่สำหรับ fan-out ที่มีความน่าเชื่อถือ

มาฝึกกันเถอะ!