1. はじめに
VMware Cloud on AWS環境とネイティブAWS VPCのIPアドレス帯(CIDR)が重複している場合でも、AWS PrivateLinkを活用すればアクセスできるというのを試せたので備忘録として残しておきます。
前回の記事ではアクセス先EC2のプライベートIPアドレスはAWSが自動採番したIPを利用しましたが、今回の記事ではプライベートIPアドレスも手動採番したIPを利用します。
またアクセス先EC2は前回の記事ではWeb Server(Apache)でしたが、今回の記事ではDB Server(MySQL)としています。
今回の構成 (実現できた構成)
今回の記事では簡単に結果だけご紹介します。詳細なセットアップは前回の記事をご参考ください。
セットアップ手順については前回記事との差分(EC2へのプライベートIP手動採番とNLBターゲットの設定)にフォーカスして記載します。
今回の記事ではEC2にプライベートIPアドレスを手動採番していますが、あくまでその要件が必須である場合にだけ実施します。
手動でプライベートIPアドレスを採番する場合はユーザー側でIPアドレスを管理する必要がありますが、中にはAWSがサービス側で予約しているなど利用できないプライベートIPアドレスも存在するなどの制約もあり、大規模構成になってくるとIPアドレス管理が煩雑化する可能性があります。
特別な要件がない限りはAWSが自動採番するプライベートIPアドレスを利用することを推奨します。詳細についてはAWS公式ドキュメントもご参照ください。
(参考) 前回の構成
2. まずは結果から
「VMC環境(192.168.0.0/20)」で稼働する「アクセス元Windows Server(192.168.15.10)」から、
「Connected VPC環境(10.0.0.0/16)」に存在する「VPC Endpoint Network Interface (10.0.3.57)」を経由して、
「アクセス先DB Server(192.168.15.251)」に対してTCP:3306(MySQL)へのアクセスができました。
文章だと長いので上図を参照ください。
アクセス確認にはMySQL Workbenchを利用しています。
SELECT文も実行できています。（成功！）
3. セットアップしてみる (概要)
前回の記事との差分にフォーカスして簡単に紹介します。詳細なセットアップ手順は前回の記事をご参考ください。
「アクセス先DB Server(192.168.15.251)」へのプライベートIP手動採番
Amazon EC2の通常作成の際に、「高度なネットワーク設定」のオプションからプライマリIP(192.168.15.251)を手動で設定します。
今回インスタンスはt2.microを選択しています。
インスタンス作成完了すると、プライベートIPは手動で設定したとおり「192.168.1.251」となっていることが確認できます。
手動で設定したプライベートIPは、インスタンス再起動しても変更されません。
(再掲・注意事項) 前述のとおりEC2にプライベートIPアドレスを手動採番することには注意点があります。
ちなみにMySQL自体は手組みでインストールして、「world database」という無償公開されているMySQL公式サンプルデータを利用しています。
Network Load Balancer(NLB)とAWS Private Linkのセットアップ
手順は前回とほぼ同じですが、NLBターゲットの指定が「インスタンス」ではなく「IPアドレス」となる点に着目ください。
Network Load Balancer(NLB)のセットアップ
まずElastic Load Balancer (ELB)サービスからNLBを選択し、「作成」を進めます。
インターネットには公開しないので、スキームは「内部」を選択します。
ロードバランサーのプロトコルは今回はMySQL Workbenchでアクセス確認したいので、TCP:3306(MySQL)を選択しています。
ロードバランサーは、「DB Server's VPC環境(192.168.0.0/20)」に作成します。
セキュリティ設定の構成はデフォルトのままで作成を進めます。
ターゲットの種類は「IP」を選択し、TCP:3306(MySQL)を選択しています。
ターゲットには、「アクセス先DB Server(192.168.15.251)」のプライベートIPアドレス「192.168.15.251」を選択します。
最後に設定内容を確認し、NLBを作成します。
「アクセス先DB Server(192.168.15.251)」へのセキリュティグループ設定
順番が前後しますがここで再度、NLBの挙動について確認します。
ターゲットの種類が「インスタンス」「IPアドレス」によってNLBの挙動が次のように異なります。
(AWS公式ドキュメントから抜粋) ターゲットグループを作成するときは、そのターゲットの種類を指定します。ターゲットの種類は、ターゲットの登録方法を決定します。たとえば、インスタンス ID、IP アドレス、または Application Load Balancer を登録できます。ターゲットをインスタンス ID で登録すると、クライアントの送信元 IP アドレスが保持され、アプリケーションに提供されます。ターゲットを IP アドレスで登録する場合、送信元 IP アドレスはロードーバランサノードのプライベート IP アドレスとなります｡ ターゲットを Application Load Balancer として登録すると、クライアントの送信元 IP アドレスが保持され、アプリケーションに提供されます。詳細については、「クライアント IP の保存」を参照してください。
今回はターゲットを「(DB Serverの)IPアドレス」で登録しています。そのため、送信元 IP アドレスはロードーバランサノードのプライベート IP アドレスとなります｡
(前回の記事ではターゲットを「(Web Serverの」インスタンス)で登録)
「アクセス先DB Server(192.168.15.251)」のセキュリティグループでは、「192.168.0.0/20」からのTCP:3306(MySQL)アクセスを許可させます。
今回の環境では「VMC環境(192.168.0.0/20)」と「DB Server's VPC環境(192.168.0.0/20)」のCIDRが重複しているためわかりにくいですが、
このセキュリティグループはNLBのプライベートIPアドレスが存在する「DB Server's VPC環境(192.168.0.0/20)」からのアクセスを許可するためです。
(CIDR指定ではなくセキュリティグループでアクセス許可できそうな気もしますが、今回構成するNLBはどこのセキュリティグループにも所属していないことにご留意ください。)
(念のため検証) 実際に再度192.168.0.0/20 (TCP:3306)からのアクセスを許可するインバウンドルールを削除した際には、「アクセス元Windows Server(192.168.15.10)」から「アクセス先DB Server(192.168.15.251)」へのMySQLアクセスもできなくなっています。
AWS Private Linkのセットアップ確認
手順は前回の記事と同じであるため省略し、セットアップ結果だけ確認します。
まず「VPC Endpoint Network Interface」のIPアドレスは「10.0.3.57」であると確認できます。
ここまででセットアップの全体構成は確認できました。詳細なセットアップ手順は前回の記事も合わせてご参考ください。
4. さいごに
AWS PrivateLinkを利用したVMware Cloud on AWSからIPアドレス重複している別VPC環境への接続について、前回と今回の記事の２本立てで確認してみました。
いずれも汎用的な活用シーンはなさそうなのですが、どうしても「CIDR重複環境同士で接続させたい」あるいは「オンプレミス環境のIPアドレスをVMC環境ネイティブAWS環境の両方で維持したい」というような場合に、このような構成もワークアラウンドとして実現できるかもしれないと思い出していただければ幸いです。
5. 参考記事