On September 1, Azure Updates marked Confidential VMs for Azure Linux generally available on AKS. The release note is short: CVM node pools now support Azure Linux, letting you "target the migration of highly sensitive container workloads to AKS without" code refactoring. On its own, that's a genuinely useful GA — memory-encrypted, hardware-isolated container nodes are exactly the primitive a sovereign or regulated workload needs. But the interesting part isn't in the release note. It's in the AKS documentation two clicks away, where the OS support matrix quietly rules out the combination most architects in this space would actually reach for first.
What shipped
Confidential VM node pools on AKS run on Azure's DCasv5/ECasv5 series, built on AMD SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging). The hypervisor and host management code are denied access to VM memory and state, each node gets a hardware-generated memory encryption key, and you can cryptographically attest that your workload is actually running inside that trusted execution environment before you trust it with anything sensitive. Lift-and-shift is the pitch: existing Linux containers move onto CVM nodes without rewrites, which is what makes this GA — rather than a preview requiring workload redesign — worth paying attention to.
Until now, that capability was available on Ubuntu. This release adds Azure Linux 3.0 — Microsoft's own minimal, hardened, RPM-based distribution — as a supported, GA OS SKU for CVM node pools, alongside Ubuntu 20.04/24.04. For anyone building sovereign landing zones on Microsoft's own Linux rather than a community distribution, that's the more relevant part of the announcement than the AMD silicon underneath it.
The exclusion nobody's flagging
Here's where it gets specific. AKS ships two Azure Linux-based node images today: Azure Linux Container Host — the mutable, package-managed OS this GA applies to — and Azure Container Linux (ACL), generally available since AKS v1.34, built on Flatcar with an immutable /usr protected by dm-verity, SELinux enforcing by default, and mandatory Trusted Launch with Secure Boot and vTPM. ACL is, on paper, the more hardened of the two — it's the image you'd reach for on a defense-in-depth checklist. Microsoft's own comparison table lists Confidential VM support for Azure Linux Container Host as "Supported." For Azure Container Linux, the same row reads: "Not yet supported."
So the choice this GA actually hands you isn't "should I use confidential VMs." It's: do you want kernel-enforced immutability and mandatory Secure Boot (ACL), or hardware memory encryption and attestable isolation from the hypervisor (CVM on the classic image)? Today, on AKS, you cannot have both in the same node pool.
It doesn't stop there
The CVM node pool limitations documented for both OS SKUs go further than the ACL exclusion:
- No FIPS mode. CVM node pools can't be combined with FIPS-validated cryptographic modules — a control that shows up in EU public-sector and defense procurement almost as often as in US federal requirements, not just a Fairfax-specific checkbox.
- No Trusted Launch. Ironically, the VM-level protections (Secure Boot, vTPM, boot integrity monitoring) that Trusted Launch provides are unavailable on the node type built for the highest confidentiality bar.
- No ARM64, no Pod Sandboxing, no in-place migration. Moving an existing node pool to a CVM size isn't supported — it's a resize-and-replace operation, not a config change.
- AMD only. Intel TDX-based confidential VMs exist elsewhere in Azure but aren't currently supported on AKS at all — this GA is SEV-SNP or nothing.
None of this makes the GA less real. It does mean "we run confidential containers on AKS" is a sentence that needs a follow-up question before you know what security posture it actually describes.
What's not answered yet
- No stated timeline for ACL + CVM convergence. Nothing in the docs or release note commits to bringing confidential VM support to Azure Container Linux, even though ACL is the newer, more hardened image.
- No Intel TDX roadmap for AKS. Whether AKS ever gets Intel-based confidential VMs, or stays AMD-exclusive, isn't addressed.
- No FIPS + CVM compatibility roadmap. For workloads that need both, there's no published path — you currently pick one.
- Windows CVM node pools remain unsupported entirely — this GA, like CVM on AKS generally, is Linux-only.
Who should care
If you're migrating sensitive Linux containers to AKS and Azure Linux is your standard image, this GA is a real, usable win — no code changes, GA-quality support, hardware attestation available today. If your threat model assumes you need both an immutable, SELinux-enforcing OS and hardware memory encryption in the same node pool — which is a reasonable bar for a sovereign landing zone handling classified or highly regulated data — the honest answer is that AKS doesn't offer that combination yet, and nothing published says when it will.
"Confidential" and "hardened" turned out to be two different procurement lines on AKS's Azure Linux roadmap, not one. Worth checking which one your compliance requirement actually asks for before you promise both.
I'm tracking whether ACL picks up CVM support before Intel TDX lands on AKS — that's the sequencing that tells you where Microsoft's confidential-computing investment on Azure Linux is actually headed. If you want that update when it lands, subscribe to Sovereign Cloud Watch or find me on LinkedIn.