1. はじめに
オンプレミス環境からAmazon EC2に移行する際に利用するツールとして、AWS Application Migration Service (MGN)はよく検討される選択肢かと思います。
VMware Cloud on AWSからもAmazon EC2への移行でも同様にAWS MGNが活用できるので、前回に引き続き実際に試してみた手順を備忘録として残します。
今回はConnected VPCのENI経由で移行元VM(のAWS Replicaiton Agent)とAWS MGNをプラベートアクセスさせています。
前回記事ではInternet Gateway(IGW)経由で移行元VM(のAWS Replicaiton Agent)とAWS MGNをパブリックアクセスさせる構成をご紹介しています。
AWS MGNの概要、および共通する手順の詳細については前回も合わせて記事をご参考ください。
ざっくりとしたイメージとしては、VMware Cloud on AWSを「オンプレミスVMware仮想環境」のように扱って、Amazon EC2に移行していると想像いただければと思います。
2. 今回の構成
ステージング環境およびターゲット環境ともに、移行元であるVMware Cloud on AWSのConnected VPCを選択しています。
Connected VPCのENI経由で移行元VM(のAWS Replicaiton Agent)とAWS MGNをプラベートアクセスさせるために、Amazon Route 53、AWS PrivateLink、Amazon S3 gateway endpointを利用します。
何やら構成が若干複雑に見えますが、実際の構築手順は簡単です。今回は構築でポイントとなる部分を抜粋してご紹介します。
ちなみにVMware Cloud on AWS環境は前回と同じくVMware vSphere 8.0系、移行元仮想マシンはWindows Server 2019およびCentOS Linux 7系です。
3. やってみた
基本的にAWS公式ガイドの手順に沿っていけばセットアップできます。
今回はシンプル化のためConnected VPCにはサブネット、ルートテーブル、セキュリティグループはそれぞれデフォルトの１つだけしか持たせていません。またPublic IPあるいはNAT Gatewayも利用していません。
各種エンドポイントの作成 < Connectec VPCの設定 >
AWS MGN、Amazon EC2、Amazon S3 のエンドポイントをConnected VPC内に作成していきます。
Amazon S3 の Gateway Endpint と Interface Endpoint (PrivateLink) のちがいについては次の Docs をご参照ください。
AWS MGN のInterface Endpoint を作成
Private DNS名での名前解決は有効にします
Amazon EC2 のInterface Endpoint を作成
Private DNS名での名前解決は有効にします。
Amazon S3 のInterface Endpoint を作成
Interfaceタイプを選択し、Private DNS名での名前解決は無効(有効のチェックボックスを外す)にします。
Amazon S3 のGateway Endpoint を作成
Gatewayタイプを選択します。
DNSの設定 < Connectec VPC、VMCの設定 >
プライベートアクセス環境における各種AWSサービスのDNS名前解決のため、Connected VPC側でAmazon Route 53 Resolver の Inbound Endpointを作成し、VMware Cloud on AWS側のDNSサービスに登録します。
Amazon Route 53 Resolver の Inbound Endpoint を作成
Inbound onlyを選択します。
次のステップで使うのでIPアドレスを控えておきます。
VMware Cloud on AWS 側のDNSサービスに登録 < VMCの設定 >
DNS Zoneを作成します。
DomainはAWSサービスの"amazonaws.com"を指定し、DNS ServersのIPアドレスは作成した Amazon Route 53 Resolver の Inboud EndPoint のIPを入力します。
DNSサービスを登録します。
作成したDNS Zoneを、Compute Gateway DNS Forwarderに登録します。
以上で、DNSの設定は完了です。
Gateway Firewall、Security Group の設定 < VMCの設定 >
VMware Cloud on AWS側からConnected VPCへのアクセスに必要なポートの通信許可をします。
今回は検証環境なので、VMware Cloud on AWS上の移行元仮想マシンからConnected VPCへの通信は全て許可しています。
またConnected VPC側Security Groupはデフォルトのまま設定変更はせず、VMware Cloud on AWSからの通信は全て許可しています。
もちろん必要な通信ポートだけにアクセス許可を絞ることもできます。その場合はAWS公式ガイドも合わせてご参照ください。
Amazon EC2 への移行
以降は前回記事と同じくAWS Replication Agentを実行するだけなのですが、このエージェントはAmazon S3 Interface Endpoint経由でダウンロードする必要があります。
手順が被る部分については説明を割愛しているので、前回記事も合わせてご参考ください。
Windows の場合
Windows用のエージェントをブラウザから次のURL経由でダウンロードします。
https://aws-application-migration-service-<aws_region>.bucket.<s3-endpoint-DNS-name>/latest/windows/AwsReplicationWindowsInstaller.exe
例えば私の作成した環境では次のようになります。一部****としてマスクしています。
https://aws-application-migration-service-us-east-1.bucket.vpce-0929d2****42f7fe-5mz****b6c.s3.us-east-1.vpce.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe
ダウンロード後、エージェントを管理者権限で実行します。
エージェントが実行されれば、自動的にレプリケーションが実行されます。
以降はAWSマネジメントコンソールからAWS MGNの手順にしたがってAmazon EC2への移行を進めていきます。
Linux の場合
次のコマンドを使用してLinux用のエージェントをインストールします。
wget -O ./aws-replication-installer-init.py \
https://aws-application-migration-service-<aws_region>.bucket.<s3-endpoint-DNS-name>/latest/linux/aws-replication-installer-init.py
例えば私の作成した環境では次のようになります。一部****としてマスクしています。
wget -O ./aws-replication-installer-init.py \https://aws-application-migration-service-us-east-1.bucket.vpce-0929d2****42f7fe-5mz****b6c.s3.us-east-1.vpce.amazonaws.com/latest/linux/aws-replication-installer-init.py
ダウンロード後、エージェントを実行すれば自動的にレプリケーションが実行されます。
以降はAWSマネジメントコンソールからAWS MGNの手順にしたがってAmazon EC2への移行を進めていきます。
4. さいごに
今回も前回に引き続き、AWS MGNを活用したVMware Cloud on AWS環境からAmazon EC2への移行を試してみました。
インターネットへのアクセスがない、プライベートアクセスのみの環境でもVMware Cloud on AWSからConnected VPC内のAmazon EC2に移行できるということが検証できました。
AWS PrivateLink、Amazon Route 53など複数のサービスを活用しましたが、存外簡単にセットアップできるということも感じていただければ幸いです！
今度は他にもAWS Migration Hubを活用したより発展的な移行、またVMware vCenter Converterを活用したAmazon EC2からVMware Cloud on AWSへの逆方向の移行なども試してみようと思います。
余談: Amazon S3 Gateway Endpoint と Interface Endpoint の違い
ざっくり紹介すると、「Interface Endpoint (= PrivateLink)」ではデータ処理に応じた課金(per GB)および利用時間課金 (per Hour)が発生するのに対し、 「Gateway Endpoint」では課金が一切発生しません。
そのため、コストの観点では可能な限り「Gateway Endpoint」を利用していくことが基本戦略になります。
詳細な利用シーンおよび課金体系については次の資料もご参考ください。
5. 前回記事
6. 参考にさせていただいた資料