概要
このページでは、AWSにおける以下の確認内容を記載します。
①NLB-ALB多段構成を行うことで静的なIPアドレスで、ALBが利用できること（基本的なバランシングが出来ていること）。
②さらに、NLB-ALB多段構成にて、本来ALBがもつパスベースルーティング（パスバランシング）機能が利用できること。
はじめに
オンプレ設備からDirectConnect（以下、DX）経由で、アドレス帯が異なるAWS上のELBと通信を行うことがあると思います。
そのAWS上で利用されるアドレス帯がオンプレ設備側で許容することが出来ない場合、
NAT（Network Address Translation）を利用することが多くオンプレ側にもアドレス消費を求められるアーキテクチャになると思います。
特にELBがALBを使う場合には、IPが静的にアドレスをアサインすることができないため
ある程度利用されるIPアドレスを想定したアドレスを確保しなくてはいけませんでした。
例）
これがIPアドレス管理も任されるオンプレNW屋さん泣かせのアーキテクチャで大変苦労されている方も多いと思います。
NW界隈がざわつくアップデート
そんな中、2021年9月27日にNW界隈をざわつかせるアップデートが。
（参考リンク）
https://aws.amazon.com/jp/about-aws/whats-new/2021/09/application-load-balancer-aws-privatelink-static-ip-addresses-network-load-balancer/
こんなことが期待できるかも
まさにIPアドレス管理を任されているオンプレNW屋さんからしたら素敵なアップデート
そこで「概要」にある通り２点について確認した内容を以下に記載します。
確認①NLB-ALB多段構成を行うことで静的なIPアドレスで、ALBが利用できること（基本的なバランシングが出来ていること）。
さすがにオンプレNW環境を公開するわけにはいかないので簡素に以下の環境を作ってみました。
（簡素なので、1AZです。しかもお外に。笑）
こちらがNLBの設定
そのNLBにALBが紐づけられています。
各EC2インスタンスにはApacheを忍ばせており、簡単なWebページにしてます。
ではCurlでアクセスしてみます。
（白抜きで分かりづらいですが）それぞれ同一ドメインとなりますが
それぞれ違うページ（違うEC2インスタンス）にアクセスされている（ロードバランシングされている）ことが出来ました。
★参考★
今回のNLB-ALBの作成工程を記載メモします。（私の備忘録です。笑）
１）EC2インスタンスを3台作成する。
２）ALBの振り分け先のTargetGroupを作り、１）を紐づける。
３）ALBを作成し、２）を紐づける。
４）NLBの振り分け先のTargetGroupを作り、３）を紐づける。
５）NLBを作成し、４）を紐づける。
確認②NLB-ALB多段構成にて、本来ALBがもつパスバランシング機能が利用できること。
次は、NLB-ALB多段構成とした場合におけるパスバランシング機能を確認しようと思います。
＜条件＞
条件１）*/index.html というパスに合致すれば、EC2の１号機、EC2の3号機
条件２）条件１）に合致しなければ、503を返却する。
確認①で使用したEC2インスタンスをそのまま利用しALBリスナー画面（TargetGroupとの紐づけ設定箇所）で条件定義します。
新たにNLBの設定
では条件１の確認のためCurlでアクセスしてみます。
では次に条件２の確認です。
きちんと条件通りパスベースルーティングができているようです。
★参考★
確認②の作成工程を記載メモします。（こちらも私の備忘録です。笑）
１）EC2インスタンスを3台作成する。
２）ALBの振り分け先のTargetGroupを作り、１）を紐づける。
３）ALBを作成し、２）を紐づける。★このタイミングで振り分けルールを策定する★
４）NLBの振り分け先のTargetGroupを作り、３）を紐づける。
５）NLBを作成し、４）を紐づける。
まとめ
・NLB-ALB多段構成はきちんと静的なIPアドレスで、ALBを利用することが確認できました。
・パスベースルーティングも効くことができたためNLB-ALB多段構成でもALBの機能がきちんと利用できることが確認できました。
ということで
AWS構築におけるNLB-ALB多段構成は、選択肢の一つに入れていいと思います！
どの組織もIPアドレス（特にipv4は！）貴重な資産かと思いますので、是非検討してみてくださいませ！