📌 はじめに
オンプレミスの VMware vSphere 環境で稼働している仮想マシンを AWS へ移行する際、最もシンプルかつ確実な手法が 「リホスト（Rehost / Lift-and-Shift）」 です。
特に、「レガシーな商用パッケージや複雑なミドルウェア設定が入っており、新しいOSへ再インストールできない」「既存のOS構成やソフトウェア設定を100%保持したままクラウドへ移行したい」という要件に対して、AWS 公式のイメージインポート機能である VM Import/Export を利用した標準移行パイプラインについて整理します。
1. 業務シナリオとコア要件の整理
業務背景
- 移行元 (Source): オンプレミスデータセンターで稼働する VMware vSphere 仮想化基盤上の仮想マシン。
- 移行先 (Destination): Amazon EC2（AWSクラウド）。
コア要件と制約条件
-
OS・ソフトウェア設定の完全保持（Retain software and configuration settings）:
- クリーンなOSを再プロビジョニングしてアプリを再導入するのではなく、ディスクレベル・イメージレベルでOS状態、設定ファイル、依存パッケージを丸ごと引き継ぐ必要がある。
-
標準機能による完結:
- サードパーティ製のエージェントを多数インストールすることなく、VMware の標準エクスポート機能と AWS の受管サービスを活用して移行を実現する。
2. アーキテクチャトポロジー
本構成では、VMware から出力した仮想ディスクイメージ（OVF/VMDK）を Amazon S3 経由で VM Import/Export エンジンへ渡し、ネイティブな Amazon Machine Image (AMI) を生成します。
┌────────────────────────────────────────────────────────┐
│ オンプレミスデータセンター (On-Premises) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ VMware vSphere 環境 │ │
│ │ │ │
│ │ [ 本番仮想マシン (全ソフトウェア・設定を内包) ] │ │
│ │ │ │ │
│ │ │ 1. 標準イメージ形式 (OVF / OVA) 変換 │ │
│ │ ▼ │ │
│ │ [ 仮想ディスクファイル (.ovf / .vmdk) ] │ │
│ └──────────────┬───────────────────────────────────┘ │
└─────────────────┼──────────────────────────────────────┘
│ 2. 大容量ファイル転送 (HTTPS / S3 Transfer Acceleration)
▼
┌────────────────────────────────────────────────────────┐
│ 移行先 AWS Region (クラウド) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Amazon S3 バケット (OVF/VMDK イメージの一時保管) │ │
│ └──────────────────────┬───────────────────────────┘ │
│ │ │
│ │ 3. vmimport ロール権限で実行 │
│ │ aws ec2 import-image │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ AWS VM Import/Export サービス変換エンジン │ │
│ │ (AWS用ドライバ注入、ブートローダーの変換処理) │ │
│ └──────────────────────┬───────────────────────────┘ │
│ │ │
│ │ 4. プライベート AMI を生成 │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Amazon EC2 AMI (元のVMwareイメージと完全互換) │ │
│ └──────────────────────┬───────────────────────────┘ │
│ │ │
│ │ 5. インスタンスの起動 │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Amazon EC2 稼働インスタンス (設定・ソフト100%保持) │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘
3. なぜこの方式を採用するのか？（3大コアメカニズム）
① VMware 標準形式のネイティブサポート
- VMware vSphere は、仮想マシンの状態を丸ごとパッケージ化する OVF（Open Virtualization Format） や OVA、VMDK 形式のエクスポートを標準でサポートしています。
- 稼働中のOS内部を個別に解析・解体することなく、ハイパーバイザーレベルでカプセル化して抽出できます。
② VM Import/Export による標準インポート手順
- AWS VM Import/Export は、既存の仮想マシンイメージを EC2 の起動テンプレートである AMI（Amazon Machine Image） へ直接変換する AWS 公式のマネージド変換エンジンです。
- 標準的な3つのステップ:
- エクスポートした仮想ディスクファイルを Amazon S3 バケットへアップロード。
- 専用のサービスロール（
vmimport）を作成し、S3 へのアクセス権限および EC2 AMI 生成権限を付与。 - AWS CLI で
aws ec2 import-imageを実行。バックエンドで仮想マシンのストレージボリュームが EBS スナップショットへ変換され、AMI が自動生成される。
③ 構成・データの無損失継承
- 生成された AMI には、オンプレミス環境の OS 状態、レジストリ、ミドルウェア設定、静的ファイルがディスクイメージ単位でそのまま保持されます。
- インスタンス起動時に必要な ENA ドライバ（Elastic Network Adapter）や AWS 向けのストレージドライバは変換プロセス中に自動注入されるため、起動後の追加設定の手間を最小限に抑えつつ、要件である「ソフトウェアおよび設定の完全保持」を確実に達成できます。
4. 構築手順とコマンド例（AWS CLI）
Step 1: vmimport 用の IAM サービスロール設定
VM Import/Export サービスが S3 バケットのイメージを読み込み、EBS スナップショットを作成するためのロールを作成します。
信頼ポリシー (trust-policy.json)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "vmie.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals":{
"sts:Externalid": "vmimport"
}
}
}
]
}
ロール作成とポリシー適用
# IAM ロールの作成
aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json
# S3バケットおよびEBS操作権限を定義したポリシーをアタッチ
cat << 'EOF' > role-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-migration-bucket-tokyo",
"arn:aws:s3:::my-migration-bucket-tokyo/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySnapshotAttribute",
"ec2:CopySnapshot",
"ec2:RegisterImage",
"ec2:Describe*"
],
"Resource": "*"
}
]
}
EOF
aws iam put-role-policy --role-name vmimport --policy-name vmimport-policy --policy-document file://role-policy.json
Step 2: イメージインポートタスクの実行
S3 バケットへアップロード済みのディスクイメージ（例: my-vm-disk.vmdk）を指定してインポートを開始します。
インポート設定 (containers.json)
[
{
"Description": "Migrated VMware VM",
"Format": "vmdk",
"UserBucket": {
"S3Bucket": "my-migration-bucket-tokyo",
"S3Key": "imports/my-vm-disk.vmdk"
}
}
]
インポート実行と進捗確認
# インポートタスクの開始
aws ec2 import-image --description "VMware to EC2 Migration" --disk-containers file://containers.json
# 出力された ImportTaskId を指定して進捗を確認
aws ec2 describe-import-image-tasks --import-task-ids import-ami-1234567890abcdef0
変換プロセスが completed になると、ImageId（例: ami-0a1b2c3d4e5f60000）が出力され、即座に EC2 インスタンスを起動できる状態になります。
5. 設計上の注意点と移行手法の選定基準
| 移行手法 | メリット | デメリット / 適用シーン |
|---|---|---|
| VM Import/Export (本構成) | エージェントレス。vSphere からエクスポートしたディスクイメージを丸ごとインポート可能。構成保持に最適。 | イメージのエクスポート・アップロード中に静止点が必要となるため、ある程度の停止時間（オフライン移行）を許容できるバッチ系・単発移行向け。 |
| AWS Application Migration Service (MGN) | 稼働中のOS上でエージェントを動かし、ブロック単位の継続的レプリケーションを実施。ダウンタイムを分単位に短縮。 | オンラインで無停止・最小停止時間での切り替えが必須となる、高可用性が求められる本番システム向け。 |
6. まとめ
- 設定の完全保持: VMware の仮想ディスクをそのまま AMI へ変換するため、既存のミドルウェア・OS設定・データを失うことなく確実に引き継ぎ可能。
-
標準パイプライン:
vSphere エクスポート➔S3 アップロード➔aws ec2 import-image (vmimport)の3ステップで完結。 - エージェントレスの優位性: 稼働中のゲストOS内部を過度に汚すことなく、ディスク単位で安全にクラウドへ移行できる。