はじめに

きっかけ

突然ですが、賃貸物件を探すのって大変ですね。

転職を機に職場の近くに引越しをしたいと物件を探していますが
家賃の高騰に目を白黒させている数ヶ月
「この値段なら、以前から狙っていた楽器演奏可能、防音物件に住めるのでは」
と既に当初の目的から外れ始めています。

楽器演奏可能物件をはじめ、賃貸物件は
「最初に申し込みをした人の早い者勝ち」が基本で
1月から3月の繁忙期は特に、
物件情報が出てからのレスポンススピードが命。

物件に空きが出た時にメールを送っていただく
ウェイティング登録はしたものの、
登録した覚えのないメールマガジンが大量に来るため
日中にGmailを都度チェックなどはしませんので
先手を取られる可能性大。

作るもの

前置きが長くなってしまいましたが

特定のワード（今回は狙っているマンション名）を含むメールを受信
↓
応答するまで何度もコールする電話通知

があれば良いのでは？

巷にも同様のサービスがありますが、初期費用/月額費用だけでなかなかのお値段
個人で利用するのはハードルが高いため

Route53 + Amazon SES + S3 + EventBrigde + SSM Incident Managerで
簡単な通知の仕組みを作成しました。

流石に賃貸の契約関係となるため、
「申込します！」というメールの自動返信はまずいので
（賃料が変更されているかもしれませんし）
「電話でコールされメールに気がつく→メールを確認してメール返信」
部分はシステム化対象外としました。

注意点

リージョンは米国東部(バージニア北部）を利用します。
（Incident Managerの電話通知が東京に対応していないため）
メール受信用の独自ドメイン取得に年額のコストがかかります。
（Route53の場合、＄13/年程）
Route53のホストゾーン、incident Manager等利用で月額のコストがかかります。（＄20/月程）
個人の携帯電話番号を登録しますので、自己責任で。

構成図

手順

メール受信用の独自ドメイン取得（Route53）

今回はRoute53を使用します。
ウィザードに従って任意のドメインを取得、連絡先情報を入力します。
（キャプチャは例です。実際にこのドメインは取得していません。）

独自ドメインのSES検証

SES > 検証済みID > IDの作成　から先程Route53で取得したドメインを指定

数分するとドメイン認証が完了し、IDステータスが「検証済み」になります。

独自ドメインのMXレコード作成

Route53 > ホストゾーン　より、取得したドメインのホストゾーンを選択　> レコードを作成
レコードタイプ　: MX – メールサーバーを指定します
レコード名　: サブドメインにしない場合は、空白
値　: 10 inbound-smtp.us-east-1.amazonaws.com

メール受信設定（Amazon SES + S3）

SES > Eメール受信 > ルールセットの作成　からルールセットを作成
作成したルールセット > ルールの作成 > 受信者の条件で
任意の受信メールアドレス（先程Route53で取得したドメイン）を指定します。

「アクションの追加」で「S3バケットに配信」を選択し、
メールが蓄積されるS3バケット名を指定します。

お使いのメーラーでメール転送設定

Gmailの場合は転送したい条件でメールフィルタを作成し、
先程設定した受信メールアドレスに転送設定します。

S3のバケットにGmailの転送設定確認メールが蓄積されることを確認し
転送設定確認メール内のURLにアクセスして転送設定を承認します。

S3証跡確認（CloudTrail）

CloudTrailによる対象S3バケットのイベントログの記録を設定します。

CloudTrail > 証跡の作成
証跡を保存する任意のS3バケット、任意のAWS KMS エイリアスを指定します。

イベントログの記録を行う対象を指定します。
イベントタイプ : データイベント
データイベントソース : S3
ログセレクターテンプレート : カスタム
高度なイベントセレクター　: メールが蓄積されるS3バケットのARNを指定

電話通知設定（Incident Manager）

AWS Systems Manager > Incident Manager
初期セットアップ操作で通知先の電話番号を設定します。
下記ページの「やってみた」を参照いただき登録操作をおこなってください。

※登録した電話番号に架電があり、
自動英語音声にて案内された6桁の数字を入力する必要があります。
頑張ってリスニングしましょう。

対応プランの設定（Incident Manager）

AWS Systems Manager > Incident Manager >　対応プラン　>　対応プランを作成

名前 : 任意
タイトル : 任意
影響 : 中
エンゲージメント : Incident Managerで設定した連絡先設定

通知設定（EventBridge）

Amazon EventBridge > イベントブリッジルール　>　ルールを作成

イベントソース : その他
サンプルイベント : 入力しない
作成のメソッド : カスタムパターン（JSON エディタ）
イベントパターン :　下記の通り


{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["PutObject"],
    "requestParameters": {
      "bucketName": ["メールが蓄積されるS3バケット名"]
    }
  }
}

インシデントの送信先（ターゲット）を指定します。

ターゲットを選択 : Insident Manager レスポンスプラン
レスポンスプラン : 先程作成した対応プラン

動作確認

Gmail宛に転送したい条件でメールを送信すると、SESにメール転送・S3に格納され
設定した電話番号宛にSSM Incident Managerによる
電話通知（自動英語音声）が来ます。

補足・つまづきポイント

通知設定（EventBridge）のイベントパターンはS3イベント通知でもOK

メールが蓄積されるS3バケットでEventBridgeへの通知許可をします

通知設定（EventBridge）を下記設定にします
イベントソース : AWS イベントまたは EventBridge パートナーイベント
サンプルイベント : 入力しない
作成のメソッド : パターンフォームを使用する
イベントソース :　AWSのサービス
AWSのサービス :　S3
イベントタイプ :　Amazon S3 イベント通知
イベントタイプの仕様１ :　特定のイベント「Object　Created」
イベントタイプの仕様２ :　特定のバケット（名前別）「メールが蓄積されるS3バケットのARNを指定」

この場合、「S3証跡確認（CloudTrail）」の手順は不要になります。

Cloudtrailで証跡イベントが一定サイズを超えると
イベントがEventBridgeに渡らない仕様があるため、
こちらの方が処理漏れが少なくすむかもしれません。
AWS CloudTrail のクォータ

一度インシデントが発生したらInsident Managerで解決済みにする

インシデントが開いていると2回目以降発生時も
同じインシデントにまとまってしまうようで、
2回目以降、電話での通知が来なくなります。
Cloudtrailでイベント履歴 > イベント名：StartIncident で検索すると
数秒おきにStartIncidentが発生しており、
インシデントが開きっぱなしであることがわかります。

AWS Systems Manager　> Incident Manager から該当のインシデントを選択し
「インシデントを解決」ボタンをクリックしましょう。

この仕様は、システムの障害アラート通知対策に採用するには理にかなっていますが
（緊急対応中に何度も同様の原因でコールがくると焦りが増す😅）
今回のようなユースケースにはあまり適していないと思われます。

Route　53のデフォルトホストゾーンは削除してはいけない

盛大にやらかしてしばらくDNS名前解決ができなかったため
こちらについては別記事にまとめました。
Route 53で取得したドメインのホストゾーンを削除してしまったら

まとめ

今回は人気の防音物件空き情報をいち早くGETするという
プライベートの目的のために構築しましたが、
実業務においても気が付きにくいメールを
通知する方法として安価で実現できるので重宝しそうです。

システムの障害や閾値超えは、直接Slack等に通知するよう
構築することが多いと思いますが

まだシステム化されていないメールベースのユースケースには採用できそうです。

（例えば、重要なクライアントから営業チームへのメールを、
開発チームも早めにウォッチしたほうが良いパターンなど）

参考文献

今回参考にさせていただいた記事はこちらです。