AWSがネスト仮想化（nested virtualization）対応を追加 (github.com/aws) 3 ポイント 投稿者 GN⁺ 2026-02-13 | 1件のコメント | WhatsAppで共有 AWS SDK for Go v2 のアップデートにより、仮想マシン内でさらに別の 仮想マシンを実行できる機能 が追加された 新機能により、非ベアメタルの EC2 インスタンスでもネストした VM の実行 が可能になった AWS EC2 における ネスト仮想化対応の拡張 は、開発・テスト環境での 仮想化レイヤー活用度 を高める基盤になる見込み 関連記事 Geminiアプリで文書・スプレッドシート・プレゼンテーションの直接作成に対応 1 ポイント · 0件のコメント · 3 시간 전 spawn-agent: ローカルのコーディングエージェントを Vercel AI SDK のモデルのように扱うアダプター 2 ポイント · 0件のコメント · 3 시간 전 VSCodeでCopilotがデフォルトでGitの共同作成者として追加されるようになりました。 1 ポイント · 1件のコメント · 3 시간 전 バイブコーディングの幻想とAIコードの水準、そして未来 4 ポイント · 4件のコメント · 8 시간 전 Stethoscope - 製作費が2.5〜5ドルのオープンソース聴診器 1 ポイント · 1件のコメント · 8 시간 전 1件のコメント GN⁺ 2026-02-13 Hacker Newsのコメント これでAWSのVM内で Firecracker や他の microVM を直接実行できるようになり、大きな変化だ 以前はこれをやるには高価な ベアメタルインスタンス が必要だった ちなみにGCPはかなり前から nested virtualization をサポートしていた こういうコメントを待っていた。Firecracker のような microVM こそ優れたユースケースだ テストや開発環境を簡単に用意できる点も利点だ nested virtualization は必ずしも完全なVMだけを意味しない この環境での 性能低下率 がどの程度なのか気になる nested virtualization のサポートが主要SDKに追加された us-west-2 リージョンではすでに「Nested Virtualization」オプションが見えており、M8id / C8id / R8id インスタンスタイプで利用できる 私が関わっている E2B のような micro-VM サンドボックスソリューションにとっては本当に大きなニュースだ なぜこれがそんなに大きな話なのか説明できる人はいる？ 以前 nested virtualization を試したときは、PoC レベル以外ではあまり役に立たないと感じた 分離の観点で非常に有用だ Kata Containers、gVisor、Firecracker のようなVMベースのコンテナソリューションは多い たとえば Kubernetes の pod をVM単位で分離できる また、EC2 インスタンス間の ライブマイグレーション が可能になり、継続的なワークロードの保守がしやすくなる CI/CD 環境でもシステムイメージを EC2 上で直接ビルドしてテストできるようになり、はるかに便利だ GCP、VMWare、KVM などはすでにこうした機能を提供していたので、EC2 がようやく追いついたのは惜しかった これで丸ごとのベアメタルインスタンスを使わなくても、より安価なAWSインスタンスの中でVMを動かせるようになった QEMU でネットワークハードウェアをエミュレートする ネットワークシミュレーション のような作業に特に有用だ AWS はようやく 2018 年に到着した感じだ その通り、かなりありふれた話だ 私は自宅でもずっと前から libvirt で一般向けハードウェア上でこれを使っていた AWS がようやくこうした古い機能に追いついたわけだ この機能は openclaw やエージェントのようなものにも役立つだろうか 可能ではあるが、実運用なら nested virtualization ではなく nixでイメージをビルド する方式を選ぶと思う nested virtualization 環境での 性能値、特に IO 中心のワークロードでの結果が気になる 一般に nested virtualization の性能への影響がどの程度なのか気になる 多段の MMU オーバーヘッド が発生しそうだ ワークロードと実装方式によって異なる 純粋なCPU処理はほとんど影響がないが、IOは実装次第で ほとんど差がないか、非常に悪くなる可能性がある trap/vmexit のようなイベントは一段階多く経由する必要がある 記憶では、仮想化命令そのものがネストされるのではなく、外部の仮想化ハードウェアと 協調して動作 する AWS の実装がこの方式に従っているかは確信がない 実務上はおおむね 5〜15% 程度の性能低下 がある レガシーアプリ にはコストが高そうに感じる ついに来たという感じで、期待が爆発している
1件のコメント
Hacker Newsのコメント
以前はこれをやるには高価な ベアメタルインスタンス が必要だった
ちなみにGCPはかなり前から nested virtualization をサポートしていた
テストや開発環境を簡単に用意できる点も利点だ
nested virtualization は必ずしも完全なVMだけを意味しない
us-west-2 リージョンではすでに「Nested Virtualization」オプションが見えており、M8id / C8id / R8id インスタンスタイプで利用できる
私が関わっている E2B のような micro-VM サンドボックスソリューションにとっては本当に大きなニュースだ
以前 nested virtualization を試したときは、PoC レベル以外ではあまり役に立たないと感じた
Kata Containers、gVisor、Firecracker のようなVMベースのコンテナソリューションは多い
たとえば Kubernetes の pod をVM単位で分離できる
また、EC2 インスタンス間の ライブマイグレーション が可能になり、継続的なワークロードの保守がしやすくなる
CI/CD 環境でもシステムイメージを EC2 上で直接ビルドしてテストできるようになり、はるかに便利だ
GCP、VMWare、KVM などはすでにこうした機能を提供していたので、EC2 がようやく追いついたのは惜しかった
QEMU でネットワークハードウェアをエミュレートする ネットワークシミュレーション のような作業に特に有用だ
私は自宅でもずっと前から libvirt で一般向けハードウェア上でこれを使っていた
AWS がようやくこうした古い機能に追いついたわけだ
多段の MMU オーバーヘッド が発生しそうだ
純粋なCPU処理はほとんど影響がないが、IOは実装次第で ほとんど差がないか、非常に悪くなる可能性がある
trap/vmexit のようなイベントは一段階多く経由する必要がある
AWS の実装がこの方式に従っているかは確信がない