▪️目的
AWSでシステムを運用していると、
- サーバーに異常が発生したら通知したい
- CloudWatchで検知したアラームを担当者へ知らせたい
- 複数の宛先へ同じ通知を送りたい
- アプリケーションで発生したイベントを別のシステムへ伝えたい
といった場面があります。
そこで利用されるAWSサービスの一つが、**Amazon SNS（Simple Notification Service）**です。
SNSは、メッセージや通知を複数の宛先へ配信するためのサービスです。
この記事では、AWS初心者の方向けに、SNSの基本的な仕組みから、Topic、Subscription、CloudWatchとの連携、実際の通知の流れまで分かりやすく解説します。
▪️SNSとは？
SNSとは、Amazon Simple Notification Serviceの略です。
簡単にいうと、
メッセージや通知を複数の宛先へ配信するためのマネージドサービス
です。
例えば、CloudWatchでサーバーの異常を検知したとします。
EC2
↓
CloudWatch
↓
異常を検知
↓
SNS
↓
担当者へ通知
という構成を作ることができます。
SNSを使うことで、通知を送る処理をアプリケーション側ですべて作り込まなくても、AWSのサービスを組み合わせて通知の仕組みを構築できます。
▪️SNSの基本的な仕組み
SNSを理解するうえで重要なのが、
- Topic
- Publisher
- Subscriber
- Subscription
という4つの言葉です。
まずは全体像を見てみましょう。
Publisher
│
▼
SNS Topic
│
├── Subscription → 宛先A
│
├── Subscription → 宛先B
│
└── Subscription → 宛先C
SNSでは、**Topic（トピック）**を中心としてメッセージを配信します。
▪️Topicとは？
Topicとは、
メッセージを配信するための論理的な窓口
のようなものです。
例えば、
SystemAlert
というTopicを作ったとします。
SystemAlert
というTopicにメッセージを送ると、そのTopicを購読している宛先へメッセージを配信できます。
イメージとしては、
SystemAlert Topic
│
┌─────────┼─────────┐
▼ ▼ ▼
Aさん Bさん Cさん
という形です。
Topicそのものが「メールアドレス」や「通知先」なのではなく、通知を配信するための中継地点と考えると分かりやすいでしょう。
▪️Publisherとは？
Publisherとは、
SNSへメッセージを送信する側
です。
例えばCloudWatch AlarmがSNS Topicへ通知を送る場合、CloudWatchがPublisher側になります。
CloudWatch
│
│ メッセージ
▼
SNS Topic
また、アプリケーションからSNSへメッセージを送信することもできます。
アプリケーション
│
▼
SNS Topic
この場合は、アプリケーションがPublisherです。
▪️Subscriberとは？
Subscriberとは、
SNS Topicからメッセージを受け取る側
です。
例えば、
SNS Topic
│
├── メール
├── Lambda
└── SQS
などを購読先として設定できます。
このように、1つのTopicに複数のSubscriberを設定できます。
▪️Subscriptionとは？
Subscriptionとは、
Topicと通知先を結びつける設定
です。
例えば、
SNS Topic
│
├── Subscription → メール
│
└── Subscription → Lambda
という構成にできます。
つまり、
Topic
↓
どこへ配信する？
↓
Subscription
↓
通知先
という関係です。
▪️SNSでメール通知してみる
SNSの代表的な利用方法が、メール通知です。
例えば、
CloudWatch Alarm
↓
SNS Topic
↓
Email
↓
担当者
という構成です。
EC2のCPU使用率が高くなった場合などに、担当者へ通知を送ることができます。
▪️CloudWatchとSNSを組み合わせる
ここまでの記事で紹介したCloudWatchとSNSは、非常によく組み合わせて利用されます。
例えば、
EC2のCPU使用率が80%以上になったら通知する
という仕組みを作るとします。
全体の流れは、
EC2
↓
CPU使用率
↓
CloudWatch
↓
CloudWatch Alarm
↓
SNS Topic
↓
メールなど
となります。
この構成によって、
「異常を検知する」→「担当者へ知らせる」
という運用ができます。
▪️実際の流れを見てみる
例えば、普段はEC2のCPU使用率が20%程度だったとします。
CPU使用率
20%
しかし、アクセスが急増して、
CPU使用率
85%
まで上昇したとします。
CloudWatch Alarmで、
CPU使用率 > 80%
という条件を設定していた場合、
EC2
↓
CPU 85%
↓
CloudWatch
↓
Alarmが条件を満たす
↓
SNS Topicへ通知
↓
Subscriberへ配信
という流れになります。
このように、SNSそのものが「異常を判断する」のではありません。
異常を判断するのはCloudWatch Alarmで、SNSはその結果を通知・配信する役割
と考えると分かりやすいでしょう。
▪️SNSは通知だけではない
SNSという名前から、
「メールを送るサービス」
と思ってしまうかもしれません。
しかし、SNSの役割はメール通知だけではありません。
SNSは、メッセージを複数の購読先へ配信する仕組みとして利用できます。
例えば、
SNS Topic
│
├── Email
├── Lambda
├── SQS
└── HTTP/S
など、さまざまな宛先と組み合わせることができます。
そのため、
「何かが起きたことを別のシステムへ伝える」
という用途にも利用できます。
▪️SNSとLambda
SNSはAWS Lambdaとも組み合わせることができます。
例えば、
SNS Topic
↓
Lambda
↓
何らかの処理
という構成です。
例えばアプリケーションからSNSへイベントを送信し、そのイベントをLambdaが受け取って処理する、といった構成が考えられます。
このようにSNSを使うことで、システム同士を直接強く結びつけるのではなく、メッセージを介して連携する構成を作ることができます。
▪️SNSとSQS
SNSと一緒に覚えておきたいAWSサービスが、Amazon SQSです。
SNSとSQSはどちらもメッセージングに関係しますが、役割が異なります。
簡単にいうと、
SNS
↓
メッセージを配信する
SQS
↓
メッセージをキューに保持する
という違いがあります。
例えば、
SNS
│
┌───────┴───────┐
▼ ▼
SQS-A SQS-B
│ │
▼ ▼
アプリA アプリB
のような構成もできます。
SNSから複数のSQSへメッセージを配信することで、複数のシステムへ同じイベントを伝えることができます。
▪️SNSとSQSのイメージ
例えば、
「新しい注文が発生した」
というイベントがあったとします。
SNSを使って、
新しい注文
↓
SNS Topic
│
├── SQS → 在庫処理
│
├── SQS → 発送処理
│
└── SQS → 集計処理
のように、複数の処理へイベントを配信できます。
このような仕組みは、システムを疎結合にするための考え方にもつながります。
▪️SNSを使うメリット
SNSを利用するメリットとして、主に以下が挙げられます。
① 複数の宛先へ配信できる
1つのTopicから複数のSubscriberへメッセージを配信できます。
SNS Topic
├── メール
├── Lambda
└── SQS
のような構成が可能です。
② AWSサービスと簡単に連携できる
CloudWatchなどのAWSサービスと組み合わせることで、
監視
↓
異常検知
↓
通知
という仕組みを比較的簡単に構築できます。
③ システム同士を疎結合にできる
システム同士が直接、
A → B
と通信するのではなく、
A
↓
SNS
↓
B
のようにメッセージを介して連携することで、システム同士の依存関係を減らせる場合があります。
▪️SNSを利用するときのポイント
SNSを設計するときは、単純にTopicを作ればよいわけではありません。
例えば、
- どのイベントを通知するのか
- Topicをどの単位で分けるのか
- 誰がPublishできるのか
- 誰がSubscribeできるのか
- どの宛先へ配信するのか
- 通知を受け取った後に何をするのか
- メッセージを再処理する必要があるか
などを考える必要があります。
特に、単純な「人への通知」なのか、それとも「システム間のイベント連携」なのかによって、設計の考え方も変わります。
▪️CloudWatch・SNS・SQSの関係
ここまでをまとめると、AWSの運用やシステム連携がかなり見えてきます。
例えば、
EC2
│
▼
CloudWatch
│
▼
CloudWatch Alarm
│
▼
SNS Topic
│
┌────────┴────────┐
▼ ▼
Email SQS
│
▼
アプリケーション
という構成です。
それぞれの役割は、
CloudWatch
↓
システムを監視する
CloudWatch Alarm
↓
条件を満たしたことを検知する
SNS
↓
メッセージを配信する
SQS
↓
メッセージをキューとして保持する
となります。
▪️CloudTrail・CloudWatch・SNSを合わせて考える
ここまでの記事で紹介してきたサービスを組み合わせると、AWSの運用設計がさらに分かりやすくなります。
IAM
↓
権限を管理
CloudTrail
↓
AWS操作を記録
CloudWatch
↓
システムを監視
CloudWatch Alarm
↓
異常を検知
SNS
↓
通知・メッセージを配信
つまり、
IAM → CloudTrail → CloudWatch → SNS
と、それぞれ違う役割を持っています。
AWSの運用では、このように複数のサービスを組み合わせて仕組みを作っていきます。
▪️SNSを理解するとAWSの「通知」が分かる
AWS初心者のうちは、
「CPUが高くなったらメールを送る」
という程度に見えるかもしれません。
しかし、実際には、
監視
↓
メトリクス
↓
条件判定
↓
アラーム
↓
メッセージ配信
↓
人間・別システム
という複数の仕組みが組み合わさっています。
この構造を理解すると、
「AWSのサービスを単体で覚える」のではなく、「サービス同士を組み合わせてシステムを作る」
というAWSの考え方が見えてきます。
▪️まとめ
今回は、AWSのSNSについて解説しました。
SNSは、メッセージや通知を複数の宛先へ配信するためのサービスです。
ポイントを整理すると、
- SNSはAmazon Simple Notification Serviceの略
- メッセージや通知を配信するサービス
- Topicを中心としてメッセージを配信する
- Publisherはメッセージを送信する側
- Subscriberはメッセージを受け取る側
- SubscriptionはTopicと通知先を結びつける設定
- CloudWatch Alarmと組み合わせて異常通知に利用できる
- メールだけでなく、LambdaやSQSなどとも連携できる
- SNSとSQSを組み合わせてシステム間のイベント連携を行うこともできる
- システム同士を疎結合にするためにも利用できる
特に今回の記事では、
CloudWatch＝監視する
CloudWatch Alarm＝異常を検知する
SNS＝メッセージを配信する
という関係を覚えておきましょう。
AWSでは、1つのサービスだけでシステムを完成させるのではなく、複数のサービスを組み合わせて、監視・通知・処理などの仕組みを構築していきます。
SNSは、その中でも「何かが起きたことを人や別のシステムへ伝える」という重要な役割を持つサービスです。
次回は、SNSとセットで覚えておきたいAmazon SQSについて解説します。
＊「Amazon SQS」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのsqsとは？メッセージを一時的に保存するキュー/」
No responses yet