はじめる前に
- 必須AWS アカウントを持ち、マネジメントコンソールにサインインできること
- 必須自分が受信できるメールアドレスを持っていること
- あると良い「複数の宛先に同時に知らせる」という考え方を聞いたことがある
※ コマンドラインや SSH などの操作は一切ありません。すべてブラウザのコンソール上で完結します。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
何かが起きたときに、複数の宛先へ同時に知らせたい場面はよくあります。メールを 1 件ずつ送る方法では、宛先が増えるたびに送信側の処理を増やす必要があります。SNS は「トピック」という掲示板のようなものを用意し、そこに発行（Publish）されたメッセージを、登録された宛先（メールなど）へ自動的に配る仕組みです。
今回は手動でメッセージを発行し、コンソールでの操作からメールが届くまでの流れを体感します。
メールを直接送るのと何が違うの？
直接送る場合は、宛先を 1 つずつ指定する必要があります。SNS はトピックに登録された宛先全部へ同時に配信されるため、宛先が増えても発行する側の操作は変わりません。
後で Lambda や他のサービスから自動で発行することもできるの？
今回は手動でメッセージを発行しましたが、実際の運用では CloudWatch のアラームなど、他の AWS サービスが自動でメッセージを発行する場合が多くあります。今回学ぶのは「発行されたメッセージがどう配られるか」という配信の仕組み自体です。
SNS トピックを 1 つ作り、Eメールサブスクリプションを登録・確認（Confirm）した上で、コンソールからメッセージを手動発行し、登録したメールアドレスに届くことを確認する。
つくる構成
コンソールから発行したメッセージが、SNS トピックを経由して、登録したメールアドレスへ自動的に配信されるまでの流れです。
メッセージを発行
自動的に配信
通知が届く
要件
以下の要件を満たし、メッセージの発行からメール受信までの一連の流れを確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | SNS トピックを 1 つ作成する（タイプ「スタンダード」、名前は自由、例：my-first-topic）。 |
| 3 | Eメールサブスクリプションを登録し、届いた確認メールのリンクをクリックして確認（Confirm）する。 |
| 4 | コンソールから「メッセージを発行」し、登録したメールアドレスに届くことを確認する（件名・本文は自由）。 |
構築の進め方
「トピックを作る → 宛先を登録して確認する → メッセージを発行する → メールを確かめる」という順番で進みます。
-
マネジメントコンソールにサインインし、リージョンを合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
SNS トピックを作成する
SNS コンソールの「トピック」→「トピックの作成」を開きます。タイプ「スタンダード」を選び、名前を自由に決めて（例：
my-first-topic）作成します。 -
Eメールサブスクリプションを作成し、確認（Confirm）する
作成したトピックの「サブスクリプションの作成」で、プロトコル「Eメール」を選び、エンドポイントに自分が受信できるメールアドレスを入力します。作成すると確認メールが届くので、メール内の「Confirm subscription」リンクをクリックします。
確認しないと配信されないサブスクリプションの状態が「Pending confirmation（確認待ち）」のままだと、メッセージをいくら発行してもメールは届きません。必ずリンクをクリックして「Confirmed」にしておきましょう。
-
コンソールからメッセージを発行する
トピックの詳細画面から「メッセージの発行」を開き、件名・本文を自由に決めて入力し、発行します。
-
登録したメールアドレスの受信ボックスを確認する
数分待ち、手順 3 で登録したメールアドレスの受信ボックスを確認します。手順 4 で発行した件名・本文を含むメールが届いていれば成功です。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。
「発行はできているのに、受信ボックスに何も増えない」
サブスクリプションの状態を確認してみましょう。確認（Confirm）をしていないと、いくら発行してもメールは届かず、状態は「Pending confirmation」のままです。SNS コンソールの「サブスクリプション」一覧で状態を見直してみましょう。
「確認メールや通知メールがどこにも見当たらない」
迷惑メールフォルダに振り分けられている可能性があります。送信元のアドレス（no-reply@sns.amazonaws.com など）で検索してみましょう。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。各コンソールを開いて、次を順に確かめましょう。
- SNS コンソールの「トピック」一覧に、作成したトピックが表示されている。
- トピックの「サブスクリプション」一覧で、状態が「Confirmed」になっている。
- 「メッセージの発行」を実行したあと、エラーメッセージが表示されていない。
- 登録したメールアドレスの受信ボックスに、発行した件名・本文を含むメールが届いている。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- メールを 1 件ずつ送る方法と比べて、SNS のトピック経由で送る方法はどんな場面で有利でしょうか。
ヒント
宛先が 1 つだけのときはあまり差を感じませんが、宛先が 10 件、100 件と増えていく場面を想像してみましょう。直接送る方法では宛先が増えるたびに送信側の処理を変更する必要がありますが、トピック経由ではどうなるか、変更の手間という観点から考えてみましょう。 - 今回はメールだけを宛先にしましたが、複数の宛先（メールと SMS など）を同時に登録したらどうなりそうでしょうか。
ヒント
SNS のサブスクリプションは、1 つのトピックに対して複数のプロトコル（メール、SMS、Lambda など）を同時に登録できます。1 回の発行が、登録されているすべての宛先に同時に配信される、という仕組みから考えてみましょう。 - 将来的に別の AWS サービスがこのトピックに自動でメッセージを発行するとしたら、今回手動で行った「発行」操作は誰が代わりに行うことになるでしょうか。
ヒント
今回はあなた自身がコンソールから「発行」のボタンを押しました。実際の運用では、何らかの条件を監視している別のサービス（例えば CloudWatch のアラームなど）が、その条件に当てはまったタイミングで、人の代わりに発行を行います。発行する主体が人からサービスに置き換わるだけで、トピック以降の配信の仕組みは変わらない、という点から考えてみましょう。
後片づけ
作ったものを片づけるところまでが一連の流れです。次の順で進めると迷いにくいです。
- サブスクリプションを削除する：SNS コンソールの「サブスクリプション」一覧から、今回作成したものを選び「削除」します。
- トピックを削除する：「トピック」一覧から、今回作成したトピック（例：
my-first-topic）を選び「削除」します。トピックを削除すると、紐づくサブスクリプションも合わせて削除されます。
削除するのは、このハンズオンで自分が作ったものだけ
トピックやサブスクリプションの一覧には、すでに別の用途で使っているものが並んでいるかもしれません。間違えて削除しないよう、このハンズオンのために付けた名前のものだけを選んで削除してください。
コストに関する注意: SNS は少量の利用であれば無料利用枠の範囲内で収まります（Eメール通知は月 1,000 件まで無料が目安です）。今回作成したトピック・サブスクリプション・発行したメッセージの範囲では課金されることはありません。最新の料金は AWS の公式料金ページで確認してください。