CloudWatch와 SNS, SQS 통합

AWS 모니터링 및 문제 해결

John Q. Martin

Principal Consultant

CloudWatch 알람과 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-actions를 통해 SNS 토픽으로 전송되고, 이 토픽이 이메일, SMS, Lambda, SQS 등 구독자에게 팬아웃되는 과정

SNS 핵심 개념

구성 요소

SNS는 발행/구독 구조: 토픽, 발행자, 구독자로 구성
토픽: 이름이 있는 채널로, 발행자가 보내고 구독자가 받음
한 번 발행하면 모든 구독자에게 동시에 전달됨

구독자 프로토콜(하나의 토픽, 여러 엔드포인트):

이메일, SMS
HTTP / HTTPS
Lambda, SQS
모바일 푸시, Kinesis Firehose

SNS 토픽 유형

순서 보장, 처리량, 전달 보장 측면에서 SNS Standard 토픽과 FIFO 토픽을 비교한 그림

SNS 토픽 생성하기: AWS CLI

Standard 토픽

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

FIFO 토픽

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

암호화 적용

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

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

CloudWatch 알람에서 오는 SNS 메시지 형식

{
  "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
    )

연결: 원본 알람 토픽이 Lambda로 전달되고, Lambda가 메시지를 읽기 쉽게 포맷해 formatted-alerts 토픽에 발행하면 당직 엔지니어가 이를 받고, 머신 소비자는 원본 토픽을 그대로 사용하는 구조

SQS를 활용한 팬아웃 아키텍처

하나의 SNS 메시지가 여러 SQS 큐와 Lambda 소비자에게 전달되는 팬아웃 아키텍처

팬아웃 설정하기

네 단계

SQS 큐 생성(소비자마다 하나씩)
큐 정책 설정(SNS가 메시지를 보낼 수 있도록 허용)
큐를 SNS 토픽에 구독
소비자 구현(폴링, 처리, 삭제)

큐 정책

{
  "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"
    }
  }
}

큐 구독하기

각 큐 구독하기

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

메시지 처리하기

소비자 패턴

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'])

필터링과 데드 레터 큐를 적용한 팬아웃

구독별 맞춤 전달

티케팅 큐: {"NewStateValue":["ALARM"],"Severity":["Critical"]}
로깅 큐: 필터 없음(모든 메시지 수신)
메트릭 큐: {"MessageType":["Metric"]}

데드 레터 큐(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: 언제 무엇을 쓸까

푸시 기반 전달 방식인 SNS와 풀 기반 메시지 큐잉 방식인 SQS 비교

아키텍처 예시

SNS 알림을 이메일로 전송하는 단순 알림 패턴

API가 SQS 큐로 보내고 워커가 소비하는 비동기 처리 패턴

하나의 알람이 여러 알림 채널로 팬아웃되는 다중 채널 알림 패턴

소스 이벤트를 여러 SQS 큐로 라우팅해 처리하는 이벤트 파이프라인 패턴

동영상 요약

SNS 토픽은 이메일, SMS, HTTP, Lambda, SQS를 통해 알람 알림을 전달
팬아웃 패턴: SNS 메시지 하나 → 여러 SQS 큐로 전달해 병렬적이고 안정적으로 처리
메시지 필터링으로 구독자별 불필요한 알림을 줄임
데드 레터 큐가 실패한 메시지를 포착
푸시 알림에는 SNS, 안정적 처리에는 SQS, 신뢰성 있는 팬아웃에는 둘 다 활용

연습해 봅시다!

AWS 모니터링 및 문제 해결