前提

Route53（ACM）→ CloudFront → ALB → EC2
というシンプルな構成

以下のようなリクエストによる500エラーが多すぎて監視工数が増えているため「これ通してるの普通にやばいですよね？」という話をした結果、自分がセキュリティ対策を検討することになった。

https://my-alb-123456789.ap-northeast-1.elb.amazonaws.com/~
https://13.113.203.1/~

記述内容

ALBのエンドポイントやIPなどを直接たたいてくるアクセスを防ぐ上で検討した内容一覧を書いていく。
間違っていることがあれば教えてほしい。
対処法一覧は以下。

1. ALB側にWAFを設置する

ALB側にWAFを入れた場合、ALBに対して様々なドメインが入り乱れてロードバランシングしているならば、各ドメイン対して状況に応じたセキュリティ対策やルーティングなどができなくなる可能性がある。

デメリット

可用性が低い。
基本的にはCloudFront側でWAFを入れて、ALBにはWAFを入れないのがスマートな対応になると考えている（後でどうせ「○○のドメインには○○のカスタマイズしたいんだよね」とか言われるとALBでまとめて対応していた内容を変更せざるを得なくなる）。

メリット

逆に、ALBにだけWAFを入れれば各CFに対してWAFを入れなくていいので、コストはかなり抑えられる。

2. ALBのリスナールールで振り分け

単純に正規ドメインでなかった場合に503で返すようなルールを設ける。

メリット

メリットとして単純かつ明快な対応であるから早い。
デメリットとして、CloudFrontからきていることを担保できないので、CloudFrontのデバッグ（CDNを使用しているという担保を得る運用）ができなくなる。

デメリット

個人的にはCDNを運用として確実に回すなら、下記の対応をするべき。

3.
CFにリクエストヘッダーを付与する＆(ALBのALBのターゲットグループ（EC2側）のSecurity GroupでCloudFrontからのアクセスのみ許可orALBのリスナールールで振り分ける)

CloudFrontに対してリクエストヘッダーを付与して、ALBのリスナールールなどで処理する方法。

メリット

ALBのリスナールールで「CFから送られてきたリクエストヘッダーがないならターゲットグループ（サーバー）へ通さない」という振り分け（503で返すなど）をすれば、確実にCF側からリクエストをきたことを担保できて正規のドメインからのアクセスであるのを確保しやすい。
個人的にはこの方法が最もスマートである気がする。
albに対して直接来てもリスナールールで振り分けられる。

デメリット

とにかく運用に乗らすためにはCloudFrontに対して逐一リクエストヘッダーを付与する必要がある。

まとめ

可用性を重視するなら、セキュリティ対策やドメインの制御はCloudFront側で実施し、ALBはあくまで補助として用いる。ただし、運用工数とコストが増える。
運用工数やコストを減らしたいならALB側でセキュリティやドメインも一元管理。CloudFrontなどはあくまでCDNとしての役割のみを持たせるただし、可用性が低いので急な仕様変更や要望に弱い。