NLBのTargetにALBを指定しhttpsアクセスさせる

この記事を書いたメンバー:

Takashi Kayukawa

NLBのTargetにALBを指定しhttpsアクセスさせる

目次

はじめに

昨年、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構成を検討する上での一助になれば幸いです。


カテゴリー
タグ

この記事を書いたメンバー

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関して
お気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)