仮想Amazon EC2インスタンス上でネストされた仮想化についての簡単な解説と、ネットワーク観点での調査、利用シーンについての考察

アップデートの概要

一言で言ってしまえば、「ベアメタルインスタンスじゃなくてもAmazon EC2インスタンスでハイパーバイザーを使えるようになった」というアップデートです。これまでAmazon EVS等、VMwareベースの仮想基盤をAWSで動かすソリューションがありましたが、KVMやHyper-Vで動いていたVMのAWS移行にはAWS MGN等のツールを使い、Amazon EC2やその他のサービスに乗り換える必要がありました。

少し技術的な観点で解説をすると、AWSのハイパーバイザーであるNitroハイパーバイザーの上にAmazon EC2インスタンスが構築されますが、OSとの間にハイパーバイザーのレイヤーが追加される形になります。WindowsのAmazon EC2インスタンスで本機能を有効化するケースを図にすると次のようになります。

前提条件

2026年3月時点では、本機能を利用するためには以下の点に注意しながら使うことができます。

• 対応インスタンスタイプ：C8i/M8i/R8iインスタンス
• 対応ハイパーバイザー：KVM/Hyper-V
• Windowsのインスタンスで使う場合：
  • Virtual Secure Mode (VSM) は自動的に無効化
  • ハイバーネーションは利用不可
  • vCPU数は192まで
• セキュリティ上の責任：通常のAmazon EC2インスタンスにおける責任共有モデルでは、ハイパーバイザーは「クラウドのセキュリティ」としてAWSが担います。本機能を利用すると、Amazon EC2インスタンス内のハイパーバイザー（Hyper-V/KVM）から上のレイヤーが「クラウド内のセキュリティ」としてユーザー側の責任範囲となります。したがって、OSのセキュリティだけではなく、ハイパーバイザーのセキュリティに対応が必要
• パフォーマンス観点：Amazon EC2インスタンス上にハイパーバイザーのレイヤーが加わるため、パフォーマンスやレイテンシー要件が厳しい場合、ベアメタルインスタンスと合わせて評価が必要

AWS環境でのネスト仮想化についてNTT東日本のクラウドエンジニアがご相談にお応えします。ぜひお気軽にお問い合わせください。

できるようになること・利用シーン

このアップデートによってできるようになったことの例は次の通りです。

• Hyper-VやKVM上で動いていたVMをそのまま移行したい
• Windows ServerでDockerを動かしたい
• EC2インスタンスタイプの制約にとらわれず、柔軟にVMのスペックを選定したい
• isoファイル等、仮想化イメージで提供されるアプライアンスのAWSでの利用（実際の利用にはアプライアンスのライセンス条件もご確認ください）
• モバイルアプリケーションや車載ハードウェアのエミュレーションをしたい

実践

では実際に仮想 Amazon EC2 インスタンス上でネストされた仮想化を体験してみましょう。今回は、次の条件で実践してみたいと思います。

• インスタンスタイプ： m8i.large
• OS: Windows Server 2025 Base(英語版)
• リージョン：東京リージョン(ap-northeast-1)
• ハイパーバイザー：Hyper-V

ネストされた仮想化を有効化した仮想 Amazon EC2 インスタンスの準備

通常のAmazon EC2インスタンスを構築する場合と同じく、EC2＞インスタンス＞インスタンスの起動を選択します。

AMIやインスタンスタイプの選択も、通常と同様になります。

通常と異なるのは、「高度な詳細」でCPUオプションを選択し、「ネストされた仮想化」を「有効」に選択します。

あとは通常通りEBSのサイズや、VPCやセキュリティグループの設定を行い、インスタンスの起動を行います。

起動できたら、Amazon EC2インスタンスのプライベートIPv4アドレスを確認します。

今回は、VPC内のプライベートサブネットを選択していますので、プライベートIPv4アドレスが付与されています。

Amazon EC2インスタンス上でWSL2のインストールとUbuntu VMの構築

ここから先は、Amazon EC2インスタンス上での作業となりますのでRDPのクライアントや、Fleet Managerなどを使ってAmazon EC2インスタンスに接続します。

インスタンスに接続できたら、PowerShellを「管理者で実行」で起動し、wsl --installコマンドを実行します。

無事にインストールが終わると、このような状態になります。

設定を反映させるため、一度OSの再起動を行い、再度接続します。

再接続を行ったら、wsl.exe –list --onlineでインストール可能なOSの一覧を取得します。

一瞬Amazon Linux 2023があることを期待したのですが、残念ながらありませんでした。今回は特に指定がないため、デフォルトのUbuntuをwsl ~コマンドでVMを起動し、IPアドレスの設定を確認します。Ubuntuの場合はip aコマンドで確認します。

すると、”172.19.255.80/20”というVPCとは異なるネットワークのプライベートIPアドレスが表示されます。これはWSL2の正常な挙動で、Hyper-V上に仮想スイッチが構築され、仮想NICがVMに接続されます。Windows側にも仮想NICが接続され、VMから外部への通信時に仮想NICでNAPTされるようになります。また、外部からVMへの通信を行う際には、Windows側でポートフォワーディングの設定を行う必要があります。

次に、Windows側のネットワーク設定も確認してみます。ipconfigコマンドの実行結果は次の通りです。

AWSのENA AdapterのNICと、WSLで使われる仮想NICの二つが見えるようになります。

ここまでの状態をまとめると、次のようになります。

通信の仕組みは、通常のWSLの通信の仕組みと変わらないように見えます。

VMのルーティングテーブルを確認してみます。

Windows側の仮想NICを向いていることがわかります。

次にVMから外部へのTraceRouteを試してみます。

Amazon EC2インスタンスのENAへのTraceRoute

外部IP（8.8.8.8：GoogleのDNS）へのTraceRoute

こちらも、WSLの構成の想定通りに動いていることが確認できました。

Amazon EC2インスタンス上でHyper-Vのインストールと起動

次に、Hyper-Vを有効化してみます。こちらは、通常のHyper-Vの有効化と同じ手順で実行します。“Add Roles and Features Wizard”でHyper-Vにチェックを入れます。

NICの選択を求められたら、Amazon ENAを選択します。

インストールが完了したら、OSを再起動して再接続します。

Hyper-V Managerが無事起動すれば、インストールは完了です。

以降はHyper-Vの手順に従って、VMや仮想スイッチ、仮想ストレージを設定します。OSインストールも同様に設定を行うことができます。

AWS環境でのネスト仮想化についてNTT東日本のクラウドエンジニアがご相談にお応えします。ぜひお気軽にお問い合わせください。

まとめ

今回は、仮想EC2インスタンス上にネストされた仮想化を使用して、WSLとHyper-Vのインストールと起動を行ってみました。もともとこうだったのではないか？と思うくらいスムーズに起動できたことと、このアップデートによりWSLやHyper-Vの環境をオンプレミスで利用していた方にもAWSが使いやすくなったように思えます。本コラムで取り上げた利用シーン以外でも使いどころが出てきそうなアップデートだと思いました。

NTT 東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供を行っております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

• Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。