1. はじめに
VMware Cloud on AWS環境とネイティブAWS VPCのIPアドレス帯(CIDR)が重複している場合でも、AWS PrivateLinkを活用すればアクセスできるということ試せたので備忘録として残しておきます。
今回セットアップ試してみた構成
今回は基本的なHTTP(TCP:80)アクセスだけで試していますが、NLBが待受けやターゲットのTCPポートを変更することでほかの構成にも応用が効くかもしれません。
本手順では、アクセス先Web ServerのIPアドレス(192.168.15.241)は「AWSが自動的に採番したプライベートIP(=私が手動で採番していないIP)」を利用しています。
アクセス先のEC2のプライベートIPアドレスを手動で採番する場合、NLBの設定および挙動が若干異なりますので次の記事もあわせてご参考ください。
2. AWS PrivateLink is 何？
データをインターネットに公開することなく、VPC と AWS のサービス間の接続を確立する
上記はAWS公式サイトのサービス概要ですが、今回はさらにVMware Cloud on AWS, Conntected VPC, ELB(NLB)などいくつかの条件や要素を組み合わせることで、上図のようにIPアドレス帯が重複するVMware Cloud on AWS環境からVPCへのアクセスを実現しています。
3. セットアップしてみる
登場人物の確認
次の３つの異なる環境をまたがる構成となっており、登場人物は次のとおりです。
アクセス元であるVMware Cloud on AWS環境(「VMC環境(192.168.0.0/20)」)
- 「アクセス元Windows Server(192.168.15.10)」
VMware Cloud on AWSのConnected VPC(「Connected VPC環境(10.0.0.0/16)」)
- 「VPC Endpoint Network Interface (10.0.3.181)」
アクセス先であるWeb Serverが稼働するVPC(「Web Server's VPC環境(192.168.0.0/20)」)
- 「アクセス先Web Server(192.168.15.241)」
- 「踏み台サーバー(192.168.11.40)」
初期セットアップの確認
「Web Server's VPC環境(192.168.0.0/20)」の確認
まず「踏み台サーバー(192.168.11.40)」から「アクセス先Web Server(192.168.15.241)」にHTTPアクセスし、Webページが表示されることを確認します。
「アクセス先Web Server(192.168.15.241)」のEC2インスタンス情報は次のとおりです。
(再掲) 本手順では、アクセス先Web ServerのIPアドレス(192.168.15.241)は「AWSが自動的に採番したプライベートIP(=私が手動で採番していないIP)」を利用しています。アクセス先のEC2のプライベートIPアドレスを手動で採番する場合、NLBの設定および挙動が若干異なりますので次の記事もあわせてご参考ください。
参考までに、「Web Server's VPC環境(192.168.0.0/20)」のサブネット情報は次のとおりです。
「VMC環境(192.168.0.0/20)」)の確認
「VMC環境(192.168.0.0/20)」で稼働している「アクセス元Windows Server(192.168.15.10)」が、
現時点では「Web Server's VPC環境(192.168.0.0/20)」で稼働する「アクセス先Web Server(192.168.15.241)」にHTTPアクセスできていないことが確認できます。
「VMC環境(192.168.0.0/20)」で作成したサブネットを確認します。
デプロイ時に選択した「Connected VPC環境(10.0.0.0/16)」を確認します。
「VMC環境(192.168.0.0/20)」から「Connected VPC環境(10.0.0.0/16)」に向けてHTTP (TCP:80)のアクセスが許可されていることを確認します。
今回許可しているのはアウトバウンド通信だけであることにも着目ください。
「Connected VPC環境(10.0.0.0/16)」の確認
ルートテーブルは次のとおりです。
「VMC環境(192.168.0.0/20)」のコンピュートゲートウェイ配下のサブネット(192.168.0.0/20)へのルートが書き込まれています。
(また今回のブログ内容と関係ありませんが、マネジメントゲートウェイ配下のサブネット(172.16.0.0/16)へのルートも書き込まれています。)
Network Load Balancer(NLB)のセットアップ
初期セットアップが確認できたので、「アクセス先Web Server(192.168.15.241)」をターゲットとするNLBを構築していきます。
まずElastic Load Balancer (ELB)サービスからNLBを選択し、「作成」を進めます。
インターネットには公開しないので、スキームは「内部」を選択します。
ロードバランサーのプロトコルは今回はブラウザ経由でアクセス確認したいので、TCP:80(HTTP)を選択しています。
ロードバランサーは、「Web Server's VPC環境(192.168.0.0/20)」に作成します。
セキュリティ設定の構成はデフォルトのままで作成を進めます。
ターゲットの種類は「インスタンス」を選択し、TCP:80(HTTP)を選択しています。
ターゲットの種類が「インスタンス」「IPアドレス」によってNLBの挙動が異なりますので、ご注意ください。
(AWS公式ドキュメントから抜粋) ターゲットグループを作成するときは、そのターゲットの種類を指定します。ターゲットの種類は、ターゲットの登録方法を決定します。たとえば、インスタンス ID、IP アドレス、または Application Load Balancer を登録できます。ターゲットをインスタンス ID で登録すると、クライアントの送信元 IP アドレスが保持され、アプリケーションに提供されます。ターゲットを IP アドレスで登録する場合、送信元 IP アドレスはロードーバランサノードのプライベート IP アドレスとなります｡ ターゲットを Application Load Balancer として登録すると、クライアントの送信元 IP アドレスが保持され、アプリケーションに提供されます。詳細については、「クライアント IP の保存」を参照してください。
ターゲットには、「アクセス先Web Server(192.168.15.241)」を選択します。
最後に設定内容を確認し、NLBを作成します。
AWS PrivateLinkのセットアップ
今回のメインパートであるAWS PrivateLinkのセットアップをしていきます。
エンドポイントサービスの作成
前ステップで作成したNLBを、エンドポイントサービスとして設定していきます。
インターネット上では公開しないものの、念のため「エンドポイントの承認が必要」を選択しておきます。
エンドポイントサービスが作成されたら、「サービス名」を後続ステップのためにメモしておきます。
エンドポイント(「VPC Endpoint Network Interface (10.0.3.181)」)の作成
前ステップで作成したエンドポイントサービスを指定し、エンドポイント(「VPC Endpoint Network Interface (10.0.3.181)」)を「Connected VPC環境(10.0.0.0/16)に作成します。
セキュリティグループは事前に作成したものを指定しており、「アクセス元Windows Server(192.168.15.10)」からの通信を許可しています。
このタイミングでいったん作成したエンドポイントサービスに戻り、「エンドポイント接続リクエストの承諾」を選択しておきます。
エンドポイント(「VPC Endpoint Network Interface (10.0.3.181)」)が作成されたら、IPアドレス(10.0.3.181)を確認します。
作成したエンドポイント(「VPC Endpoint Network Interface (10.0.3.181)」)のセキュリティグループが、「VMC環境(192.168.0.0/20)」で稼働する「アクセス元Windows Server(192.168.15.10)」からのアクセスを許可していることも念のため再度確認しておきます。
(今回の構成で必要なのは最低限TCP:80(HTTP)でのインバウンドアクセスとなります。)
(成功！) IPアドレス帯が重複している環境へのアクセス確認
「アクセス元Windows Server(192.168.15.10)」が「VPC Endpoint Network Interface (10.0.3.181)」を経由して、「アクセス先Web Server(192.168.15.241)」にHTTP(TCP:80)アクセスできたことが確認できました。
4. さいごに
AWS PrivateLinkを利用したVMware Cloud on AWSからIPアドレス重複している別VPC環境への接続を試してみました。
今回は基本的なHTTP(TCP:80)アクセスだけでしたが、NLBが待受けやターゲットのTCPポートを変更することでほかの構成にも応用が効くかもしれませんのでご参考いただければ幸いです。
5. 参考にさせていただいた文献
今回のセットアップではいつも以上に色々な文献を参考にさせていただきました。（いつも有益な情報ありがとうございます！）
おそらく日本語で同じようなユースケースを調べる場合は下記ページに行き着くと思うので、備忘録としてまとめておきます。
6. 参考記事