目次
はじめに
昨年、NLBのTarget GroupにALBを指定することができるようになりました。NLBを前段に置くことでなにが嬉しいかというと、やはりNLBは固定IPを付与できるという点、で固定IPが付与できるということは例えばDirectConnect(DX)を経由したオンプレミスとAWS間の通信において、NAT変換している際に有効になってきたりします。ALBでももちろんENIのIPを特定しそのIPでNAT変換、ということはできますが、ALBのIPは変動する可能性があるためその都度NATの定義を変えるなんて現実的ではありません。DXを経由したオンプレミスとAWS間通信においてNAT変換されているケースを想定し、NLBを追加することで解決するシュチュエーションについて検証してみました。
シチュエーション
下記のようなケースを考えてみます。
- DirectConnect(DX)でオンプレミスとAWS間が接続されている。
- VPC内にはPrivateなWebサイトがALB+EC2で構築されており、VPC内およびオンプレミス(拠点Aとする)からhttpsでアクセスされている。
- TLSの終端はALBとなっている。
- VPC内もオンプレミス側も、Route 53 Private Hosted Zoneの名前解決ができる構成になっている。(ALBの名前はALIASで登録されている。またRoute 53 Resolver、Inbound Endpointの表記は割愛。)
- 今回、新たにNAT変換が必要な拠点BとDXで接続することになり、さらにはその拠点からPrivateなWebサイトへhttpsでアクセスする必要がある。
NAT変換が必要な拠点BからVPC内のPrivateなWebサイトへhttpsアクセスが必要ということで、今のままでは拠点BからALBにアクセスすることはできません。もちろん、各拠点からALBの名前は解決できる前提なのですが、ALBの名前を引くとNAT変換されていない、VPC内のIPが返ってきます。拠点BからするとVPC内のIPの情報はもっていないのでルーティングできずALBに到達することができません。そこで、固定IP化したNLBを前段に置いて、固定IPをNAT変換後のIPとマッチング(これは拠点側NW機器の設定)、Route 53にはNLBの名前として、NAT変換後のIPを返すAレコードを登録してあげます。
上図の通り、NLB(nlb.example.com)はRoute 53がNAT変換後のIPを返してくれるため、拠点BからNLB(nlb.example.com)はアクセス可能、かつその先のALB-EC2(Web)までアクセスし、PrivateなWebサイトが閲覧可能となります。
検証
机上では問題なさそうなのですが、今回新たに追加となった機能NLB→ALBにおいて、httpsアクセスが正しく行えるのか？という点については実環境で検証してみようと思います。NATの構成までは準備できなかったので、今回はNLB→ALBのhttpsアクセス可否に絞って検証してみます。
構成
VPC内のEC2から、ALB経由、NLB経由のhttpsアクセスを試行し、共に同じWebサイト(Private websiteというページ)が表示されることを確認してみます。尚、NLB、ALBに適用する証明書はACMで既に有効になっているものを利用します。
※その他、VPCからインターネットへのアクセスやVPC Endpoint等、本検証に直接関係のない機能は表記を割愛しています。
ALBへのアクセス
まずは、ClientのEC2(Windows)からALBに対してアクセスしてみます。登録されているALIASレコードの結果も合わせて確認してみます。
ClientのブラウザからALB(https://alb.example.com)へアクセスしたところ、正しくPrivate websiteというページが表示されました。ALIASのレコードでも正しくPrivate SubnetのIPが返ってきています。ALBには特段問題なくhttpsアクセスができました。
NLBへのアクセス
続いて、NLBを経由してALBの先にあるPrivate websiteが表示できることを確認します。ここからは機能の検証も兼ねてAWSマネジメントコンソールでの手順も合わせて記載します。尚、手順は以下を参考にしました。
Application Load Balancers as targets
Target Groupの作成
Target GroupとしてALBを登録していきます。Target Groupの作成画面から、Application Load Balancerを選択します。
次に、Target group nameやHealth checkの設定を入れていきます。
今回はTargetとなるALBがHTTPSで待ち受けしているため、Targetのプロトコルは443、Health check protocolもHTTPSを指定しました。
最後に先程接続確認をしたALBをプルダウンから選択し、Targetに指定します。
以上でTarget Groupの作成は完了です。
NLBの作成、Target Groupとの紐付け
次はNLBを作成し、先程作成したTarget Groupと紐付けます。作成の途中で、構成に記載した固定IPを付与します。
ListenerではTCP/443、先程作成したTarget Groupをプルダウンから選択し、NLBを作成します。
NLBの作成が完了すると、TargetであるALBへのHealth checkが開始され、ステータスがhealthyとなりました。尚、NLBにはSecurity Groupをアタッチできないため、TargetであるALBのSecurity GroupではNLBのIPや所属するSubnetのCIDRで443/tcpを許可しておく必要があります。
NLB経由でのアクセス検証
NLB→ALBの構成が準備できたため、ClientのEC2からブラウザでアクセス検証をしてみます。Route 53にもNLBの固定IPを返すAレコードは登録済みのため、名前解決の結果も合わせて確認してみます。
名前は解決できている(172.16.1.10、172.16.2.10が返ってきている)のですが、サイトにアクセスできませんでした。応答時間が長すぎるとあるので、今一度NLBの設定、Security Group等確認をしたところ・・・先程自分で触れていた、NLBにはSecurity Groupをアタッチできない点から、ALBのSecurity Groupにて不備を発見しました。
元々、EC2(Client)からALBへのhttpsアクセス時は、EC2(Client)のSecurity Groupをインバウンドルールに登録することでアクセス可能としていました。しかし、NLB経由でアクセスする場合は、前述の通りNLBにSecurity Groupをアタッチできないため、TargetであるALBのSecurity GroupでEC2(Client)のIPや所属するSubnetのCIDRで443/tcpを許可しておく必要があります。
ということで、EC2(Client)の所属するSubnetのCIDRをインバウンドルールに追加しました。
改めて、NLB経由で接続確認をしてみます。
想定通り、NLB経由でもPrivate websiteと表示させることができました！
以上で、NLB→ALB経由でもhttpsアクセスが可能であることの確認ができました。
おわりに
ALBをTargetに指定できるようになり、L7レイヤーの機能をALBで実装しつつ、NLBにて固定IPを実装する等、より様々なケースに対応できるアーキテクチャが組めるようになりました。ちなみに今回想定したシチュエーションですと、NLBのTargetを直接EC2にすることも可能です。ただ、例えばELB-EC2間でセッション維持が必要な場合、NLBはTLSリスナーだとセッション維持に対応していないので、そういったシチュエーションでも今回の構成は有効になってきます。httpsアクセスが可能なことも確認できましたので、PrivateなNW構成を検討する上での一助になれば幸いです。
この記事をシェアする
