AWS nested virtualization, finally on virtual EC2
For years, AWS customers who wanted to run a hypervisor inside an EC2 instance – to host VMs inside VMs were forced onto expensive bare‑metal instance types. With the 2026 release of nested virtualization on 8th‑gen Intel virtual EC2 instances, AWS now lets you run KVM or Hyper‑V inside standard C8i, M8i, R8i and related families without touching bare metal.
In practice, this means you can build full lab environments, microVM platforms, and emulator farms using normal virtual instances that fit your price/performance envelope instead of specialized hardware hosts.
What nested virtualization actually is
Nested virtualization lets you run a hypervisor (for example KVM or Hyper‑V) inside an EC2 instance, and then create additional virtual machines inside that guest. AWS documentation describes a three‑layer architecture: the physical AWS infrastructure and Nitro hypervisor at level L0, your EC2 instance running its own hypervisor at L1, and one or more nested VMs at L2.
The Nitro System passes processor‑level virtualization extensions like Intel VT‑x into the guest, so your L1 hypervisor can use hardware virtualization to run L2 VMs with reasonable performance.
Supported EC2 instance families
Nested virtualization is currently supported only on specific x86 instance types, primarily 8th‑generation Intel families. AWS lists support for C8i, M8i, R8i, their “flex” variants, and disk‑optimized siblings like C8id, M8id, R8id, as well as some 7th‑gen Intel types such as C7i, M7i, R7i, C7i‑flex, M7i‑flex, X8i, and I7i.
Graviton (ARM) instances are not currently supported, so any nested virtualization design today has to target these Intel families. According to AWS, there is no additional EC2 surcharge for enabling nested virtualization itself, you pay the usual instance pricing.
From bare metal only to virtual instances
Before this update, the only officially supported way to run nested VMs on EC2 was to use bare‑metal instances, which expose the physical hardware directly and tend to be significantly more expensive. Many teams resorted to EC2 Mac instances and other low‑end bare‑metal types as a workaround just to get VT‑x access for test labs and microVM experimentation.
With nested virtualization on virtual instances, AWS now exposes the same processor features via Nitro to standard EC2 types, so you can choose instance sizes based on workload requirements instead of being locked into bare metal purely for hardware virtualization.
Supported hypervisors and tooling
AWS explicitly supports KVM and Hyper‑V as the L1 hypervisors inside nested‑virtualization‑enabled EC2 instances. That covers the most common Linux and Windows workflows, where you might be running QEMU/KVM on Linux hosts or Hyper‑V on Windows Server or Windows workstations.
In practice, this unlocks a wide toolchain: Docker Desktop, Windows Subsystem for Linux 2 (WSL2), Android Studio emulators, Firecracker, Kata Containers, and other microVM or VM‑based runtimes that rely on hardware virtualization extensions.
Key use cases for DevOps and platform teams
AWS and early adopters highlight several concrete use cases that nested virtualization on 8th‑gen EC2 enables.
- Mobile app CI and emulator farms
You can run Android emulators in CI/CD pipelines or large device farms inside nested VMs, without paying for bare‑metal instances or on‑prem hardware. - Automotive and hardware simulation
In‑vehicle hardware simulations and automotive software validation can run in fully virtualized testbeds, with nested hypervisors hosting different firmware or OS images as separate VMs. - Developer workstations in the cloud
Windows workstations with WSL2, Docker Desktop, and Hyper‑V based tooling can be moved into EC2 while retaining their virtualization‑dependent workflows. - MicroVM platforms and multi‑tenant lab environments
Platforms based on Firecracker or similar microVM technologies can now run on standard EC2 virtual instances, instead of needing bare metal, which is a big deal for multi‑tenant lab setups and sandbox services.
Enabling nested virtualization on EC2
AWS exposes nested virtualization as a CPU option on supported instance types. When launching a new instance via the API or CLI, you can set the NestedVirtualization=enabled flag in CpuOptions on compatible Intel families like c8i, m8i, or r8i.
For existing instances, AWS documentation notes that you can turn on nested virtualization after stopping the instance, provided the instance type supports the feature.
Once the instance is up, you install and configure KVM or Hyper‑V as usual, and then create L2 VMs using your preferred tooling (libvirt, virt‑manager, Hyper‑V Manager, etc.).
Limitations and caveats you need to know
There are a few important constraints and trade‑offs to factor into your designs.
- Performance and latency overhead
AWS explicitly recommends that performance‑sensitive workloads that require hardware virtualization still consider bare‑metal instances, as nested virtualization adds extra overhead through multiple hypervisor layers. - Windows‑specific constraints
On Windows instances, enabling nested virtualization automatically disables Virtual Secure Mode (Credential Guard), and hibernation is not supported. There is also a CPU‑count limit – nested virtualization is not supported on certain very large Windows configurations, such as somem8i.96xlargeshapes. - Security responsibilities
AWS continues to handle “security of the cloud” (Nitro, host isolation, and physical infrastructure), but customers are responsible for “security in the cloud”. That includes the guest OS, the L1 hypervisor, L2 VMs, and everything running inside those virtual machines. - Instance type and region coverage
At launch, nested virtualization is available in all commercial regions on the listed Intel instance families; other architectures like Graviton are not supported yet. You must choose a matching instance type and region or yourNestedVirtualizationflag will have no effect or won’t be present at all.
Architectural patterns unlocked by nested virtualization
From an architectural point of view, nested virtualization on virtual EC2 closes a gap that has existed between AWS and other clouds that already supported VMs‑inside‑VMs on standard instance types. It means you can now keep complex virtualization‑dependent tooling – emulator farms, microVM platforms, and full lab environments – centralized on EC2 without bespoke bare‑metal clusters.
You can design patterns like “hypervisor hosts as pets, nested VMs as cattle”: use C8i/M8i/R8i instances as L1 hypervisor nodes, spin up L2 VMs on demand for ephemeral dev/test environments, and tear them down as easily as containers. For organizations investing in multi‑tenant sandbox platforms or heavy QA pipelines, this drastically reduces the friction of moving those workloads into AWS.
How Cloudwork can help you adopt this feature
At Cloudwork, we already work with teams that want disposable lab environments, complex CI pipelines, and sandboxed domain‑intelligence workloads on AWS. Nested virtualization on 8th‑gen EC2 gives us a more flexible tool for those designs.
We can help you:
- Identify which of your current bare‑metal or on‑prem hypervisor workloads can move to nested virtualization on C8i/M8i/R8i.
- Design safe multi‑tenant architectures for microVM platforms and emulator clusters with appropriate isolation and observability.
- Integrate nested virtualization into your Terraform and CI flows so that lab environments and test benches become fully reproducible.
If you’ve been avoiding nested virtualization on AWS because bare‑metal instances were too costly, this 8th‑gen EC2 update is the moment to revisit that decision, and we can work with you to make sure your architecture, security model, and performance profile are ready for VMs inside VMs in the cloud.
