EIP を割り当てた NLB と ALB を組み合わせて、固定 IP と AWS WAF を両立してみた

はじめに

こんにちは、ほりぐちです。

外部サービスや取引先から Web アプリケーションへ接続してもらう際に、「接続先の IP アドレスを固定し、接続元の allowlist に登録したい」という要件がある場合があります。

Application Load Balancer（ALB）は AWS WAF と関連付けられますが、インターネット向けの固定 IP アドレスを直接割り当てることはできません。

一方、Network Load Balancer（NLB）はサブネットごとに Elastic IP アドレス（EIP）を割り当てられるため、固定 IP アドレスを持つエンドポイントとして利用できます。ただし、NLB に AWS WAF を直接関連付けることはできません。

そこで今回は、次の役割分担で構成します。

• NLB：固定 IP アドレスを持つインターネット向けのエンドポイント
• ALB：HTTP リクエストの処理と AWS WAF による検査
• EC2：Web アプリケーションを実行するバックエンド

最終的な通信経路は、次のようになります。

クライアント → EIP を割り当てた NLB → ALB → EC2

この記事では、EIP をアタッチした EC2 への直接アクセスから開始し、ALB、NLB の順に追加しながら、それぞれの段階で疎通を確認します。

固定 IP アドレスで Web アプリケーションを公開しつつ、AWS WAF も利用したい方に向けた検証記事です。

今回の構成

今回は 2 段階に分けて検証をします。
最初に、EIP を直接 EC2 に割り当て、クライアントから EC2 上の nginx へ直接アクセスできることを確認します。

次に、EC2 から EIP の関連付けを解除し、その EIP を NLB に割り当て、ALB を経由してアクセスします。

NLB は固定 IP アドレスを提供し、ALB は AWS WAF による HTTP／HTTPS リクエストの検査を担当します。

EC2 を NLB から直接参照するのではなく ALB を挟むことで、固定 IP アドレスを維持しながら、AWS WAF やパスベースルーティングなどの ALB の機能を利用できます。

それでは実際にやっていきましょう。

1. 疎通先の EC2 インスタンスを作成する

まずは、EIP 単体で外部から EC2 に到達できることを確認します。そのために、バックエンドとなる EC2 を作成します。

この EC2 には、HTTP リクエストが正常に到達することを確認するため、Web サーバーとして nginx をインストールします。

この段階では、EC2 に直接端末からアクセスするためにセキュリティグループには次のインバウンドルールを設定します。

• プロトコル：TCP
• ポート：80
• ソース：マイ IP

今回の検証ではこちらの EC2 を利用して疎通の確認を行います。

2. EC2 に EIP を割り当てて疎通確認する

それでは先ほど作成した EC2 インスタンスに EIP を割り当て、直接接続ができるかを試してみます。

EC2、もしくは VPC のコンソール左のメニューから Elastic IP を選択し、右上オレンジの「Elastic IP アドレスを割り振る」ボタンをクリックします。

今回は us-east-1 に IPv4 の EIP を割り振ります。

無事 EIP を確保できました。

次に、こちらを先ほど作成した EC2 インスタンスに紐付けます。

これで作成した EC2 に EIP をアタッチすることができました。
それでは早速 EC2 に紐付けた EIP を直接指定してアクセスできるかを試してみましょう。

こちらのパブリック IPv4 アドレスに先ほど割り当てた EIP が書かれているので、コピーしてアドレスバーに IP を指定してアクセスします。

http://<EIP>

無事 nginx のトップページが表示されました。
これによって次の点を確認できました。

• EIP から EC2 へ到達できる
• EC2 のセキュリティグループが正しく設定されている
• nginx が TCP 80 番ポートで動作している

今回は EC2 にインストールした nginx のトップページが表示されたことをもって疎通したとします。

3. ALB を作成し、EC2 への疎通を確認する

それでは、次に EC2 の手前に ALB を作成していきます。

この ALB は NLB から受け取ったリクエストを EC2 へ転送するとともに、AWS WAF を関連付けるために使用します。
必須の工程ではありませんが、ALB 作成時点で ALB -> EC2 の通信が通るかも確かめてみます。

この時、ALB に WAF をアタッチすることが可能です。
例えば、次のような制御が可能です。

• 特定の送信元 IP アドレスの許可またはブロック
• SQL インジェクションに該当するリクエストの検出
• クロスサイトスクリプティングに該当するリクエストの検出
• 一定時間内に大量のリクエストを送信したクライアントの制限
• AWS マネージドルールによる一般的な攻撃パターンへの対策

今回は検証のためアタッチできることを確認するに留めます。

今回は ALB にアクセスして EC2 への疎通を確かめるため、マイ IP を受け入れるように ALB セキュリティグループのインバウンドルールを設定します。これによって、端末から ALB の DNS 名にアクセスすることが可能になります。

また、先ほどまでマイ IP を受け入れる設定にしていた EC2 のインバウンドルールを変更し、ALB のセキュリティグループからの通信を受け入れるように設定します。これによって、ALB 経由のアクセスのみを許可します。

それでは ALB の DNS 名でアクセスしてみましょう。

無事できました。これで WAF をアタッチできる ALB を経由して EC2 へアクセスすることを強制できます。
しかし、ALB へのアクセスは DNS 名を指定したもので、EIP をターゲットとした固定 IP でのアクセスではありません。元々の要件はターゲット IP を固定して、安全にアクセスすることでした。

それでは最後に、こちらに NLB を追加して EIP をターゲットとしたアクセスを実現していきます。

4. EIP を割り当てた NLB 経由で疎通確認する

EC2 の EIP を関連付け解除して NLB に移し、EIP をターゲットとしてアクセスしたら NLB、ALB を経由して EC2 まで疎通することを確認しましょう。

まず EC2 の EIP の関連付けを解除します。

次に、NLB を作成していきます。
まずはセキュリティグループから。

NLB のセキュリティグループは マイ IP からのインバウンドを許可する設定にします。（裏で先ほど マイ IP を許可していた ALB のインバウンドルールを NLB からの通信だけを許可する設定に変更しておきます）

NLB のターゲットグループを作成します。
ターゲットの種類として Application Load Balancer を選択し、今まで利用していた ALB を指定します。

NLB を作成します。
先ほど作成した、ALB をターゲットとするターゲットグループを指定します。

NLB のサブネットマッピングをします。NLB と ALB で使用する AZ は、可能な限り一致させます。AWS でも、可用性、スケーリング、パフォーマンスを最適化するために、NLB と ALB で同じ AZ を有効化することを推奨しています。

なお、NLB には有効化した AZ ごとに 1 つの IP アドレスが割り当てられます。そのため、2 つの AZ で NLB を構成する場合は、基本的に 2 つの EIP を用意します。この時、EIP の一つに先ほど EC2 との関連付けを解除した EIP を指定します。

それでは改めて NLB にアタッチした EIP を指定してアクセスしてみます。

無事疎通が確認できました。

以上を持って、EC2 に関連づけられていた EIP を NLB に移し、間に ALB を挟んで WAF をアタッチ可能ということを確認することができました。

おつかれさまでした！

補足：本番環境では internal ALB とプライベートサブネットを検討する

今回の検証では、構成を段階的に確認するため、インターネット向け ALB を使用しました。インターネット向け ALB であれば、NLB を作成する前に ALB の DNS 名へブラウザから直接アクセスできます。そのため、ALB から EC2 までの通信に問題がないことを切り分けやすくなります。

一方、実際の運用ではクライアントから NLB を経由して ALB へアクセスするため、ALB 自体をインターネットへ公開する必要はありません。

NLB 経由でのみアクセスさせる場合は、internal ALB と EC2 をプライベートサブネットに配置することで、外部への公開範囲を必要最小限にできます。この構成は、インターネットから直接アクセスする必要のないリソースをプライベートサブネットに配置するという、AWS のベストプラクティスに沿っています。(WKLD.10 - AWS Prescriptive Guidance)

5. コストの違い

今回は固定 IP で接続する場合に ALB を挟むことで WAF をアタッチし、セキュリティを向上させる方法について紹介しました。

この場合コスト的にはどのくらいの違いが出るのでしょうか？

EC2 に EIP を直接割り当てる構成と、NLB、ALB、AWS WAF を組み合わせた構成では、発生する主な費用が次のように異なります。

EC2 の利用料金はどちらの構成でも発生します。一方、NLB、ALB、AWS WAF を組み合わせた構成では、2 種類のロードバランサーの稼働時間と使用量に応じた料金に加え、AWS WAF の利用料金が発生します。

AWS WAF の料金は、作成した Web ACL とルールの数、および Web ACL が処理したリクエスト数に応じて決まります。

そのため、EC2 に EIP を直接割り当てる構成よりもコストは増加しますが、固定 IP アドレスを維持しながら、ALB のレイヤー 7 の機能や AWS WAF によるリクエストの検査を利用できます。

おわりに

今回は、EIP を割り当てた NLB の背後に internal ALB を配置し、固定 IP アドレスと AWS WAF を両立する構成を検証しました。

最終的な通信経路は次のとおりです。

NLB に EIP を割り当てることで、アクセスターゲットとして固定 IP アドレスを用意できます。また、ALB に AWS WAF を関連付けることで、HTTP／HTTPS リクエストをルールに基づいて検査できます。

一方、NLB と ALB の両方を使用するため、EC2 に EIP を直接割り当てる構成と比べて、コストと構成の複雑さは増加します。

採用する際は、固定 IP アドレスが本当に必要か、WAF が必要か、複数 AZ による可用性が必要かを整理したうえで、要件に合う構成を選択してください。