SNS・SQS と CloudWatch の連携

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 トピックに送信し、Email・SMS・Lambda・SQS の各サブスクライバーにファンアウトされるフロー

SNS のコアコンセプト

コンポーネント

SNS はパブリッシャー／サブスクライバー方式：トピック、パブリッシャー、サブスクライバー
トピック：名前付きチャネル。パブリッシャーが送信し、サブスクライバーが受信
1 回の発行で全サブスクライバーに同時配信

サブスクライバープロトコル（1 トピック、複数エンドポイント）：

Email、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 に送られ、読みやすいメッセージに整形されて formatted-alerts トピックへ発行される。オンコールエンジニア向けに配信される一方、機械処理のコンシューマーは生のトピックを参照するチェーン構成

SQS を使ったファンアウトアーキテクチャ

1 つの SNS メッセージが複数の SQS キューと Lambda コンシューマーに配信されるファンアウトアーキテクチャ

ファンアウトの設定

4 つのステップ

SQS キューを作成する（コンシューマーごとに 1 つ）
キューポリシーを設定する（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 キューに送信し、ワーカーが処理する非同期処理パターン

1 つのアラームが複数の通知チャネルにファンアウトされるマルチチャネルアラートパターン

ソースイベントを複数の SQS キューにルーティングして処理するイベントパイプラインパターン

まとめ

SNS トピックはメール・SMS・HTTP・Lambda・SQS 経由でアラーム通知を配信します
ファンアウトパターン：1 つの SNS メッセージ → 複数の SQS キューで並列かつ確実に処理
メッセージフィルタリングでサブスクライバーごとのノイズを削減できます
デッドレターキューで処理に失敗したメッセージを捕捉します
プッシュ通知には SNS、確実な処理には SQS、信頼性の高いファンアウトには両方を組み合わせます

練習しましょう！

AWS のモニタリングとトラブルシューティング