AWS SNSって何ができるの?仕組みをやさしく解説&誰でもシンプルに試せる方法

AWS SNSって何ができるの?仕組みをやさしく解説&誰でもシンプルに試せる方法

※当ブログでは商品・サービスのリンク先にプロモーションを含みます。ご了承ください。

AWS SNSという名前は聞いたことがあるけれど、「結局何ができるの?」「自分で使う場面あるの?」と思っている方は多いのではないでしょうか。

自分もその一人で、公式ドキュメントを読んだだけではいまいちピンとこなかったので、実際に手を動かして試してみることにしました。

この記事では、AWS SNSの仕組みを非エンジニアの方にもわかるようにやさしく解説したうえで、一番シンプルな構成でメール通知を送るところまでを紹介します。

「とりあえず触ってみたい」「理屈より先に動かしたい」という方にも参考になるはずです。

AWS SNSとは?「通知を届けるハブ」をイメージするとわかりやすい

AWS SNS(Amazon Simple Notification Service)は、ひとことで言うと「何か起きたことを、複数の相手に一斉通知するためのサービス」です。

たとえば「注文が入った」「サーバーに異常が起きた」「画像のアップロードが完了した」といったイベントが発生したとき、それをメール・SMS・Slack・Lambdaなど複数の宛先へまとめて届けてくれます。

イメージとしては「拡声器」が近いです。1回叫べば、登録されている全員に届く。

個別にメールを送ったり、Slackに書き込んだりする処理をアプリ側で一つずつ書く必要がなくなります。

SNSを理解するうえで押さえておきたいのが、次の3つの登場人物です。

用語 役割 イメージ
トピック(Topic) 通知の受け皿 掲示板
サブスクリプション(Subscription) 「この掲示板の更新をメールで受け取る」的な購読登録 フォロー設定
パブリッシュ(Publish) 掲示板に投稿する=通知を発信する 投稿ボタンを押す

流れとしてはこうなります。

1. トピックを作る(通知の受け皿を用意)
2. トピックにサブスクリプションを追加する(「メールで届けて」「Slackに流して」などを登録)
3. トピックにパブリッシュする(通知を発信)
4. 登録されているすべての宛先に、同じ通知が届く

この「トピック → サブスクリプション → パブリッシュ」の3ステップがSNSの基本構造です。

「1回送れば全員に届く」けど、宛先ごとに内容は変えられない

「1回の通知で複数に届くなら、顧客にはお礼メール、社内にはデータ付き通知、みたいに内容を分けられるの?」と思うかもしれません。

残念ながら、SNS単体ではそれはできません。

1回のパブリッシュで届くメッセージは、すべての宛先に対して同じ内容になります。

つまりSNSは、「誰に届けるか」を増やすのは得意だけど、「宛先ごとに内容を変える」のは守備範囲外ということです。

もし宛先ごとに内容を変えたい場合は、SNSの先にLambdaなどの処理を挟んで分岐させる設計が一般的です。

注文完了
↓
SNSトピックに1回パブリッシュ
├─ 顧客向けLambda → お礼メール送信
└─ 社内向けLambda → データ付き通知送信

SNSはあくまで「通知を広げるハブ」で、内容の加工はその先に任せる、という役割分担です。

宛先の上限や、途中で配信失敗したらどうなる?

「宛先をいくらでも増やせるの?」「10件に送って途中で失敗したら全部やり直し?」という疑問も出てくると思います。

まず宛先の上限について。完全に無制限ではなく、SNSにはクォータ(上限)があります。

Standardトピックなら1トピックあたり最大1,250万件のサブスクリプションが可能です。

個人利用や検証レベルであれば、まず気にする必要はありません。

次に配信失敗時の挙動について。

SNSは宛先ごとに独立して配信するので、たとえば10件中8件目で失敗しても、残りの1〜7件目と9〜10件目には影響しません。

「1件コケたから全部やり直し」にはならないということです。

失敗した宛先に対しては自動で再試行が行われ、それでもダメな場合はDLQ(デッドレターキュー)という「配信できなかったメッセージの避難先」に送ることもできます。

SNSとSQSはよく混同されるけど、役割がまったく違う

AWSにはSNSとよく似た名前のSQS(Simple Queue Service)というサービスがあります。名前が紛らわしいですが、役割はまったく別物です。

  • SNS = 配る(拡声器):イベントを複数の宛先に同時配信する
  • SQS = ためる(待機列):メッセージをキューに保持して、後から順番に処理する

実務ではこの2つを組み合わせて、「SNSでイベントを配り、各処理はSQSに受けて後でさばく」という設計もよく使われます。

今回の記事ではSNS単体に絞って試していきます。

AWS SNSの料金は?無料枠で十分試せる

「試してみたいけど、料金が気になる」という方も安心してください。

AWS SNSには無料枠が用意されています。

毎月の無料枠はこのとおりです。

項目 無料枠
SNSリクエスト(パブリッシュなど) 月100万件
HTTP通知 月10万件
Eメール通知 月1,000件

無料枠を超えた場合も、たとえばリクエストは100万件あたり$0.50、Eメール通知は10万件あたり$2.00と、かなり安価です。

SMS(ショートメッセージ)は送信先の国によって料金が変わるので、使う場合は事前に確認しておくのがおすすめです。

今回の検証のように「トピックを1つ作って、数回メールを送る」程度なら、無料枠の範囲で余裕を持って試せます。

実際にAWS SNSでメール通知を試してみた【最小構成】

ここからは、実際にAWSコンソールを使ってSNSのメール通知を試していきます。

今回試す構成はこれだけです。

手動 or AWS CLI → SNSトピック → メール

サブスクリプションはメール1件だけ。

複数の宛先やSlack連携などは一切なしの、一番シンプルな構成です。

まずはSNSの基本動作を体感することを目的にしています。

SNSトピックを作成する

AWSコンソールにログインしたら、サービス一覧から「Amazon SNS」を開きます。

SNSのトップページが表示されます。

左メニューの「トピック」を開くと、まだ何もない状態です。

ここから「トピックの作成」をクリックします。

トピックの作成画面では、以下のように設定します。

  • タイプ: 「スタンダード」を選択
  • 名前: 任意の名前を入力(今回は `test-email-topic`)

タイプは「スタンダード」と「FIFO」の2種類があります。

FIFOは順序保証や重複排除が必要なケース向けですが、今回のような基本的なメール通知にはスタンダードで十分です。

画面を下にスクロールすると、暗号化やアクセスポリシーなどのオプションが並んでいますが、今回はすべてデフォルトのままでOKです。

ちなみに「表示名」という項目がありますが、これはSMS(ショートメッセージ)で使うものなので、メール通知だけなら空欄で問題ありません。

そのまま「トピックの作成」をクリックすると、トピックが作成されます。

 

トピックの詳細画面が表示され、ARN(トピックの識別子)やタイプなどが確認できます。

この時点ではまだサブスクリプションが0件なので、通知を送っても届け先がない状態です。

サブスクリプション(メール)を作成する

トピックができたら、次は「どこに届けるか」を登録します。

トピック詳細画面の下部にある「サブスクリプションの作成」をクリックします。

設定内容はシンプルです。

  • トピックARN: 先ほど作成したトピックが自動で入っています
  • プロトコル: 「Eメール」を選択
  • エンドポイント: 通知を受け取りたいメールアドレスを入力

入力したら「サブスクリプションの作成」をクリックします。

作成直後はステータスが「保留中の確認」になっています。

これはまだメールアドレスの持ち主が承認していない状態です。

確認メールを承認する ― ここで気づく「メーリングリスト向きではない」理由

サブスクリプションを作成すると、登録したメールアドレス宛にAWSから確認メールが届きます。

メール内の「Confirm subscription」リンクをクリックすると、承認完了の画面が表示されます。

AWSコンソールに戻ると、サブスクリプションのステータスが「確認済み」に変わっているのが確認できます。

これでこのメールアドレスへの通知が有効になりました。

ここで一つ気づくことがあります。SNSのメール通知は、受信者本人が確認リンクを押さないと有効にならないということです。

つまり、顧客のメールアドレスを登録して一方的に通知を送る、といった使い方はできません。

メーリングリストや顧客向けの一括メール配信には向いていないわけです。

顧客向けのメール送信が目的なら、同じAWSでもAmazon SES(Simple Email Service)の方が適しています。

SNSのメール通知は、どちらかというと社内通知や監視アラートなど、「受け取りたい人が自分で購読する」タイプの用途に向いていると考えるとわかりやすいです。

Amazon SESについては、自分も近いうちに同じように実際に試してみたいと思っているので、そのときはまた記事にする予定です。

AWSコンソールからメッセージを発行してみる ―「正直、ただのメーラーじゃない?」

サブスクリプションの確認が完了したら、いよいよメッセージを送ってみます。

トピック詳細画面の「メッセージの発行」をクリックします。

入力する項目はシンプルです。

  • 件名: 任意(今回は空欄にしました。理由は後述)
  • メッセージ本文: 送りたいテキストを入力

ちなみに件名について少し補足すると、AWSコンソールからの入力では件名がASCII文字(半角英数)のみ対応になっていて、日本語を入れるとエラーになりました。

ここでは空欄のまま送信しています。

「メッセージの発行」をクリックすると、発行完了の画面が表示されます。

メールを確認すると、ちゃんと届いていました。

件名を空にしたので、デフォルトの「AWS Notification Message」という件名になっています。

届いたことは確認できたのですが、ここで正直に思ったことがあります。

「これ、ただのメーラーでメール送信してるのと変わらなくない?」

トピックを作って、メールアドレスを登録して、手動でメッセージを入力して送信する。

やっていることは普通にメールを送るのとほとんど同じに見えます。

この感覚は間違っていません。

今やっているのはSNSの最小動作確認なので、SNSらしさはまだ薄い状態です。

SNSの本領が発揮されるのは、手動で送信するのではなくイベントを起点に自動で通知が飛ぶ構成にしたときです。

次のセクションでは、AWS CLIを使ってプログラムから通知を発火する方法を試してみます。

ここでようやく「SNSっぽさ」が見えてきます。

AWS CLIからメッセージを発行してみる ― ここでようやく「SNSっぽさ」を実感

コンソールから手動でメッセージを送るだけだと、正直SNSの良さはわかりにくいです。

実際の運用では、注文完了や受付完了のタイミングでプログラムから自動的に通知を発火するのが一般的です。

その疑似体験として、AWS CLIからSNSトピックにメッセージを送ってみます。

AWS CLIの準備

AWS CLIは、ターミナルからAWSの各サービスを操作できる公式ツールです。

まだインストールしていない場合は、以下のコマンドでインストールできます(Macの場合)。

brew install awscli

インストール後、認証情報を設定します。

aws configure

AWSアクセスキーID、シークレットアクセスキー、リージョン(東京なら `ap-northeast-1`)を入力すれば準備完了です。

すでに別の用途でAWS CLIを使っている場合は、プロファイルを分けると既存の設定を壊さずに済みます。

aws configure --profile sns-test

この場合、コマンド実行時に `–profile sns-test` を付けることで認証先を切り替えられます。

SNSトピックにメッセージを送る

準備ができたら、以下のコマンドでSNSトピックにメッセージを発行します。

aws sns publish \
--topic-arn arn:aws:sns:ap-northeast-1:xxxxxxxxxxxx:test-email-topic \
--message "注文受付完了のテスト通知" \
--subject "受付完了" \
--profile sns-test

`–topic-arn` にはトピック詳細画面に表示されているARNをそのまま貼り付けます。

コンソールでは日本語の件名がエラーになりましたが、CLIからは問題なく送信できました。

メールを確認すると、件名「受付完了」、本文「注文受付完了のテスト通知」でちゃんと届いています。

この瞬間が、自分にとって一番「SNSっぽさ」を感じたタイミングでした。

ローカルのCLI(プログラムの代わり)
↓
SNSトピック
↓
メール

手動でメッセージを入力して送るのではなく、コマンド1本で通知が飛ぶ。

これを `aws sns publish` ではなくアプリのコードに置き換えれば、注文完了や受付完了をトリガーにした自動通知の仕組みがそのまま作れるわけです。

AWS SNSを実際に試してみて感じたこと

今回、AWS SNSをゼロから触ってみて感じたのは、SNSは「メール送信サービス」ではなく「通知ハブ」だということです。

コンソールから手動でメッセージを送っているだけだと、正直ただのメーラーにしか見えませんでした。

でもAWS CLIからコマンド1本で通知を飛ばしてみたとき、「ああ、これはプログラムから使うことで初めて意味が出てくるサービスなんだな」と腹落ちしました。

SNSの仕組み自体はとてもシンプルで、覚えることは3つだけです。

  • トピックを作る(通知の受け皿)
  • サブスクリプションを追加する(届け先の登録)
  • パブリッシュする(通知の発信)

今回はメール1件だけのシンプルな構成でしたが、サブスクリプションを増やせばSlackやLambda、SQSなど複数の宛先に同時配信することもできます。

「AWSのサービスって難しそう」と感じている方も、まずはこの最小構成で触ってみると、思った以上にシンプルに動くことが体感できるはずです。