はじめに
きっかけ
突然ですが、賃貸物件を探すのって大変ですね。
転職を機に職場の近くに引越しをしたいと物件を探していますが
家賃の高騰に目を白黒させている数ヶ月
「この値段なら、以前から狙っていた楽器演奏可能、防音物件に住めるのでは」
と既に当初の目的から外れ始めています。
楽器演奏可能物件をはじめ、賃貸物件は
「最初に申し込みをした人の早い者勝ち」が基本で
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等に通知するよう
構築することが多いと思いますが
まだシステム化されていないメールベースのユースケースには採用できそうです。
（例えば、重要なクライアントから営業チームへのメールを、
開発チームも早めにウォッチしたほうが良いパターンなど）
参考文献
今回参考にさせていただいた記事はこちらです。