Multi-VPC ENI Attachmentsの使い道をVMware Cloud on AWSの目線で考えてみる。

はじめに・・・

数日前に、AWSのアップデートがリリースされました。
それがこちら

端的に言えばEC2の2個目や3個目のNICを、別のVPCに接続ができますということです。
もともと、同じVPC内で別のSubnet（同一AZ内）だと接続できていたのが、別のVPC（ただし同じアカウントID内）できるようになったということになります。

このアップデート、オンプレ世代のエンジニア視点からみると、サーバの別のNICが別のNWに接続できるぐらいのノリなので特に驚きはなく、むしろVMware Cloud on AWSのENIでつながっている特殊なVPCだと、別のVPCとつなぐのに、VTGW（VMwareがManagedするTransit Gateway）を経由する必要があったので、SDDC側からこの2個目のNICが見えれば実はすごく使えるのでは？と思ったぐらいです。

せっかくなので、使い道も含めてやってみましょうというのが本投稿になります。
前置きが長くなりました・・・・。

この記事の技術的な内容はエンジニアへの情報提供のみを目的としております。
本番環境などで活用を検討する場合はしっかりとフィジビリティーを検討されることを推奨します。

早速やってみた

早速動かしてみました。構成はこちらです。

やってみたの趣旨はネットワークアプライアンスのENIでVPC間をつなぐと、跨いで通信できるんだっけ？の確認です

• 構成図は概要はこんな感じです。
• VPCを3つ作成。アドレスは/21で作成してます。
  VPC-A（site-a-vpc） : 172.26.0.0/21
  VPC-B（site-b-vpc） : 172.26.8.0/21
  VPC-C（site-c-vpc） : 172.26.16.0/21
• 真ん中のVPC（site-b-vpc）にはPublic Subnetを作成して、Internet Gatewayをおいています。
• アプライアンスはFortigateをMarket Placeから買って置いて、外に出れるようにしています。
• FortigateのVMに予めsite-a-vpcとsite-c-vpcで作成したENIをアタッチします。
• ENIのアタッチはCLIからのみ。出張中に作ったのでCloud Shellを使いました。
• それぞれのSubnetに通信テストをするためのUbuntuをおいています。ConsoleへのアクセスはEC2 Instance Connect Endpointを使いました。ICMPレベルとiperf3で測定
• Private SubnetのRoute Tableは、それぞれのVPCのFortigateのENIに向けています。
• Public SubnetのRoute Tableは、site-b-vpcのInternet Gatewayに向けています。

前振りの結論はこちら

site-aのubuntuからsite-bのFortigateを経由してのインターネットアクセス→問題なし
site-aのubuntuからsite-cのUbuntuにpingとiperf3の通信も問題なし
もちろん、site-bのubuntuから、site-aやsite-cのubuntuとも問題なく通信可能です。
可用性云々の話はおいておいて、ひとまずネットワークアプライアンスをサンドイッチしてネットワークが作れることはわかりました。

本題：VMware Cloud on AWSから、このEC2のENIは参照可能か？

• 結論からお伝えすると問題なくできましたが、課題が残ります。

おさらい：VMware Cloud on AWSのネットワーク構成について

この構成図にはVeeamのリポジトリやFSx for NetApp ONTAPの図がはいっておりますが、今回の構成の目的であるMulti-VPC ENI Atttachmentsは関係ありません。

少しだけおさらいします。

• VMware Cloud on AWSは、一つだけ特殊なVPCを作成します。これはNSX-TとENIが直結したVPCです。（VMCのT0から伸びているENIです）
• このVPCのメインルートテーブルにはVMware Cloud on AWSの管理セグメント（一般的に/23）とNSX-Tでユーザが作成したサブネットが経路伝搬してきます。
• VMware Cloud on AWSは、VMware ManagedのVPCにvSphereやNSX-TやVSANを導入した仮想基盤ですが、ユーザサブネットなどはNSX-Tの仮想ネットワークのため、アドレス帯も自由に作成が可能です。サブネットはVMware Cloud on AWSの管理コンソールのNSX-Tからサブネットを作成できます。

構成例

• 実際のアドレスを記して書いたほうがわかりやすいため、こちらにサンプルを作成します。
  VPC（ENI）：172.27.0.0/21
  VMC（管理）：172.27.8.0/23
  ユーザサブネット：172.27.10.0/24～172.27.15.0/24，192.168.255.0/24
• Direct ConnectやIntennet VPCでBGPを構成して流れてくるサブネットは、VPC（ENI）とVMC（管理）とユーザサブネットがバラバラ流れてきます。またこのユーザサブネットは、VPC(ENI）側のRoute Tableにも流れてきます（自動伝搬）
• ユーザサブネットはCIDRも含めて自由に作成可能です。（NGなアドレス帯はある）
• 自宅からIPSec+BGPでつながっているので、アドレスはサマライズする前提の設計です・・・。
  172.27.0.0/20とか・・・。

何が課題か？

• 今回は仮の話として、他のVPCからVMCとENI連携したVPCに他のVPCのEC2からENIを接続したとします。
• 他のVPCのEC2はDefault Gatewayは、所属するSubnetが指定するGatewayに向いています。
• VMC側のSubnetに作成したNICは、そのSubnetだけがConnectedで見えています。
• 他のVPCのEC2が、VMCのVPCの全体を認識する場合は、VPCのアドレスをEC2のRouteTableに書いてあげる必要があります（Persist Route）
• そして、問題は、NSX-T側で作成されるSubnetのRouteも追加が必要なことです。
  NSX-T側でSubnetを作ったタイミングで、VPCのRoute Tableには反映されますが、EC2の中に書かれたRouteTableは反映されません。（忘れやすい作業になる）

結論

• 上記のような課題を運用で解決などを考慮する必要がありますが、ENIで接続されたVPCに別のVPCで構成されたEC2のENIを接続することができる技術は非常に有効です。これまでVTGWを通すことでコストと遅延が発生したモノが改善されるのは大きいことかと思います。

さいごに・・・

テキストばかりで簡単にまとめましたが、最後までご覧頂きありがとうございました。