SNSメール通知が届かない原因と対処法：サブスクリプション確認を忘れていませんか？

SNSトピックを作成してメールアドレスを登録したのに、アラートが一切届かない——本番環境の監視を設定した直後にこの状況に陥ると、「SNSが壊れているのか、IAMが間違っているのか」と疑い始めてしまう。ほとんどの場合、原因はずっとシンプルだ。サブスクリプション確認メールのリンクをクリックしていない、それだけである。

TL;DR：SNSメール通知が届かない場合の確認ポイント

確認順序確認内容期待される状態
1サブスクリプションのステータスconfirmed（PendingConfirmationは未確認）
2確認メールの受信（迷惑メールフォルダ含む）件名「AWS Notification - Subscription Confirmation」
3SNSトピックのアクセスポリシーパブリッシュ権限が正しく設定されている
4送信元サービスのIAMロールSNSトピックへのsns:Publish権限を保持
5CloudWatchアラームのアクション設定正しいSNSトピックARNが指定されている

SNSメール通知の仕組み：なぜ確認が必要なのか

Amazon SNSのEmailサブスクリプションは、スパム防止のためにダブルオプトイン方式を採用している。エンドポイント（メールアドレス）を登録した時点では、サブスクリプションはPendingConfirmation状態になる。この状態では、トピックにメッセージがパブリッシュされても、そのエンドポイントには配信されない。確認リンクをクリックして初めてconfirmed状態に遷移し、通知が届くようになる。

graph TD A["sns:Subscribe 呼び出し"] --> B["PendingConfirmation 確認メール送信"] B --> C{"確認リンクを クリックしたか？"} C -- "No（期限切れ含む）" --> D["メッセージ配信されない 再サブスクライブが必要"] C -- "Yes" --> E["Confirmed サブスクリプション有効"] E --> F["Publish 呼び出し"] F --> G["メール配信成功"]
  1. Subscribe呼び出し：メールアドレスをエンドポイントとしてSNSトピックに登録する
  2. PendingConfirmation：SNSが確認メールを送信し、サブスクリプションは保留状態になる
  3. 確認リンクのクリック：メール内のリンクをクリックすることでSNSに確認を通知する
  4. Confirmed：サブスクリプションが有効化され、以降のパブリッシュが配信される
  5. Publish → 配信：CloudWatchアラームなどからのメッセージが実際にメールとして届く
確認リンクには有効期限がある。SNSの確認トークンは3日間有効で、期限切れ後は再サブスクライブが必要になる。「確認メールが来ていたけど後で見ようと思っていた」というケースで期限切れになっていることが多い。

SNSサブスクリプション確認：ステップバイステップの診断と修正

ステップ1：サブスクリプションのステータスを確認する

まず現在のサブスクリプション状態を確認する。PendingConfirmationが表示されていれば、確認リンクのクリックが完了していないことが確定する。IAMやトピックポリシーを疑う前に、ここを見るだけで原因が判明することがほとんどだ。

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

出力のSubscriptionArnフィールドがPendingConfirmationになっていれば、確認が未完了である。confirmed状態の場合は、別の原因（ステップ3以降）を調査する。

ステップ2：サブスクリプションを再作成して確認メールを再送する

確認メールが見つからない、または有効期限が切れている場合は、既存のサブスクリプションを削除して再作成する。再作成することで新しい確認メールが送信される。今度は迷惑メールフォルダも含めて即座に確認すること。

# 既存のPendingConfirmationサブスクリプションを削除（ARNがPendingConfirmationの場合は削除不要なケースもあるため確認）
aws sns unsubscribe \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --region us-east-1

# メールアドレスを再登録
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --protocol email \
  --notification-endpoint your-email@example.com \
  --region us-east-1

受信した確認メールの件名は「AWS Notification - Subscription Confirmation」となる。メール本文内の「Confirm subscription」リンクをクリックすることで確認が完了する。

ステップ3：SNSトピックのアクセスポリシーを確認する

サブスクリプションがconfirmed状態なのに通知が届かない場合、トピックポリシーがパブリッシュを拒否している可能性がある。特にCloudWatchやEventBridgeなど他のAWSサービスからSNSにパブリッシュする場合、サービスプリンシパルへの許可が必要になる。

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

CloudWatchアラームからパブリッシュする場合、トピックポリシーに以下のステートメントが含まれている必要がある。

🔽 CloudWatch用SNSトピックポリシー例（クリックして展開） 
{
  "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",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:*"
        }
      }
    }
  ]
}

ステップ4：CloudWatchアラームのアクション設定を確認する

サブスクリプションもポリシーも問題ないのに通知が来ない場合、CloudWatchアラームが正しいSNSトピックARNを参照しているか確認する。アラームのアクションにSNSトピックが設定されていない、またはARNが誤っているケースが意外と多い。

aws cloudwatch describe-alarms \
  --alarm-names "MyAlarmName" \
  --region us-east-1 \
  --query 'MetricAlarms[*].{AlarmName:AlarmName,AlarmActions:AlarmActions,StateValue:StateValue}'

AlarmActions配列に対象のSNSトピックARNが含まれていることを確認する。空配列または別のARNが設定されている場合は、アラームを更新する必要がある。

aws cloudwatch put-metric-alarm \
  --alarm-name "MyAlarmName" \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --region us-east-1 \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0

ステップ5：テストメッセージを手動パブリッシュして疎通確認する

CloudWatchアラームの状態遷移を待たずに、SNSトピックへ直接メッセージをパブリッシュして配信経路を検証する。これにより、SNS→メール配信の経路自体が機能しているかをアラームとは独立して確認できる。

aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MyAlertTopic \
  --subject "SNS疎通テスト" \
  --message "このメッセージが届けば、SNSからメールへの配信は正常に機能しています。" \
  --region us-east-1

このコマンドでメールが届けば、SNSとサブスクリプションは正常だ。届かなければ、サブスクリプションのステータスに戻って再確認する。届いた場合にCloudWatchからの通知だけが来ないなら、アラームのアクション設定またはトピックポリシーの問題に絞り込める。

graph TD Start["メール通知が届かない"] --> S1["ステップ1: サブスクリプション ステータス確認"] S1 --> Q1{"PendingConfirmation？"} Q1 -- "Yes" --> Fix1["ステップ2: 再サブスクライブ 確認リンクをクリック"] Fix1 --> Done["解決"] Q1 -- "No（confirmed）" --> S3["ステップ3: トピックポリシー確認"] S3 --> Q2{"Publishが許可 されているか？"} Q2 -- "No" --> Fix2["ポリシーにサービス プリンシパルを追加"] Fix2 --> Done Q2 -- "Yes" --> S4["ステップ4: CloudWatchアラーム アクション確認"] S4 --> Q3{"正しいSNS ARNが 設定されているか？"} Q3 -- "No" --> Fix3["put-metric-alarmで アクションを修正"] Fix3 --> Done Q3 -- "Yes" --> S5["ステップ5: 手動Publishで 疎通確認"] S5 --> Q4{"テストメールが 届いたか？"} Q4 -- "Yes" --> Inv["アラーム状態遷移を 調査"] Q4 -- "No" --> Back["ステップ1に戻り 再確認"] Inv --> Done

実際の現場で起きた誤診パターン

「SNSのパブリッシュが失敗しているはずだ」と思い込んで、IAMロールのポリシーを1時間かけて見直したことがある。CloudTrailでSNS:Publishのイベントを検索しても見つからない。「権限エラーだ」と確信してsns:Publishを追加しようとしたところ、すでに付与されていた。

実際の原因はサブスクリプションがPendingConfirmationのままだったことだ。SNSはパブリッシュ自体は成功させる——ただしconfirmedでないエンドポイントには配信しないだけだ。CloudTrailにはPublish成功のログが残るが、メールは届かない。この非対称な動作が誤診を引き起こす。

SNSのパブリッシュ成功とエンドポイントへの配信成功は別の概念である。

必要なIAM権限

SNSトピックの管理とサブスクリプション操作を行うユーザーまたはロールには、以下の権限が必要になる。

🔽 SNS管理用IAMポリシー例（クリックして展開） 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SNSTopicManagement",
      "Effect": "Allow",
      "Action": [
        "sns:ListSubscriptionsByTopic",
        "sns:GetTopicAttributes",
        "sns:Subscribe",
        "sns:Unsubscribe",
        "sns:Publish"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:MyAlertTopic"
    },
    {
      "Sid": "CloudWatchAlarmManagement",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:DescribeAlarms",
        "cloudwatch:PutMetricAlarm"
      ],
      "Resource": "*"
    }
  ]
}

cloudwatch:DescribeAlarmsおよびcloudwatch:PutMetricAlarmはリソースレベルの制限をサポートしていないアクションが含まれるため、Resource: "*"が必要になる場合がある。AWS Service Authorization Referenceで最新の対応状況を確認すること。

まとめとネクストステップ：SNSメール通知の確実な運用

SNSのメール通知が届かない問題の大半は、サブスクリプションのPendingConfirmation状態、つまり確認リンクの未クリックが原因だ。診断の順序は明確で、まずサブスクリプションのステータスを確認し、confirmedであれば次にトピックポリシー、アラームのアクション設定へと進む。

本番環境では、SNSトピックの作成とサブスクリプション登録をIaC（CloudFormationやTerraform）で自動化することを検討する。ただし、Emailサブスクリプションの確認は自動化できないため、デプロイ後に必ず手動で確認ステータスを検証するプロセスを組み込むこと。

用語集

用語説明
SNSトピックメッセージの送受信を仲介するAmazon SNSのチャネル。パブリッシャーがメッセージを送り、サブスクライバーが受け取る
サブスクリプションSNSトピックとエンドポイント（メールアドレスなど）の紐付け。確認完了後に有効化される
PendingConfirmationサブスクリプション登録後、確認リンクのクリック前の保留状態。この状態ではメッセージが配信されない
トピックポリシーSNSトピックへのアクセスを制御するリソースベースのポリシー。他のAWSサービスからのパブリッシュ許可もここで設定する
sns:PublishSNSトピックにメッセージを送信するIAMアクション。CloudWatchアラームなどのサービスがこの権限を必要とする

Related Posts

コメント

コメントを投稿

このブログの人気の投稿

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む

EC2インスタンスIDをメタデータから取得する方法 — IMDSv2が安全な理由

サーバー上で動作するスクリプトから自分のインスタンスIDを取得したい場面は多い。デプロイスクリプト、ログ集約、Auto Scalingグループのインベントリ管理など、用途は様々だ。ただし、EC2インスタンスメタデータサービス（IMDS）には2つのバージョンが存在し、 IMDSv1とIMDSv2の選択はセキュリティ上の重大な差異 を生む。本番環境でIMDSv1を使い続けることは、SSRF（Server-Side Request Forgery）攻撃の踏み台になるリスクを放置することと同義だ。 TL;DR — IMDSv1 vs IMDSv2 早見表 観点 IMDSv1 IMDSv2 認証方式 なし（直接GETのみ） セッショントークン必須（PUT → GET） SSRF耐性 なし あり（PUT不可なSSRFはトークン取得不可） TTL制御 なし X-aws-ec2-metadata-token-ttl-secondsで指定 デフォルト状態 新規インスタンスでも有効（設定次第） IMDSv2-onlyに変更可能 推奨度 非推奨 AWS公式推奨 IMDSの仕組み — なぜインスタンス内からだけ到達できるのか EC2インスタンスメタデータサービスは、リンクローカルアドレス 169.254.169.254 で提供される。このアドレスはRFC 3927で定義されたリンクローカル範囲であり、インスタンスのネットワークインターフェース外には到達できない。つまり、インターネット経由や他のインスタンスから直接アクセスすることは原理的に不可能だ。 ただし、 SSRF脆弱性があるアプリケーションが動作している場合は話が変わる 。攻撃者がアプリケーションを経由して http://169.254.169.254/latest/meta-data/iam/security-credentials/ へリクエストを誘導できれば、インスタンスにアタッチされたIAMロールの一時クレデンシャルを盗める。IMDSv1はこのシナリオに対して無防備だ。 graph TD subgraph v1[...
続きを読む