Working with Nested Virtualization on Amazon WorkSpaces

Introduction

Developers and engineers increasingly rely on tools that require hardware virtualization support – Docker Desktop, WSL2, Android Studio emulators, and AI agents such as Claude Cowork. Until now, using these tools on a virtual desktop meant choosing between self-managed infrastructure or asking users to work on local hardware outside of your managed environment.

Nested virtualization on Amazon WorkSpaces Personal and Amazon WorkSpaces Core bundles solves this. Your WorkSpaces now expose processor-level virtualization extensions to the guest OS, enabling Hyper-V and Kernel-based Virtual Machine (KVM) workloads at no additional cost.

This post explains what nested virtualization is, what it enables, and what you need to know to get started. For step-by-step instructions on enabling nested virtualization – including console, CLI, and API guidance – see:

• Nested virtualization for WorkSpaces Personal
• Modify a WorkSpace in WorkSpaces Personal

What is nested virtualization?

In a traditional cloud desktop, the underlying EC2 instance already runs inside a hypervisor. “Nested” virtualization means enabling a second level of hypervisor inside that instance. At the hardware level, this exposes processor virtualization extensions to the guest operating system, which allows it to run its own virtual machines.

On Windows, this enables Hyper-V – the Windows hypervisor that underpins WSL2, Docker Desktop, Windows Sandbox, and other virtualization-based features. On Linux, this enables KVM, which supports QEMU (Quick Emulator), Docker, and other Linux virtualization tools.

For more information about how nested virtualization works at the infrastructure level, see Use nested virtualization to run hypervisors in Amazon EC2 instances in the Amazon EC2 User Guide.

What’s unlocked

Here are some example capabilities that were previously unavailable on WorkSpaces and are now enabled with nested virtualization:

Windows Subsystem for Linux 2 (WSL2)

WSL2 runs a full Linux kernel inside a lightweight Hyper-V virtual machine, delivering complete Linux compatibility for developer tools. With nested virtualization enabled, your WorkSpaces users can install WSL2 with a single command:

wsl --install

After a reboot, users can work with Linux distributions – Ubuntu, Debian, Fedora, and others – directly within their managed Windows WorkSpace.

For more information, please see Microsoft’s documentation on WSL.

AI agents with sandboxed execution

Enterprise teams increasingly use AI agents that autonomously perform tasks on their desktop – organizing files, drafting documents, running commands, and managing workflows. Some of these tools – including Anthropic’s Claude Cowork – isolate execution inside a Hyper-V virtual machine for safety. This architecture requires hardware virtualization at the processor level, which previously made them incompatible with virtual desktops.

With nested virtualization, these tools now work within your managed WorkSpaces environment.

Docker Desktop

Docker Desktop on Windows uses the WSL2 backend (or Hyper-V directly) to run Linux containers. Engineering teams can now run containerized development environments on their WorkSpaces without additional infrastructure.

For more information, please see Docker’s Windows installation instructions. The default “WSL 2 backend, x86_64” steps can now be used with WorkSpaces, using the new nested virtualization capability.

Android Studio emulators

Mobile developers using Android Studio require hardware-accelerated emulation. With nested virtualization, the Android Emulator uses Hardware Accelerated Execution Manager (HAXM) on Windows or KVM on Linux to run at near-native speed.

QEMU and general-purpose virtualization

For teams that maintain custom VM images or run embedded systems tooling, QEMU with KVM acceleration is now available on Linux WorkSpaces.

Supported configurations

Prerequisites:

• The WorkSpace must use the DCV protocol or Bring Your Own Protocol (BYOP). WorkSpaces using the PCoIP protocol are not supported.
• The WorkSpace must use a non-Graphics (non-GPU) bundle.
• The WorkSpace must not use the Value bundle size.
• The WorkSpace must run a supported operating system. Windows Server 2016, Windows 10, and Amazon Linux 2 are not supported.

Recommendation: Use Power (4 vCPU) or higher bundle sizes. Hypervisors and nested virtual machines consume additional compute resources. For the best experience with Docker Desktop or WSL2 workloads, we recommend Power or larger bundles.

Considerations

Before you begin using nested virtualization, consider the following:

• Credential Guard / Virtualization-Based Security (VBS) – When nested virtualization is enabled on a Windows WorkSpace, Credential Guard and Virtualization-Based Security (VBS) are automatically disabled. This is consistent with the behavior documented for nested virtualization on Amazon EC2. Evaluate whether your security requirements depend on Credential Guard before enabling nested virtualization. For more information, see Credential Guard / Virtualization-Based Security (VBS) in the Amazon WorkSpaces Administration Guide.
• Security responsibilities – AWS maintains isolation between WorkSpaces via the Nitro System. Customers are responsible for securing the operating system, any nested hypervisor, nested VMs, and data within the WorkSpace.
• Performance – Nested VMs consume additional compute resources. Use Power (4 vCPU) or higher bundles for the best experience. We recommend testing your workloads with nested virtualization enabled to ensure they meet your performance requirements.

Known limitations

• AutoStop mode with Windows Server 2025 and Windows 11 24H2/25H2 – WorkSpaces with AutoStop running mode perform a full reboot instead of hibernating. Use AlwaysOn running mode if you require session persistence.
• GPU-based bundles – Not supported.
• Windows Server 2016 and Windows 10 – Not supported.
• Standby WorkSpaces – Not supported. See Multi-Region Resilience for Amazon WorkSpaces Personal.

Lifecycle behavior

The nested virtualization setting is preserved during Rebuild, Restore, and Migration operations. For the Migration option, if the destination bundle does not meet the nested virtualization prerequisites, the feature will be disabled.

Conclusion

Nested virtualization on Amazon WorkSpaces removes a long-standing barrier for developer-focused virtual desktop deployments. Your developers can now use WSL2, Docker Desktop, AI coding assistants, Android emulators, and other virtualization-dependent tools – all within the security and management boundary of a WorkSpaces deployment. And at no additional cost.

To get started, see Nested virtualization for WorkSpaces Personal in the Amazon WorkSpaces Administration Guide.

Dan is a Senior AWS Customer Success Specialist, focusing on helping customers scale and optimize end-user computing solutions. Dan also focuses on EC2, Microsoft, and Linux based workloads. Dan has been at AWS since March 2016, working with End User Compute solutions throughout. Previously, Dan has been an AWS Premium Support escalation engineer, Specialist Technical Account Manager, and Specialist Solutions Architect.

Sona is a Senior Product Manager, Technical on Amazon WorkSpaces, focusing on OS lifecycle management and foundational features such as Nested Virtualization. Sona has been at AWS since September 2024, bringing 17 years of product experience across consumer technology and enterprise software. Previously, Sona held product leadership roles shipping AI-powered consumer products and subscription platforms at scale.