Amazon EC2で入れ子の仮想化がサポートされたのでWindows Serverでいろいろ試してみた
しばたです。
先日第8世代のEC2インスタンスタイプにおいて入れ子の仮想化(Nested Virtualization)がサポートされました。
このアップデートを受けてWindows Server EC2でできる事・できない事について調べたので本記事で共有していきます。
免責事項
Microsoftライセンスの話をするのでいつも通り免責事項を最初に。
今回に関しては裏取りできる情報が少なく、正直なところ記事の内容にそこまでの自信がありません...
Microsoftライセンス上問題になりうる点があることだけでもご認識いただければと思います。
Microsoftライセンス周りのはなし
Windows Serverの機能において入れ子の仮想化はサポートされており[1]、これが利用者自身がハードウェアを保有するオンプレミス環境であればライセンス的にも話は単純です。
EC2にも採用されているコアライセンスのDatacenter Edition[2]であれば同一ハードウェア内のゲストOSとして無制限のWindows Serverが実行可能です。
しかしながら、パブリッククラウドであるAWSではSPLA契約に基づいて AWS提供のサービスをユーザーが利用する 形になります。
クラウド環境では原則としてオンプレミス向けのライセンスは使えず[3]、オンプレミス向けのライセンスを使うにはライセンスモビリティの行使によりBYOLする必要があるのですがWindows Server OSはライセンスモビリティの対象外です。
このためユーザー自身が保有する(オンプレミス向け)Windows OSライセンスを使ってWindows Server EC2上に入れ子の仮想マシンを作ってはいけません。
5.Microsoft Windows クライアントのオペレーティングシステム、デスクトップアプリケーション製品 (Microsoft Office など)、Microsoft Windows Server オペレーティングシステムは対象外です。 AWS でのこれらのプログラムのその他のオプションをご覧ください。
- ライセンスモビリティ より引用
では「AWSが提供する機能を使えば良いのか?」という話になりますが、少し考えるだけでも
- AWS提供のライセンス認証サーバーを使わずにWindows Server仮想マシンを本番利用するにはインストールメディアとライセンスキーが必要になるが、ライセンスキーは決してAWSから提供されない
- AWS提供のEC2 Windows Server向けライセンス認証サーバーは
169.254.169.250,169.254.169.251となるが、入れ子の仮想マシンからアクセスする方法が提供されていない - EC2の料金体系的にも入れ子のWindows Server仮想マシンを利用できてしまうと不当にライセンス費用が安くなってしまう
といった懸念点があるので実現不可能でしょう。
このためWindows Server on Windows Server EC2は「技術的にはできうるがライセンス上不可」という扱いになるはずです。
(なお、Windows 11といったクライアントOSは元々AWSの共有ハードウェア上での利用が禁止されています)
SPLA契約下においてもHyper-V自体を利用する事は許可されているので、例えばWSL2やLinux on Windows Server EC2といったライセンスの懸念が無いOSを入れ子の仮想化で扱うことは問題ありません。
余談1 : Hyper-V分離コンテナの扱いが謎
Windows Serverのコンテナは「プロセス分離」と「Hyper-Vによる分離」の二種類存在します。
プロセス分離のコンテナに関してはSPLAのサービス利用者が守るべき規約となるServices Provider Use Rights (SPUR)において
Windows Server 2025 Standard および Datacenter での、Hyper-V による分離を使用しない Windows Server コンテナーの使用
お客様は、ライセンスを取得したサーバーで、Hyper-V による分離を使用しない Windows Server コンテナーとしてインスタンス化された任意の数の OSE を使用することができます。
と、無制限の利用が許可されています。[4]
さらに用語集において
Hyper-V による分離を使用する Windows Server コンテナー (以前の Hyper-V コンテナー) とは、1 つ以上の Windows Server コンテナーをホストするために 1 つの仮想オペレーティング システム環境を利用する Windows Server のコンテナー テクノロジの 1 つです。 1 つ以上の Windows Server コンテナーをホストするために使用される Hyper-V による分離インスタンスはそれぞれ、1 つの仮想オペレーティング システム環境と見なされます。
と、Hyper-V分離によるコンテナは1インスタンスごとに1つのOS環境として扱うものと定義されています。
このためライセンス的にはWindows Serverコンテナの扱いが明確なのですが、
- コンテナの利用時にOSのインストールメディアやライセンスキーは不要
- コンテナの利用にはライセンスキーによるアクティベーションが発生しない
と、技術的な制約が緩くその気になれば誰でも簡単に利用できてしまいます。
AWSサービス側でHyper-V分離によるコンテナの利用が許可されているかは明記されておらず、EC2上でこれを使って良いかは不明です。
余談2 : Windows Server 2025 Datacenter Azure Edition の特例
MicrosoftではAzure向けに専用の「Datacenter Azure Edition」を提供しています。
このうちWindows Server 2025 Datacenter Azure Editionだけ
2. Datacenter: Azure Edition は、入れ子になったホストまたはゲストとして使用可能
と、入れ子の仮想化でのゲスト利用を明示的に許可しています。
逆に言えばAzureを含めたパブリッククラウド環境において、Windows Server 2025 Datacenter Azure Edition以外のバージョンとエディションでは入れ子の仮想化でのゲスト利用は許可されていないと読み取ることができます。そうではなく「明記されていない以上グレーである」とも言えますし、これ以上深く追及することはできない+その気も無いので本記事ではここまでにしておきます。
AzureのWindows Server 2025だけ特例が存在することを覚えておけば良いでしょう。
Windows Server EC2インスタンスに関わる技術的制約など
EC2の入れ子の仮想化に関する技術的な詳細は以下のドキュメントに記載されています。
ここからWindows Serverに関わりそうなものをいくつかピックアップすると、
- 現時点で入れ子の仮想化をサポートするインスタンスタイプは C8i, M8i, R8i のみ
- 現時点でサポートされるハイパーバイザー(L1ハイパーバイザー)は KVM, Hyper-V のみ
- 入れ子の仮想化を有効にしたWindows Serverインスタンスには以下の制限がある
- Credential Guardは非サポート
- ハイバネーションは非サポート
- 最大CPU数は192まで
となります。
いくつかの制約はあるもののHyper-Vを使うこと自体はAWSとしてもサポートされる範囲なので安心して利用できるかと思います。
試してみた
ここからは実際に動作確認してみます。
0. 検証環境
私の検証用AWSアカウントの東京リージョンに用意したVPC内にm8i.xlargeの日本語Windows Server 2025 EC2インスタンス(AMI : ami-097115014964b1c33 Windows_Server-2025-Japanese-Full-Base-2026.02.11)を1台用意しました。


EC2の構築方法は割愛しますが、必ず「ネストされた仮想化」設定を「有効」に設定します。
1. WSL2
最初にWSL2を有効にしてみます。
Windows Server 2025ではwsl --installコマンドを実行して再起動するだけでWSL2が利用できます。
# 要管理者権限
# ※ wsl --install コマンドが使えるのはWindows Server 2022から
wsl --install
# OS再起動
Restart-Computer

今回一回のコマンドでディストリビューションまで入らなかったので、再起動後にもう一度wsl --installを実行しました。
# OS再起動後にもう一度 wsl --install
wsl --install

無事WSL2の初期設定が終わり良い感じに利用できました。

EC2でWSL2があっさり動作する図
WSL2の利用にはライセンス上の制約も無いですし、これは非常に嬉しいですね。
2. Hyper-V 仮想マシン
次にHyper-Vの機能を有効にして適当な仮想マシンを作成してみます。
今回はPowerShellからコマンドを実行して機能を有効にしています。
# PowerShellからHyper-Vの機能をインストール
Install-WindowsFeature Hyper-V
Install-WindowsFeature RSAT-Hyper-V-Tools -IncludeAllSubFeature
# 再起動
Restart-Computer

インストール後Hyper-Vマネージャーを起動するとこんな感じです。

詳細は割愛しますがここから以下のドキュメントを参考にインターネットアクセス用のNATネットワークを作ってやり、
ライセンス上の問題が無いUbuntu Desktopの仮想マシンを作成してやるとこんな感じです。

3. Hyper-V分離コンテナ
最後にHyper-V分離コンテナを試してみます。
次のドキュメントに従ってDocker Community Editionをインストールします。
GitHubからインストールスクリプトをダウンロードして実行してやればOKです。
# Docker Community Editionをインストールするスクリプトのダウンロード
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1
# インストールスクリプトの実行
.\install-docker-ce.ps1
今回の場合あらかじめHyper-Vの機能と管理ツールをインストール済みなのでその辺は省略していますが、新規に環境を作る場合は適宜Hyper-Vのインストールも行ってください。
今回はVer.29.2.1がインストールされました。

この状態でバージョン互換の無いイメージをプロセス分離で起動するとエラーとなります。
# 互換性の無いWindows Server 2019イメージを起動
# プロセス分離だとOSバージョン非互換でエラーに
docker run --isolation=process mcr.microsoft.com/windows/servercore:ltsc2019 cmd /c ver
docker: Error response from daemon: container 5c10fbafa686466d45521ead23cfc26015013bd698d4cd87922b9f68595c5d63 encountered an error during hcs::System::Start: failure in a Windows system call: The container operating system does not match the host operating system. (0xc0370101)

これがHyper-V分離だとエラーなくコンテナを起動できます。
# Hyper-V分離だと古いバージョンのコンテナを起動できる
# 簡単に実行できてしまうがライセンス的に怪しいので要注意
docker run --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2019 cmd /c ver

OSバージョンが 10.0.17763.8389 (Windows Server 2019)と古いイメージを起動している
先述の通りこれはライセンス的に問題となる可能性があるので要注意です。
今回はあくまでも動作チェックのために敢えて起動しましたが、実際の運用でHyper-V分離コンテナを利用可能かは不明である点は繰り返し述べておきます。
最後に
以上となります。
一応本記事に書いた不明点についてはAWSサポートに問い合わせたりもしているのですが、その結果については公開不可能だと思うので気になる方は個別に問い合わせると良いでしょう。
ライセンスの懸念が無い環境であればWindows Server EC2であっても問題無く入れ子の仮想化が使えるので適切にご利用ください。
Windows Server 2016からのサポートです ↩︎
過去にはStandard EditionのEC2(Windows Server 2012と2012 R2)もありましたが、現在サポートされているWindows Server EC2 OSのエディションは全てDatacenter Editionです ↩︎
Windows Server 2025から登場した従量課金ライセンス(PAYG)については本記事では考慮しません。これをオンプレミス向けと言って良いのかも微妙ですし... ↩︎
現バージョンのSPURではWindows Server 2025に対する記述となっていますが、古いバージョンのSPURではWindows Server 2022等旧バージョンに対する許可も明記されています ↩︎






