概要
下記の続きとなります。
追記
現在は、AWSより本ロジックを作成しなくても、対応できるようにマネージドプレフィックスリストが追加されております。
https://aws.amazon.com/jp/about-aws/whats-new/2022/02/amazon-cloudfront-managed-prefix-list/
過信(2022/2/8)
そもそも、NLBがどのIPでヘルスチェックしているかを俺は理解していなかった。
ヘルスチェックをするIPはCloudFrontのIPアドレスではなくNLBの所属するVPC内で払いだされたIPアドレス。
NLBの先のインスタンスではCFのIPアドレスとVPCのCIDR(AWS公式はVPCのCIDRを登録するのが推奨っぽい)をセキュリティグループで許可してあげなければいけない。
ターゲットセキュリティグループ
罠
上記の設定をしたのち、ヘルスチェックも通りアプリアクセスも正常にいけた。
しかし、主題であるアクセスをCloudFrontからのみに制限するということが実現できておらずNLB直でもアクセスできてしまうことが発覚しました。
アプリアクセス的にはCloudFrontのIPしか許可していないのにNLB直が何故かイケてしまう状況。。
構成図的には下記のような状態だった。
設定値を眺めているとNLBのターゲットグループでクライアント IP の保存というのがあり、
これが無効になっていたのが原因だった。
クライアント IP の保存
クライアントIPを保持していると信じていたのにそうではなくNLBのIPアドレスでアクセスしていたので
ヘルスチェック用のSGで通ってしまっていた状態だった。
終わりに
どういった違いで設定が変わるかを覚えておくことが重要な気がします。
インスタンス ID でターゲットを指定する場合
→すべての受信トラフィックのクライアント IP が保持される。
IP アドレスでターゲットを指定する場合
→ターゲットグループプロトコルが TCP または TLS の場合、クライアント IP 保存はデフォルトで無効です。
→ターゲットグループプロトコルが UDP および TCP_UDP の場合、クライアント IP 保存はデフォルトで有効です。
今回の場合、IPアドレスでターゲットを指定しており、ターゲットプロトコルがTCPであった為、
IP アドレスでターゲットを指定する場合の1つ目に該当していたようです。