ハクソク

世界を動かす技術を、日本語で。

AWSがネストされた仮想化のサポートを追加

102日前原文(github.com)

概要

AWS SDK for Go v2が 2026年2月12日 にアップデート。 EC2サービスモジュールが v1.288.0 へ更新。 新機能として 仮想EC2インスタンス内でのネスト仮想化 をサポート。 その他の依存パッケージに大きな変更なし。 主な変更点と新機能の概要を以下にまとめる。

AWS SDK for Go v2: 2026年2月12日リリースハイライト

  • リリース日 ：2026年2月12日
  • 対象モジュール ：github.com/aws/aws-sdk-go-v2/service/ec2 v1.288.0
  • 主な新機能 ：Nested Virtualization（ネスト仮想化）のサポート
    • 仮想（非ベアメタル）EC2インスタンス 内で 入れ子VM の起動が可能
    • 従来はベアメタルインスタンスのみで利用可能だった機能
    • テスト、開発、CI/CD環境などでの 柔軟な仮想化 運用が可能
  • 他の依存パッケージ ：バージョン変更なし、安定運用を維持

ネスト仮想化機能の詳細

  • Nested Virtualization ：仮想マシン内でさらに仮想マシンを起動する技術
    • これまでは物理サーバ（ベアメタル）でのみ利用可能
    • 今回のアップデートで 仮想EC2インスタンス 上でもサポート
  • 主な用途
    • 開発・テスト環境の構築
    • 複雑なCI/CDパイプラインの仮想化
    • セキュリティ検証やサンドボックス環境の実現
  • 利用方法
    • AWS SDK for Go v2の EC2 v1.288.0 以降でサポート
    • 対応インスタンスタイプや制約事項は AWS公式ドキュメント を参照

まとめ

  • AWS SDK for Go v2 の最新版で EC2の柔軟性が向上
  • Nested Virtualization のサポートにより、開発・テスト用途での選択肢拡大
  • 今後の運用やシステム設計で 仮想インスタンスの活用幅 が広がる見込み

Hackerたちの意見

メインのSDKにネストされた仮想化のサポートが追加されたよ。us-west-2リージョンでは、「ネストされた仮想化」オプションがすでに見えていて、新しいM8id、C8id、R8idインスタンスタイプで使えるんだ。これは、私が取り組んでいるE2BのようなマイクロVMサンドボックスソリューションにとって、すごく大きなニュースだね。

これが大事な理由を誰か説明してくれない？数年前にネストされた仮想化をいじってみたけど、PoCとかその手のもの以外では後退だと思ったんだ。自分は仮想化機器が足りなくなったことがないから、PoCをやる必要もなかったし。

└

孤立性が高まるのがいいね。今はKata Containersやgvisor、FirecrackerみたいなVMベースのコンテナ化ソリューションがたくさんあるし。Kataを使うと、Kubernetesのポッドが孤立したVM内で動くんだ。それに、EC2インスタンス間でアプリのライブマイグレーションができるようになって、持続的なワークロードがあるときのメンテナンスが楽になるよ。セキュリティのためだけじゃなくて、ワークロードがマシンを壊す可能性もたくさんあるから、再起動や交換が必要になることもあるし（例えば、間違ったタイミングでマウントされたXFSファイルシステムを持つEBSボリュームを切り離すとか）。でも、私が一番欲しかったのはCI/CDシステムで、EC2でシステムイメージを一般的にビルドしてテストするのがいつも面倒だったんだ。他のサードパーティ製のアプライアンスもそのままEC2で動かせるようになるし。でも、ほとんどの他の実行環境はこれを提供してるのに、EC2はベアメタルインスタンスタイプでしか提供してこなかったのがもどかしい。10年以上前にEC2がXenを使っていたときは理解できたけど、Nitroの開始以来KVMを使っているんだから。

└

これで、全体のベアメタルインスタンスを払わなくても、安いAWSインスタンス内でVMを実行できるようになったよ。ネットワークシミュレーションみたいな、QEMUを使ってネットワークハードウェアをエミュレートするような用途に便利だね。

└

もしVMを作成するワークロードがあるなら、今はそのワークロードをEC2で実行できるようになったから、ベアメタルやネストされた仮想化を許可する他のプロバイダーを使わなくてもよくなったね。そういうワークロードはたくさんあるよ。一例を挙げると、CIジョブをホストするためにVMを立ち上げるビルドシステムのテストとかね。

└

ネストされた仮想化を使うと、ネストされたVM同士でクラウド内でマルチキャストができるよ。でも、クラウド内のVM間ではマルチキャストはできない。要するに、HyperVとかで小さなLANを設定する感じだね（私はHyperVでしかやったことないけど）。

└

これでやっとAWSインスタンスでGNS3みたいなネットワークシミュレーターが動かせるようになるといいな。

└

自分のVMで色々やりたい時に、ベアメタルマシンに余分なお金を払いたくないって感じかな。自分のハードウェアで使う理由は特にないけど、クラウドの場合は、サーバー全体の料金を払うほどの作業がいつもあるわけじゃないからね。

これは大きなニュースだよ。AWSのVM内でFirecrackerや他のマイクロVMを実行できるようになったから、高価なAWSのベアメタルインスタンスを使わなくて済むんだ。GCPはしばらく前からネストされた仮想化を提供してたしね。

└

こういうのって、パフォーマンスにどれくらいの影響があるの？

└

このコメントがここにあるといいなと思ってた。FirecrackerとマイクロVMはいいユースケースだし、簡単にテストや開発ができるのも嬉しいポイントだよ。ネストされた仮想化は色々な意味を持つからね。フルVMだけじゃないんだ。

└

Azureもネストされた仮想化をしばらく前から提供してるよ。昔はクラウドでHyper-Vを使ってたし。

└

OCIはIntelでサポートしてるよ。AMDでも動くのは知ってるけど、公式にはまだサポートしてないと思う。AMDのパフォーマンスはIntelよりも落ちるし、前に見た時はそうだった。

└

高いAWSのVMを使うより、高いAWSのベアメタルイメージを使った方がいいよ。AWSがどれだけ高いか、みんな気づいてる？

自分が正しかったって感じだね :)。数年前にGCEでネストされた仮想化をうまく動かすために、素晴らしいお客さんと一緒にたくさんの努力をしたから、AWSがやっと追いついてきたのを聞いて嬉しいよ。人に別のことをやるように言うこともできるし、別の自然な解決策があるかもしれないけど、時には操作の均一性やコントロールを持つために、ピークパフォーマンスを犠牲にすることもあるんだよね。

これって、Azureが「Boost」SKUでOpenShift仮想化を始めることと関係あるのかな？VMWareの顧客がOpenShift Virtに移行してるみたいだし、AzureのCPU/メモリのオーバーヘッドはフルロード時で約10%に達するらしいけど…でもHyper-Vはその辺りで結構頑張ってるよね。NitroがKVMのフルパススルーを含んでるかどうかはわからないけど、ここで有利になるかもしれないね。

└

Azure？OpenShift？「君のことなんて全然考えてないよ。」 — マット・ガーマン多分

└

Azureはしばらくネストされた仮想化を提供してるけど、OpenShiftと関係あるかもしれないね。でも、AzureでOpenShiftを動かすことはしばらく前からできたよ。特定のSKUでAzureのHyper-Vを使ってたこともあったし。

ネストされた仮想化は、8世代のIntelベースのインスタンスタイプ（c8i、m8i、r8i、そしてそのフレックスバリアント）でのみサポートされています。ネストされた仮想化が有効になると、インスタンスのためにVirtual Secure Mode（VSM）が自動的に無効になります。

LinuxカーネルのネストされたVMX仮想化って、ほんとにそんなに安定してるの？技術的な詳細は、ほとんどの人が思ってるよりもずっと複雑だよ。単一レベルのVMX仮想化は比較的簡単だけど、VMCSの設定やエグジットの処理など、いろいろな詳細を扱わなきゃいけない。ネストされた仮想化は全く別の話で、レベルだけじゃなくて、ハードウェアが通常やることや、レベル間の遷移中の内部状態の管理も必要になるからね。LKMLは、非常に鋭い貢献者たちがその仕組みを理解しようと議論してるスレッドで溢れてる。Amazonがその機能をオンにするのは一つのことだけど、100%完璧に動くのはまた別の話だよね…

└

もう15年近く前からあって、過去10年間でいくつかのプロバイダーが本番環境で使えるくらい安定してる（GCPとAzureは2017年に導入）。AWSは、自社のスタックをたくさん作っちゃったから、オープンソースのソリューションを取り入れて貢献するのが遅れちゃったんだよね。

└

確かに心配な点だけど、これは2017年からGCPとAzureで静かに本番安定してるから、もう8年以上クラウドスケールで使われてるよ。君が言ってるLKMLの議論は、主にエッジケースの珍しいVMX機能（ネストされたAPIC仮想化やSGXパススルー）についてのもので、FirecrackerやKataが実際に使うコアのネスティングパスについてではないんだ。もっと興味深いのは、AWSがこれを8世代のIntelインスタンス（c8i/m8i/r8i）に制限していること。彼らはVMCSシャドウイングのために、これらのチップの特定のマイクロアーキテクチャの改善を利用している可能性が高い。信頼性を保証できるハードウェア世代を選んで、広く有効にするのではなく、古いシリコンのエラッタに対処しているんだ。これがクラウドプロバイダーに求められる慎重なエンジニアリングアプローチだよ。

これで、CIで通常のランナーを使ってAndroidエミュレーターで自動テストを実行しやすくなるね。そのためだけにベアメタルインスタンスを扱うのは面倒だったから。

マイクロVMを使ってる人には嬉しいニュースだね。「うちはAWSしか使わない」っていうのが、うちのサービス（スライサーサービスやサンドボックス、自ホストのGitHubランナー）には問題だった。もし待てない人がいたら（今はあまり情報がないみたいだし）、Ant GroupのKVM-PVMパッチについて詳しい手順を書いたよ。バックグラウンドサーバーやタスクにはまあまあのパフォーマンスだけど、K8sクライアントでのカーネルやGoの複雑なビルドでは最大50%落ちることもある。DIYの詳細オプションはこちら: https://blog.alexellis.io/how-to-run-firecracker-without-kvm... 完全に動作する、事前にビルドされたホストとゲストのカーネルとrootfs: https://docs.slicervm.com/tasks/pvm/ これが利用可能になったら、すぐにテストして比較するつもりだよ。PVMアプローチと比べて、少しは加速されてるといいな。これらのパッチがLinuxカーネルにマージされるかどうかはまだ不明だけど、知ってる人がいたらリンク教えてほしい。Azure、OCI、DigitalOcean、GCEはすべてネストされた仮想化をオプションとしてサポートしてて、多少のパフォーマンス低下はあるけど、テストや探索がすごく簡単になるよ。Hetznerのベアメタルは今、最大350ユーロのセットアップ費用がかかるけど、0セットアップ費用のものも見つけられるけど、だいたい古い機材だよ。編集: これ、見出しほど良さそうには見えないね…インスタンスのオプションがちょっと限られてる。誰かがここでさらに情報を見つけたみたいだよ: https://x.com/nanovms/status/2022141660143165598/photo/1

└

Hetznerのベアメタルは今、最大350ユーロのセットアップ費用がかかるけど、0セットアップ費用のものも見つけられるけど、だいたい古い機材だよ。ここで何にお金を払ってるのか分からないんだけど、ネストされた仮想化は普通のものと比べてハードウェアの追加設定が必要ないよね…それとも、HetznerはBIOSで普通の仮想化オプションをオンにするのに350ユーロを要求してるってこと？

これはGo SDKを使ってる時だけの話？