1. はじめに
2021年10月末から「VMware Cloud on AWS」も大阪リージョンに対応していましたが、つい先日(2022/7/29)にすべてのユーザー組織で利用できるようになったということで、私も試しに触ってみます。
本稿は2022年8月時点で執筆しており、デプロイ時のSDDCバージョンは1.18でした。
2. デプロイ直後、デフォルト状態のスクリーンショット
VMware Cloud コンソールからわかる概要
ホスト数は1ホスト、AWS大阪リージョンにデプロイされているのが分かります。
参考までに、左側はAWS東京リージョン同日にデプロイしたSDDCです。
vCenterにアクセスしてからわかる情報
他のAWSリージョンにデプロイしたSDDC環境と特には差異がありません。
3. VMware Transit Connect (VTGW) 経由で東京リージョンのVMware Cloud on AWSとping疎通させてみる
せっかくなのでVTGWを構成して、大阪リージョンと東京リージョンのping疎通確認をしてみます。
VMware Cloud on AWS上に仮想マシンをデプロイして、pingができるか確かめます。
VMware Transit Connectについては、次のVMware Japanブログの解説が分かりやすいのでご参考ください。
インベントリから「SDDC Groups」に遷移して、「Create SDDC Group」を実施します。
今回SDDC Groupとして構成する対象のSDDCを選択します。
しばらく待ってステータスがConnectedになると準備完了です。
これによって、最初の図のように東京リージョンと大阪リージョンの両側にVTGWが作成され、Inter-Region Peeringが構成されます。
過去に同様な記事があるので仮想マシンの作成については割愛しますが、
次のVMware Docsを参考にVMware Cloud on AWSのCompute Gateway Firewallを設定して両側で疎通できるようにFirewallの穴あけをしておきます。
大阪リージョンの仮想マシン(10.20.10.2)から、東京リージョンの仮想マシン(192.168.10.2)へのping疎通。
東京リージョンの仮想マシン(192.168.10.2)から、大阪リージョンの仮想マシン(10.20.10.2)へのping疎通。
4. さいごに
普段メインで東京リージョンでVMware Cloud on AWSを利用していますが、当然ながら大阪リージョンでもSDDC環境は同じです。
違いがあるとすれば、AWS大阪リージョンは元々ローカルリージョンということもあり、各種ネイティブAWSサービスへの対応は東京リージョンの方が若干早かったり充実している印象です。
もし地理的要件などの制約がそこまで強くないとすれば、基本的には東京リージョンをメインで利用していくのかと思います。あるいは東京リージョンのDRサイトとして大阪リージョンを利用するというケースも今後増えてくるかもしれません。
そういえばつい先日(2022/7/29)、ひっそりAWS香港リージョンにもVMware Cloud on AWSが対応していました。
今後も対応リージョンが増えていくのは嬉しい限りです！
4. 関連記事