WorkSpaces nested virtualization turns off Credential Guard — the 18 August 2026 announcement never says so

Summary. AWS turned on nested virtualization for Amazon WorkSpaces Personal and WorkSpaces Core managed bundles on 18 August 2026, which finally lets Docker Desktop, WSL2, Android Studio emulators and QEMU run inside a managed cloud desktop. The What's New post lists three exclusions and calls the feature free. The Amazon WorkSpaces Administration Guide lists five exclusions, and adds two facts the announcement omits entirely: enabling nested virtualization on a Windows WorkSpace automatically disables Credential Guard and Virtualization-Based Security, and WorkSpaces on AutoStop running mode with Windows Server 2025 or Windows 11 24H2/25H2 stop hibernating — they full-reboot on timeout and lose the user's unsaved work. The feature itself costs $0. Moving 50 part-time seats from AutoStop to AlwaysOn to get session persistence back costs about $910 a month in US East (N. Virginia) and about $1,930 a month in Asia Pacific (Mumbai) on the Windows Power bundle, as of 22 August 2026.

What shipped on 18 August 2026

Nested virtualization exposes processor-level virtualization extensions to the guest operating system, so a hypervisor running inside the WorkSpace can create its own virtual machines. On Windows that means Hyper-V, which underpins WSL2, Docker Desktop and Windows Sandbox. On Linux it means KVM, which QEMU and the Android emulator use for hardware acceleration.

Dan Garibay, senior AWS customer success specialist, and Sona Chandramohan, senior product manager, technical, on Amazon WorkSpaces, wrote in the AWS Desktop and Application Streaming blog on 20 August 2026: "Nested virtualization on Amazon WorkSpaces removes a long-standing barrier for developer-focused virtual desktop deployments."

That is fair. Before this, a mobile team running Android Studio on a managed desktop had no hardware-accelerated emulator, and a backend team had no Docker Desktop. The gap pushed developers onto local hardware outside the managed boundary, which is exactly the outcome a virtual desktop programme exists to prevent.

The problem is not the feature. It is that the announcement and the reference documentation do not agree on what you are switching on.

Three exclusions in the announcement, five in the docs

The AWS What's New post, posted 18 August 2026, states: "Nested virtualization is not supported on GPU bundles, the PCoIP protocol, or Amazon WorkSpaces based on Windows Server 2016 and Windows 10."

The administration guide page Nested virtualization for WorkSpaces Personal adds two more prerequisites that the announcement leaves out, and one more known limitation:

The Value bundle omission matters for cost-led rollouts, because Value is the cheapest tier and the obvious place a finance-constrained team would start a pilot. The Standby WorkSpaces omission matters more: Standby is the multi-Region resilience mechanism for WorkSpaces Personal. If your disaster-recovery posture depends on Standby WorkSpaces, nested virtualization and that posture are mutually exclusive, and the announcement gives you no way to know it.

The Credential Guard shutdown

This is the one to escalate internally before anyone touches the console.

The administration guide page Credential Guard / Virtualization-Based Security (VBS) states: "When you enable nested virtualization on a Windows WorkSpace, Credential Guard and VBS are automatically disabled. This is required because nested virtualization uses the hardware virtualization extensions that VBS relies on. If you need both Credential Guard and nested virtualization, they cannot be enabled on the same WorkSpace simultaneously."

The mechanism is not surprising — VBS is itself a hypervisor-based feature, and two hypervisors cannot both own the same processor extensions. What is surprising is that the What's New post, which is the document that reached every feed and every internal Slack channel on 18 August 2026, does not mention it. The AWS blog covering the same launch does, two days later. So does the admin guide.

AWS spells out the consequences on the same page, and they are not soft:

• Reduced kernel-level protection: the OS kernel becomes more vulnerable to malicious code.

• Increased risk of credential theft: attackers may more easily extract credentials from the lsass.exe process.

• Disabled code integrity checks: Hypervisor-Enforced Code Integrity will not function, allowing unsigned drivers to run in kernel mode.

• Increased vulnerability to exploits, up to full system compromise.

• Loss of Windows Defender Credential Guard and System Guard.

AWS's own guidance on that page is blunt: "Only disable VBS if required for specific performance or compatibility needs."

None of this is new at the infrastructure layer, which is what makes the omission harder to defend. AWS brought nested virtualization to virtualized EC2 instances on 16 February 2026, on C8i, M8i and R8i instance types. The EC2 nested virtualization documentation already listed both consequences under its considerations: "Credential Guard – Virtual Secure Mode (VSM) is automatically disabled" and "Hibernation – Instance hibernate and resume is not supported." The WorkSpaces launch inherits both. The EC2 page has said so for six months.

An administrator can enable nested virtualization on an individual WorkSpace through the console, CLI or API. Nothing in that path requires a security review. If your organisation mandates Credential Guard through a hardening baseline or an audit control, a single developer request routed to a helpful admin can quietly take a machine out of compliance. Treat the toggle as a change that needs sign-off, because the platform will not ask.

The AutoStop hibernation break, and what it actually costs

The second omission is operational and it has a price tag.

From the administration guide's known limitations: "WorkSpaces configured with AutoStop running mode that have nested virtualization enabled on Windows Server 2025 or Windows 11 24H2/25H2 perform a full reboot instead of hibernating when the WorkSpace times out. This results in longer resume times and loss of the user's prior session, including any unsaved work. If you require fast resume and/or session persistence, use AlwaysOn running mode for these WorkSpaces."

Losing unsaved work on an idle timeout is not a limitation a developer will tolerate twice. The documented remedy is to switch the running mode, and running mode is the main lever in WorkSpaces pricing.

AWS bills WorkSpaces Personal two ways. AlwaysOn is a flat monthly rate for unlimited use. AutoStop is a lower monthly base fee plus an hourly fee while the instance is running. Figures below are for the Windows Power bundle (4 vCPU, 16 GB memory, 175 GB root and 100 GB user volume, license included), retrieved from the Amazon WorkSpaces pricing page on 22 August 2026:

Work the arithmetic for the seats this actually affects. A part-time or occasional user at 60 hours a month costs $19.00 + (60 × $0.68) = $59.80 on AutoStop in US East (N. Virginia), against $78.00 on AlwaysOn. Forcing that seat to AlwaysOn adds $18.20 a month. Across 50 such seats, $910 a month, or $10,920 a year. In Asia Pacific (Mumbai) the same seat costs $26.00 + (60 × $0.99) = $85.40 on AutoStop against $124.00 on AlwaysOn, so $38.60 a month per seat and $1,930 a month across 50 seats.

Full-time users are unaffected by this particular trade, and it is worth saying plainly: at 176 hours a month a Power WorkSpace costs $138.68 on AutoStop in US East (N. Virginia) against $78.00 on AlwaysOn, so a heavy user should already be on AlwaysOn. The exposure sits entirely with the part-time cohort — contractors, QA, occasional builders — which is also the cohort a finance team put on AutoStop deliberately.

Both AWS pages say nested virtualization carries no additional charge, and that is accurate. The feature is free. The running-mode change the limitation forces is not.

Who is affected, and how to tell if that is you

You should act on this if any of the following is true:

• Your Windows baseline mandates Credential Guard or Hypervisor-Enforced Code Integrity. Enabling nested virtualization on a WorkSpace silently drops both.

• You run WorkSpaces on Windows Server 2025 or Windows 11 24H2/25H2 with AutoStop and you plan to enable nested virtualization. Session persistence goes away.

• Your fleet uses Standby WorkSpaces for multi-Region resilience. Nested virtualization is not supported there.

• You piloted on the Value bundle, or you run Amazon Linux 2, or your users are still on PCoIP. None of those can take the feature.

• You budgeted a developer WorkSpaces rollout on AutoStop pricing and have not modelled the AlwaysOn fallback.

You are clear if you run AlwaysOn on Power or larger, on DCV, on a supported Windows or Linux image, and Credential Guard is not part of your control set. For that shape the launch is a straightforward win at no extra cost.

Getting the configuration right

The supported matrix, taken from the administration guide rather than the announcement:

Note the gap between the recommendation and the support boundary. AWS recommends Power (4 vCPU) or higher, but Standard and Performance are supported. A team that reads only the announcement line "Power (4 vCPU) or higher is recommended" may not realise it can enable the feature on a Standard bundle and then watch a nested VM starve the host session. Test before you roll it out; AWS says so directly.

The setting survives Restore, Rebuild and Migrate operations, with one caveat on Migrate: if the destination bundle does not meet the prerequisites, the feature is disabled. Migrating a nested-virtualization WorkSpace onto a GPU or Value bundle will turn it off, and a developer will discover that when Docker Desktop refuses to start rather than when the migration runs.

What to do this week

1. Decide the Credential Guard question at policy level before any admin enables the toggle. It is a security posture change, and the console does not present it as one.

1. Inventory which WorkSpaces run Windows Server 2025 or Windows 11 24H2/25H2 on AutoStop. Those are the seats where hibernation breaks.

1. Price the AlwaysOn fallback for the part-time cohort at your own bundle and Region before you approve the rollout, not after the first invoice.

1. Check whether Standby WorkSpaces is part of your resilience plan. If it is, nested virtualization and that plan do not coexist today.

1. Audit for the two exclusions the announcement omitted: Value bundle size and Amazon Linux 2.

1. Confirm the protocol. PCoIP fleets need a DCV migration first, which is a separate project with its own client and image implications. The WorkSpaces bundles page shows Windows Server 2025 as DCV-only, while Windows Server 2019 and Windows 10 still carry both protocols.

1. Fold this into your Windows Server 2016 exit. That image cannot take nested virtualization and its WorkSpaces lifecycle retirement date is 12 January 2027, so the two migrations are the same project.

For mobile teams the calculation is usually the simplest one on this list: hardware-accelerated Android emulation inside a managed desktop is worth real money in onboarding time and device-security posture, and the AlwaysOn premium is small against a developer's cost. That is the case our Android engineering teams make most often. The cost modelling for the wider fleet belongs with the same discipline covered in our cloud FinOps guide for Indian teams, alongside the commitment questions in our notes on AWS Savings Plans coverage sizing and the Azure Reserved VM Instances retirement.

The expensive part of a virtual desktop programme is rarely the desktop. It is the exceptions.

What is still unknown

AWS has not said whether the AutoStop hibernation failure on Windows Server 2025 and Windows 11 24H2/25H2 is a permanent architectural consequence of nested virtualization or a defect with a fix planned, and no target date is published. Nothing states whether Standby WorkSpaces support is on the roadmap. There is no published guidance on whether AWS intends to surface the Credential Guard change as a console warning or a compliance signal, so for now the only control is your own change process. The administration guide also says the modification "may take se[veral]" minutes to apply without committing to a figure, so plan the enablement window generously rather than to a number.

India-specific considerations

Asia Pacific (Mumbai) carries a wider AlwaysOn-to-AutoStop gap than US East (N. Virginia) on the Windows Power bundle: $124.00 against $26.00 plus $0.99 an hour, which pushes the break-even out to about 99 hours a month against about 87 in US East (N. Virginia). The practical effect is that the AutoStop cohort is larger in Mumbai, so more seats are exposed to the hibernation limitation and the per-seat cost of the AlwaysOn fallback is higher — $38.60 a month against $18.20. For Indian services firms running offshore development desks, that is the number to put in the rollout business case. Where WorkSpaces hold client data subject to the Digital Personal Data Protection Act 2023, the Credential Guard shutdown deserves an explicit entry in the risk register: credential extraction from lsass.exe becomes materially easier, and that is a control your client's security questionnaire probably asks about by name.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5, MSME certified and ISO 27001:2022 certified engineering organisation in Gurugram, and an AWS partner. Our senior engineering teams size developer desktop fleets, model the AlwaysOn and AutoStop split against real usage data, and design applications aligned with DPDP Act 2023 requirements where those desktops touch personal data. If you are weighing nested virtualization against a Credential Guard baseline, contact us and we will work through the trade with your security team.

References

1. Amazon WorkSpaces now supports Nested Virtualization — AWS What's New, posted 18 August 2026.

1. Nested virtualization for WorkSpaces Personal — Amazon WorkSpaces Administration Guide, supported configurations, prerequisites, known limitations, lifecycle behaviour.

1. Credential Guard / Virtualization-Based Security (VBS) — Amazon WorkSpaces Administration Guide, automatic disablement and security implications.

1. Working with Nested Virtualization on Amazon WorkSpaces — Dan Garibay and Sona Chandramohan, AWS Desktop and Application Streaming blog, 20 August 2026.

1. Amazon WorkSpaces pricing — AWS, AlwaysOn and AutoStop rates for WorkSpaces Personal, retrieved 22 August 2026.

1. Amazon WorkSpaces bundles — Amazon WorkSpaces Administration Guide, bundle sizes and specifications.

1. Use nested virtualization to run hypervisors in Amazon EC2 instances — Amazon EC2 User Guide, the infrastructure-level behaviour AWS cites as consistent.

1. Amazon EC2 supports nested virtualization on virtual Amazon EC2 instances — AWS What's New, February 2026, the EC2 precursor to this launch.

1. Amazon EKS Capability for Argo CD now supports custom configuration — AWS What's New, 21 August 2026, a second August launch where the announcement and the reference documentation diverge.

1. Amazon EKS pricing — AWS, for comparison of hourly managed-service metering models, retrieved 22 August 2026.

1. Amazon WorkSpaces protocols and networking — Amazon WorkSpaces Administration Guide, DCV and PCoIP protocol requirements.

Last updated: 22 August 2026.