概要

・CloudFrontの後段にELBがいるような構成になっていてCloudFrontではAWS WAFでDDos等防いでいるが、
　ELB及びEC2へは直接アクセスできてしまうのでブロックしたいパターン。

・ALBであればカスタムヘッダ/WAFで制御することも可能だが、今回はNLBということで後段のSGインバウンドを動的に対応させることに。

公式ブログを参考にしていくことに。　
https://aws.amazon.com/jp/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/

※大まかな手順等は上記公式ブログに記載の為今回は省きます。

追記(2022/2/8)

現在は、AWSより本ロジックを作成しなくても、対応できるようにマネージドプレフィックスリストが追加されております。
https://aws.amazon.com/jp/about-aws/whats-new/2022/02/amazon-cloudfront-managed-prefix-list/

構成

構成の流れとしては以下

①初回は公式ブログにあるテストをし、現在のIP RangeからLambdaの中でCloudFrontのGLOBAL/REGIONALのIPを抽出しSGに反映する。
②それ以降は、IP Rangeが更新されるたびに公式から公開されているSNSをトリガーにLambdaが動作してSGを更新してくれる。

問題①

公式ブログで参照先になっているPythonコードを試したところ、このissueに挙がってる問題に直面し上手くいかなかったので上記エラーを解決しているものを使用することにしました。

問題②

セキュリティグループのルール数に上限(デフォルト50)があり、GLOBALのIPを追加するセキュリティグループのルールが上限を超えてしまう問題があります。
セキュリティグループのNameタグで対象を選択しているので同じNameタグのセキュリティグループの数を増やすorセキュリティグループのルール数の上限緩和をする必要があります。
セキュリティグループのルール数の上限緩和も制約があるので申請する場合は確認したほうが良いと思います。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/increase-security-group-rule-limit/

注意点

当たり前だろ、と思われるかと思いますが構築中にあるLambdaのトリガー設定をするCLIはSNSがあるリージョンで実行しなければならないのでexport AWS_DEFAULT_REGION=us-east-1等してから実行しないと上手くいきません。

今回自分はTerraformで構築したのですが、その際にもalias等使用してトリガーの設定をしないと上手くいかないと公式にも書いてあるので要注意です。
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sns_topic_subscription

続編