Oracle VirtualBoxのVMをAWS Transform MGNでEC2へ移行してみた

こんにちはクラスメソッドのイ・スジェです。

以前の記事では、オンプレミスサーバーをAWSへ移行する方法の一つとしてAWS Transform MGNを紹介しました。

VMイメージを一度だけ取り込む方法もありますが、移行元サーバーを稼働させたまま変更されるデータまで反映するには、継続的なレプリケーションが必要です。それでは、オンプレミスに別のサーバーを用意しなくても、ローカルPCの仮想マシンでこの流れを確認できるのでしょうか。

本記事では、Oracle VirtualBoxで稼働しているUbuntu VMにAWS Replication Agentをインストールし、AWS Transform MGNを通じてEC2のテストインスタンスとして起動します。まずMGNの仕組みとメリット、考慮点を確認してから、実際のテスト手順を進めます。

AWS Transform MGNとは？

AWS Transform MGNは、物理サーバー、仮想サーバー、またはほかのクラウドのサーバーをAmazon EC2へ移行する際に利用できるサービスです。以前はAWS Application Migration Serviceという名称で提供されており、2026年6月からAWS Transform MGNという名称が使われています。

今回利用するエージェントベースの方式では、移行元サーバーのディスクをブロック単位でAWSへ継続的にレプリケーションします。初期同期が完了した後も変更されたブロックを転送し続け、必要なタイミングでレプリケーションしたデータを変換して、EC2のテストインスタンスまたはカットオーバーインスタンスとして起動します。カットオーバーは、本番サービスをAWS側へ切り替える段階です。

簡単な流れは次のとおりです。

VirtualBoxのUbuntu VM
        ↓ AWS Replication Agent
AWSのステージング領域
        ↓ 変換および起動
EC2のテストインスタンスまたはカットオーバーインスタンス

ステージング領域には、レプリケーションデータを受信するReplication ServerやEBSボリュームなどが作成されます。テストインスタンスを起動した後も移行元VMは稼働し続け、移行元で発生した新しい変更は、既存のテストインスタンスではなくステージング領域へレプリケーションされます。

テストインスタンスには、起動時に使用したレプリケーションデータの状態が反映されます。その後の変更分まで確認するには、新しいテストインスタンスを起動する必要があり、このとき既存のテストインスタンスは置き換えられます。

サポートされているVMware vCenter環境では、スナップショットを転送するエージェントレス方式も利用できます。VirtualBoxを使う今回の検証では、ゲストOSにエージェントをインストールします。AWSはVirtualBoxを個別のサポート対象プラットフォームとして明記していませんが、物理・仮想サーバーをOSレベルでレプリケーションするというサポート範囲をもとに構成した検証です。

メリットと考慮点

VM Import/Exportは、VMイメージをS3へアップロードしてAMIに変換する方式であり、イメージを作成した後の変更は自動的に反映されません。MGNには、変更分を継続的にレプリケーションしながらテストとカットオーバーを準備できるというメリットがあります。移行元サーバーを稼働させたまま、EC2での起動やアプリケーションの動作を何度も確認できます。

既存のOSとインストール済みのアプリケーションをまとめて移行するため、新しいサーバーですべての設定をやり直す負担も減らせます。この方式は、既存の構成をできるだけ維持したまま実行環境を移すリホスト移行に適しています。

ただし、エージェントベースの方式では、移行元サーバーごとに管理者権限でAWS Replication Agentをインストールする必要があります。サポートされるOSやアーキテクチャ、ブートローダー、ディスク構成などの条件も確認が必要で、Linuxの移行元サーバーではSecure Bootをサポートしていません。

レプリケーション中は、移行元サーバーからMGN APIへのTCP 443、AWSのReplication ServerへのTCP 1500の通信が必要です。ステージング領域にもReplication ServerやEBSボリュームなどのリソースが作成されるため、ネットワーク構成とコストを併せて考える必要があります。

MGNのサービス料金は、移行元サーバーごとに連続使用で90日間無料ですが、レプリケーションの過程で作成されるEC2、EBS、スナップショット、テストインスタンスなどの料金は別途発生します。無料利用期間はエージェントをインストールした時点から始まることにも注意が必要です。

また、継続的なレプリケーションによって無停止で切り替えられるとは限りません。実際のカットオーバーでは、移行元アプリケーションへの書き込みを停止し、最後の変更分が反映されたことを確認したうえで、EC2インスタンスの起動とアプリケーションの検証まで行う必要があります。

MGNは基本的に、既存サーバーをEC2へ移すリホスト方式です。サーバーが正常に起動しても、IPアドレスやDNS、外部システムとの接続、ライセンス、運用方法まで自動的に解決されるわけではありません。

使ってみる

今回のテストでは、VirtualBox VMをAWSへ継続的にレプリケーションし、EC2のテストインスタンスを起動するところまで確認します。本番環境への切り替えが目的ではないため、カットオーバーは実施しません。

テスト環境は次のとおりです。

VMとSSHを準備する

Ubuntu Server 22.04 LTSのx86_64インストールISOを使ってVirtualBox VMを準備します。今回は2 vCPU、4GBのメモリ、20GBの仮想ディスクを使用し、VMのブートローダーにはGRUBを設定してSecure Bootは使用しません。このスペックはMGNの最小要件ではなく、検証用の構成です。

UbuntuにOpenSSHサーバーを用意し、Windowsで使用するSSH公開鍵を一般ユーザーの~/.ssh/authorized_keysに登録します。秘密鍵はWindowsに保管します。

ネットワークにはNATを使用します。Windowsから接続できるように、TCP 127.0.0.1:2222をゲストの22番ポートへ転送するポートフォワーディングルールを追加します。ゲストがNATのDHCPを使用する場合、ゲストIPは空欄にします。

VMの作成とSSH設定の詳しい手順は省略し、Windowsから公開鍵認証でUbuntuへ接続できる状態から進めます。後ほどEC2のテストインスタンスにも、同じUbuntuのユーザーとSSH鍵で接続します。

確認用のWebサーバーを作成する

Ubuntu VMへSSH接続し、簡単なNginx Webサーバーを作成します。確認用のページを用意しておくと、後ほどEC2でも同じファイルの内容とサービスの動作を確認できます。

次のコマンドはWindows PowerShellではなく、SSH接続したUbuntuで実行します。

# Nginxをインストールし、移行元VMの状態を変更します。
sudo apt update
sudo apt install -y nginx curl

echo 'MGN test page - version 1' | sudo tee /var/www/html/index.html
sudo systemctl enable --now nginx
curl http://127.0.0.1

最後のコマンドで、次の内容が表示されることを確認します。

MGN test page - version 1

AWS Transform MGNの初期設定を行う

AWSマネジメントコンソールで、東京リージョン（ap-northeast-1）のAWS Transform MGNコンソールを開きます。初めて使用するリージョンの場合は、必要なIAMロールを作成する権限を持つユーザーまたはロールで、Get startedから初期設定を行います。

レプリケーション環境は、Settings → Replication template → Editから設定できます。移行元サーバーを追加する前に、AWS側でレプリケーションデータを受け取る環境を決める段階です。

Staging area subnetでは、インターネットゲートウェイへのデフォルトルートがあるパブリックサブネットを選択します。Target storage typeはデフォルトのAmazon EBSを使用します。

セキュリティグループはAlways use AWS Transform MGN security groupを有効にし、MGNに管理させます。レプリケーションデータを受け取るTCP 1500のルールもサービスが管理するため、今回はカスタムセキュリティグループを追加しません。

続いて、Data routing and throttlingを次のように設定します。

この設定により、Replication ServerへパブリックIPv4アドレスが割り当てられ、移行元VMからインターネット経由でレプリケーションデータが転送されます。今回はVPNやDirect Connectなどのプライベート接続を構成しないため、レプリケーションにPrivate IPv4 addressを使用するほかのオプションは選択しません。

同じ回線を使うほかの作業に影響がある場合は、Throttle network bandwidthを有効にし、サーバーごとの転送帯域幅の上限をMbps単位で指定できます。

ステージング領域のサーバーからMGN・EC2 APIおよび必要なS3バケットへHTTPS（TCP 443）でアクセスできることも確認し、設定を保存します。

エージェントのインストールに使用するAWS認証情報を準備する

エージェントをインストールする際は、サーバーをMGNへ登録できるAWS認証情報が必要です。ここでは、移行先AWSアカウントにインストール用のIAMロールを作成し、STSで一時的な認証情報を発行します。

IAMコンソールのRoles → Create roleで、信頼されたエンティティタイプにAWS account、アカウントにThis accountを選択します。許可ポリシーとしてAWSApplicationMigrationAgentInstallationPolicyをアタッチし、ロール名には、例えばMgnVirtualBoxAgentInstallを指定します。

このロールを使用する作業者にも、ロールに対するsts:AssumeRole権限が必要です。既存の権限に含まれていない場合は、次のポリシーを作業者のIAMユーザーまたはロールへ付与します。<account-id>は検証用AWSアカウントのIDに置き換えます。IAM Identity Centerを使用する場合は、該当する許可セットを通じて付与します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<account-id>:role/MgnVirtualBoxAgentInstall"
    }
  ]
}

移行先AWSアカウントのユーザーまたはロールでAWS CloudShellを開き、次のコマンドで同じアカウント内のインストール用ロールを引き受けます。別のAWSアカウントから利用する場合は、まず移行先アカウントの作業用ロールへ切り替えてからCloudShellを開きます。

CloudShellではAWS CLIを使用できるため、この手順のためにUbuntu VMへAWS CLIをインストールする必要はありません。

# インストールに使用する一時的な認証情報を発行します。出力には機密情報が含まれます。
aws sts assume-role \
  --role-arn 'arn:aws:iam::<account-id>:role/MgnVirtualBoxAgentInstall' \
  --role-session-name mgn-virtualbox-install \
  --duration-seconds 3600 \
  --query Credentials \
  --output json

出力されたAccessKeyId、SecretAccessKey、SessionTokenを、次のインストール手順で入力します。Expirationより前にインストールを行い、期限切れになった場合は再度発行します。ロールの信頼ポリシーにMFA条件を追加している場合は、AssumeRoleの呼び出しにも条件を満たすMFA情報を渡す必要があります。

AWS Replication Agentをインストールする

インストールの前に、Ubuntu VMのアーキテクチャとディスクの空き容量を確認します。uname -mの出力はx86_64である必要があり、ルートディレクトリに2GB以上、インストール中は/tmpに1GB以上の空き容量が必要です。

/bootが別のパーティションになっている場合は、/bootにも50MB以上の空き容量が必要です。

uname -m
df -h / /tmp /boot

実行中のカーネルと同じバージョンのヘッダーとDHCPクライアントも必要です。Pythonとインストールファイルのダウンロードに使用するツールも併せて準備します。

# エージェントのインストールに必要なパッケージを移行元VMへインストールします。
sudo apt update
sudo apt install -y "linux-headers-$(uname -r)" isc-dhcp-client python3 wget

移行元VMからMGN APIへのTCP 443、Replication ServerへのTCP 1500のアウトバウンド通信が必要です。この通信はVMからAWSへ開始されるため、SSH接続とは異なりNATのポートフォワーディングは必要ありません。

また、MGNはMACアドレスを使って移行元サーバーを識別します。そのため、エージェントをインストールした後は、VirtualBoxでVMのMACアドレスを再生成しないようにします。

準備ができたら、Ubuntu VMで東京リージョン用のインストーラーをダウンロードします。

wget -O aws-replication-installer-init \
  https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init

実行権限を付与してから、インストーラーを実行します。

# AWS Replication Agentを移行元VMへインストールします。
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region ap-northeast-1

レプリケーションするディスクを尋ねられたら、Ubuntuのブート領域とルートファイルシステムを含む仮想ディスクを選択します。今回のようにディスクが一つだけの構成では、そのディスク全体が対象です。インストールが完了すると、MGNコンソールのSource serversに新しいサーバーが登録され、初期同期が始まります。

エージェントのインストールが成功すると、次のようなメッセージを確認できます。このメッセージはエージェントのインストールが完了したことを示しており、初期レプリケーションの完了を意味するものではありません。

 sudo ./aws-replication-installer-init --region ap-northeast-1
[sudo] password for sujae:
The installation of the AWS Replication Agent has started.
AWS Access Key ID: 
AWS Secret Access Key: 
AWS Session Token: 
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/sda
To replicate some of the disks, type the path of the disks, separated with a comma (for example, ...
The AWS Replication Agent was successfully installed.

初期レプリケーションを確認する

エージェントのインストール後に初期レプリケーションが始まると、コンソールのダッシュボードに次のように表示されます。

上のダッシュボードに表示されている1 server, 100%は、登録されたサーバーのうち該当する状態にあるサーバーの割合であり、初期レプリケーションの進捗率ではありません。

MGNコンソールで、移行元サーバーのData replication statusを確認します。最初はInitial syncなどと表示され、初期レプリケーションが完了するとHealthyへ変わります。

テストインスタンスを起動する前に、次の状態になっていることを確認します。

• Migration lifecycle: Ready for testing
• Data replication status: Healthy
• Next step: Launch test instance

初期レプリケーションにかかる時間は、ディスクのデータ量やネットワーク帯域幅などによって異なります。

EC2の起動設定を確認する

移行元サーバーのLaunch settingsで、テストインスタンスを起動するVPCとサブネット、インスタンスタイプ、セキュリティグループを確認します。レプリケーションデータをどの環境で、どのようなEC2構成として起動するかは、レプリケーション設定とは別に管理されます。

今回のテストでは、SSHとWebページを確認できるように、テストインスタンスのセキュリティグループで次のインバウンド通信を許可します。送信元には、接続元PCがインターネット接続に使用するグローバルIPv4アドレスを指定します。

• TCP 22：接続元のグローバルIPv4アドレス（/32）
• TCP 80：接続元のグローバルIPv4アドレス（/32）

インターネットからEC2へ直接接続するには、インターネットゲートウェイへのルートがあるパブリックサブネットとパブリックIPアドレスも必要です。プライベートサブネットで起動する場合は、VPN、Session Manager、または別の接続経路を用意する必要があります。

MGNはEC2 Launch Templateのdefaultバージョンのみを使用するため、設定を変更してもdefaultバージョンでなければ反映されません。

また、Instance type right-sizingが有効になっている場合、EC2 Launch Templateで指定したインスタンスタイプよりも、MGNが選択した値が優先されます。

上の画面のPublic IP: Noは、パブリックIPアドレスの自動割り当てが無効になっている状態です。今回のようにパブリックIPアドレスを使って直接接続する場合は、EC2 Launch TemplateのネットワークインターフェイスでAuto-assign public IPをEnableに設定し、変更したバージョンをdefaultに指定してからテストインスタンスを起動します。

テストインスタンスを起動する

Source serversで対象のサーバーを選択し、Test and cutoverメニューからLaunch test instancesを実行します。

レプリケーションしたデータをもとにスナップショットと変換処理が実行され、EC2のテストインスタンスが作成されます。
EC2コンソールでインスタンスが実行中であり、ステータスチェックに合格していることを確認してから、Windows PowerShellでSSH接続します。
今回はポートフォワーディングを経由せず、EC2のパブリックIPアドレスに対して、デフォルトのSSHポートである22番へ接続します。

$mgnSshKeyPath = '<private-key-path>'
ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i $mgnSshKeyPath '<source-user>@<test-instance-public-ip>'

<private-key-path>は移行元VMへの接続に使用したWindows上の秘密鍵ファイルのフルパス、<source-user>はUbuntuのユーザー名に置き換えます。<test-instance-public-ip>には、今回作成されたEC2のパブリックIPアドレスを入力します。

接続したら、Nginxとディスクの状態を確認します。

sudo systemctl is-active nginx
curl http://127.0.0.1
lsblk

WebブラウザからもテストインスタンスのパブリックIPアドレスへアクセスし、次の内容が表示されることを確認します。

ここまで確認できれば、VirtualBoxのVMディスクがAWSへレプリケーションされ、EC2で起動できる形式へ変換されたことが分かります。

変更分もレプリケーションされるか確認する

MGNの継続的なレプリケーションを確認するため、移行元のVirtualBox VMにあるページを変更します。

# 移行元VMのファイルを変更します。
echo 'MGN test page - version 2' | sudo tee /var/www/html/index.html
curl http://127.0.0.1

MGNコンソールでData replication statusがHealthyであることを確認し、移行元サーバーのMigration dashboardでLagとBacklogが発生していないことも確認します。小さな変更の場合はHealthyのままレプリケーションされることがあるため、いったん別の状態に変わってから戻るのを待つ必要はありません。

すでに起動している最初のテストインスタンスにも再度接続し、ページがversion 1のままであることを確認します。新しい変更分はテストインスタンスではなく、ステージング領域へ転送されるためです。

最初のテストをReady for testingの状態へ戻す際に既存のテストインスタンスを終了し、その後、新しいテストインスタンスを起動します。

パブリックIPアドレスが変わる可能性があるため、EC2コンソールで新しいインスタンスのアドレスを確認して接続します。2回目のテストインスタンスで、次の内容が表示されることを確認します。

テスト用リソースを削除する

テストが終わったら、まずMGNコンソールでテストの状態を戻し、テストインスタンスを終了するオプションを選択します。EC2コンソールでも、テストインスタンスが残っていないことを確認します。

その後、Source serversで対象のサーバーを選択してDisconnect from serviceを実行すると、レプリケーションが停止します。移行元VMを起動したままAWSと通信できる状態にしておくと、エージェントがアンインストールの指示を受け取ります。サービスから切断しても、起動中のテストインスタンスは自動的に終了されないため、前の手順で別途削除する必要があります。

レプリケーション用リソースは非同期で削除されます。公式APIドキュメントでは、サービスから切断した後、90分以内に削除されると案内されています。削除処理が進んだ後に、ステージング用のReplication Server、EBSボリューム、スナップショットなどが残っていないか確認します。

今後使用する予定がなければ、検証用に作成したMgnVirtualBoxAgentInstallロールと、作業者へ追加したAssumeRole権限も削除します。既存のVPCやセキュリティグループなど、テスト前から使用していたリソースは残します。

MGNが作成するEC2インスタンスを区別する

レプリケーションとテストを進めると、EC2コンソールには自分で起動したテストインスタンスのほかにも、MGNが管理するインスタンスが表示されます。今回の検証でも、AWS Application Migration Service Replication ServerとAWS Application Migration Service Conversion Serverという名前のインスタンスを確認できました。

Replication Serverは、移行元VMから転送されたブロックデータを受け取り、ステージング領域のストレージへ書き込みます。Replication templateで指定したサブネット、インスタンスタイプ、セキュリティグループなどの設定が、このサーバーに適用されます。

Conversion Serverは、TestまたはCutoverインスタンスを起動する際に、レプリケーションされたブートディスクをEC2で起動できるように変換する一時的なサーバーです。Replication Serverと同じセキュリティグループを使用し、MGNによって自動的に管理されるため、どちらのサーバーにも直接接続したり、停止したりしません。

実際に確認する対象は、MGNのMigration dashboardからView in EC2 consoleで開くTest instanceです。移行元サーバーのLaunch settingsとEC2 Launch Templateは、このTest instanceとカットオーバー時に起動するCutover instanceへ適用されます。

参考：Test instanceとCutover instanceの違い

Launch test instancesとLaunch cutover instancesは、どちらも最新のレプリケーションデータをもとにスナップショットと変換処理を行い、EC2を起動します。同じLaunch settingsを使用する点も共通していますが、MGN上の目的と起動後の処理が異なります。

Test instanceで確認が終わっても、そのインスタンスをそのまま本番用へ切り替えるわけではありません。Launch cutover instancesを実行すると、既存のTest instanceとその依存リソースが削除され、移行元のレプリケーションデータをもとに新しいCutover instanceが作成されます。Test instanceだけに加えた変更は、Cutover instanceには引き継がれません。

今回はCutoverを実行しませんが、実際に進める場合は、前述のDisconnect from serviceではなく次の流れで切り替えます。

Test instanceを検証
→ Mark as "Ready for cutover"
→ 移行元アプリケーションへの書き込みを停止
→ Healthy状態とLag・Backlogを確認
→ Launch cutover instances
→ Cutover instanceへ接続してアプリケーションを検証
→ DNS・ロードバランサーなどのトラフィック経路を切り替え
→ 切り替え後の経路でサービスの動作を確認
→ Finalize cutover

MGNが移行元アプリケーションへの書き込み停止やトラフィックの切り替えまで自動的に行うわけではありません。移行元への書き込みを停止し、最後の変更分がレプリケーションされたことを確認してからCutover instanceを起動する必要があります。その後、環境に合わせてDNSやロードバランサーの設定などを変更し、実際のリクエストが新しいインスタンスで正常に処理されることを確認します。

サービスの切り替えまで検証してからFinalize cutoverを実行すると、データのレプリケーションが停止し、Replication Serverやステージングストレージなどのレプリケーション用リソースが削除されます。Cutover instance自体は終了されず、その後も本番インスタンスとして使用できます。

おわりに

Oracle VirtualBoxはMGNのエージェントレスレプリケーションの対象ではありませんが、サポートされているゲストOSへAWS Replication Agentをインストールすることで、MGNの主な流れをテストできます。

今回の構成では、初期レプリケーションとEC2テストインスタンスの起動に加え、移行元で発生した変更分を反映して新しいテストインスタンスを起動するところまで確認しました。小さなVMでも、MGNがデータをどのようにレプリケーションし、テストインスタンスを作成するのか確認できます。

ただし、実際の移行では、1台のサーバーが起動できることを確認するだけでは不十分です。アプリケーション間の依存関係やデータの整合性、ネットワーク、DNS、証明書、ライセンス、カットオーバー後の運用まで別途検証する必要があります。

MGNを利用したサーバー移行を検討している方の参考になれば幸いです。

最後までお読みいただき、ありがとうございました。

参考資料

• MGNの概要：サービス概要・一般的なFAQ・名称変更のお知らせ
• サポート範囲：対応OS・エージェントレスレプリケーション
• エージェントのインストール：インストール要件・Linuxへのインストール手順
• レプリケーション環境：初期設定・Replication template・セキュリティグループとデータルーティング・ネットワーク要件・パブリックサブネットとインターネットゲートウェイ
• インストール用の認証：MGNの認証情報を準備する・IAMロールを作成する・STS AssumeRole・CloudShellでAWS CLIを使用する
• ローカルVMへの接続：VirtualBoxのNATとポートフォワーディング・Ubuntu OpenSSHと公開鍵認証
• EC2の起動設定：Launch Templateの詳細設定・defaultバージョンの適用
• テストとカットオーバー：テストインスタンスを起動する・Ready for cutoverへ移行する・カットオーバーインスタンスを起動する・カットオーバーを完了する・Lag・Backlogを確認する・移行先インスタンスの設定
• MGNが管理するインスタンス：Replication ServerとConversion Server
• 本番環境への切り替え：カットオーバー段階の考慮事項
• MGNの料金に関するFAQ
• リソースの削除：エージェントのアンインストール・DisconnectFromService