AWSを使って人気物件の空き情報メール受信を電話でお知らせ

## はじめに
### きっかけ
突然ですが、賃貸物件を探すのって大変ですね。

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

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

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

### 作るもの
前置きが長くなってしまいましたが

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

があれば良いのでは？

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

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

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

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

## 構成図
![mailapartment-aws..png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/f4aaa9c3-2843-b1ef-5871-0ba71ac52da8.png)


## 手順


#### メール受信用の独自ドメイン取得（Route53）
今回はRoute53を使用します。
ウィザードに従って任意のドメインを取得、連絡先情報を入力します。
（キャプチャは例です。実際にこのドメインは取得していません。）
![Screenshot at Dec 31 21-13-39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/6c518d85-25b8-05e4-4756-3d3d609a3401.png)

![Screenshot at Dec 31 21-13-59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/2249cae1-1015-638b-f758-664a9fe42554.png)

#### 独自ドメインのSES検証
SES > 検証済みID > IDの作成　から先程Route53で取得したドメインを指定
![Screenshot at Dec 31 21-39-38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/a5fae8fa-7772-e1d4-d5e8-77644415bb92.png)


数分するとドメイン認証が完了し、IDステータスが「検証済み」になります。
![Screenshot at Jan 03 12-55-03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/267fc4d0-3016-ef08-a7c9-5a9cd0fc11ed.png)

#### 独自ドメインのMXレコード作成
Route53 > ホストゾーン　より、取得したドメインのホストゾーンを選択　> レコードを作成
レコードタイプ　: MX – メールサーバーを指定します
レコード名　: サブドメインにしない場合は、空白
値　: 10 inbound-smtp.us-east-1.amazonaws.com
![Screenshot at Jan 03 13-22-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/fb1da0e1-870a-07a7-82c1-1ab202260e78.png)


#### メール受信設定（Amazon SES + S3）
SES > Eメール受信 > ルールセットの作成　からルールセットを作成
作成したルールセット > ルールの作成 > 受信者の条件で
任意の受信メールアドレス（先程Route53で取得したドメイン）を指定します。
![Screenshot at Dec 31 21-36-14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/e22079e5-b7e6-ba96-1261-d1e5d39e1466.png)

「アクションの追加」で「S3バケットに配信」を選択し、
メールが蓄積されるS3バケット名を指定します。
![Screenshot at Dec 31 21-46-27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/2d9b990a-1b3c-0eae-51dc-ed293bb7244b.png)


#### お使いのメーラーでメール転送設定
Gmailの場合は転送したい条件でメールフィルタを作成し、
先程設定した受信メールアドレスに転送設定します。
![Screenshot at Jan 03 12-59-03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/6b281299-074c-ac86-c824-1b0fe6ea08ca.png)

S3のバケットにGmailの転送設定確認メールが蓄積されることを確認し
転送設定確認メール内のURLにアクセスして転送設定を承認します。
![Screenshot at Jan 03 13-04-15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/88d3499e-2408-855a-987b-a78d49bb3f3b.png)

#### S3証跡確認（CloudTrail）
CloudTrailによる対象S3バケットのイベントログの記録を設定します。

CloudTrail > 証跡の作成
証跡を保存する任意のS3バケット、任意のAWS KMS エイリアスを指定します。
![screencapture-us-east-1-console-aws-amazon-cloudtrail-home-2024-01-03-14_43_54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/3525adfb-9682-1ce2-ab88-c293986d6b2f.png)

イベントログの記録を行う対象を指定します。
イベントタイプ : データイベント
データイベントソース : S3
ログセレクターテンプレート : カスタム
高度なイベントセレクター　: メールが蓄積されるS3バケットのARNを指定
![screencapture-us-east-1-console-aws-amazon-cloudtrail-home-2024-01-03-14_51_55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/a7145a51-63f3-2599-e982-5e96807d95d5.png)


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

https://dev.classmethod.jp/articles/getting-start-incidentmanager/

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

#### 対応プランの設定（Incident Manager）
AWS Systems Manager > Incident Manager >　対応プラン　>　対応プランを作成

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

![Screenshot at Jan 03 15-07-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/58312d9b-3fa8-db7a-a887-194fbe06537f.png)

#### 通知設定（EventBridge）
Amazon EventBridge > イベントブリッジルール　>　ルールを作成

![Screenshot at Jan 03 15-26-23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/6cc59dc4-f862-56f6-7812-e37c0f489378.png)

![screencapture-us-east-1-console-aws-amazon-events-home-2024-01-03-15_29_07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/17251226-375d-a92f-9dd0-80dec54225d5.png)

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

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

```

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

ターゲットを選択 : Insident Manager レスポンスプラン
レスポンスプラン : 先程作成した対応プラン
![screencapture-us-east-1-console-aws-amazon-events-home-2024-01-03-16_17_53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/d4b2f888-6c60-d66e-a733-26b8055dd179.png)




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


## 補足・つまづきポイント

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

メールが蓄積されるS3バケットでEventBridgeへの通知許可をします
![Screenshot at Jan 21 11-29-23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/a509b1f0-65e2-debe-18e4-dbb790357901.png)

通知設定（EventBridge）を下記設定にします
イベントソース : AWS イベントまたは EventBridge パートナーイベント
サンプルイベント : 入力しない
作成のメソッド : パターンフォームを使用する
イベントソース :　AWSのサービス
AWSのサービス :　S3
イベントタイプ :　Amazon S3 イベント通知
イベントタイプの仕様１ :　特定のイベント「Object　Created」
イベントタイプの仕様２ :　特定のバケット（名前別）「メールが蓄積されるS3バケットのARNを指定」
![screencapture-us-east-1-console-aws-amazon-events-home-2024-01-21-13_52_31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/d060cec0-786d-49cd-0c7c-f469a42dd15b.png)

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

Cloudtrailで証跡イベントが一定サイズを超えると
イベントがEventBridgeに渡らない仕様があるため、
こちらの方が処理漏れが少なくすむかもしれません。
[AWS CloudTrail のクォータ](https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/WhatIsCloudTrail-Limits.html)

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

![Screenshot at Jan 21 14-09-52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/13844f43-13da-224d-630e-dcdd2062b938.png)

![Screenshot at Jan 21 13-45-18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/f760a44e-5eb1-0fe9-1e6c-ea0ff48ec320.png)


AWS Systems Manager　> Incident Manager から該当のインシデントを選択し
「インシデントを解決」ボタンをクリックしましょう。
![Screenshot at Jan 21 13-48-20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/f1476435-14ac-e005-0cc8-2bba1aa11f4e.png)

![Screenshot at Jan 21 13-48-46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3635225/4e021133-8956-703f-2c91-8c58690e96ad.png)


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


#### Route　53のデフォルトホストゾーンは削除してはいけない
盛大にやらかしてしばらくDNS名前解決ができなかったため
こちらについては別記事にまとめました。
[Route 53で取得したドメインのホストゾーンを削除してしまったら](https://qiita.com/tutti618/items/44d4718b842b74ea34b2)

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

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

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

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

## 参考文献
今回参考にさせていただいた記事はこちらです。
- [メール受信をトリガーに電話通知をする対応をSSM Incident Managerを使って対応してみた](https://dev.classmethod.jp/articles/ses-incident-manager/)
- [【AWS】SESとS3でサーバレスなメールの送受信環境を構築する](https://www.isoroot.jp/blog/6229/)
- [SESメール送信 S3で受信テスト](https://qiita.com/ezaqiita/items/e5a16a85f1f129faa314)
- [アップロードするS3オブジェクトが大きいとEventBridgeが発火しない?](https://qiita.com/NaotoFushimi/items/cb78ca79575cf42b4dfe)
- [S3イベント通知 vs EventBridge 処理漏れ率を比べてみた](https://dev.classmethod.jp/articles/s3-event-notification-vs-eventbridge-event-processing-overflow-rate/)
- [EventBridgeを介してDatadogとIncident Managerを連携させてみる](https://shepherdmaster.hateblo.jp/entry/2021/12/18/134811)