Azure DCsv2 Confidential VM Retirement Migration Before June 30, — when and how should I migrate?
Teams on DCsv2 confidential-computing VMs need to choose replacement SKUs and revalidate enclave assumptions before retirement on June 30, 2026 changes both runtime availability and billing.
Blockers
- runtime/dcsv2 — EOL 2026-06-30
- DCdsv3 preserves the enclave-based Intel SGX model
- DCasv5 uses AMD SEV-SNP
- DCadsv5 uses AMD SEV-SNP
- Azure Confidential Container Instances runs with AMD SEV-SNP
- Confidential computing enforcement policies must be generated by the Azure CLI confcom extension
- Migration changes billing when keeping a local temp disk
- SEV-SNP is a different trust and attestation model from SGX
- SEV-SNP is a different trust and attestation model from SGX
Who this is for
- enterprise
- compliance
- cost-sensitive
Candidates
Migrate to DCdsv3 to preserve Intel SGX enclaves
Microsoft's retirement guide says DCsv2-series VMs retire on June 30, 2026 and recommends DCdsv3 if you need to continue using the enclave-based Intel SGX model. As of 2026-04-02, DCsv2 already has capacity restrictions and no new subscriptions have been allowed since July 1, 2025. The DC family page says DCsv3/DCdsv3 use Intel SGX plus Intel Total Memory Encryption - Multi Key on 3rd Gen Intel Xeon Scalable processors, with up to 48 vCPUs and 384 GiB RAM. As of 2026-04-02, Microsoft confirms migration from DCsv2 to DCdsv3 changes billing when you keep a local temp disk, so check official pricing docs for the exact delta.
When to choose
Use this when your application explicitly depends on Intel SGX enclaves and you want the least architectural change before June 30, 2026. It is the decisive choice if enclave semantics matter more than global availability or adopting newer whole-VM confidential-computing models.
Tradeoffs
Preserves the SGX programming model and is the primary Microsoft-recommended retirement path. Tradeoffs are region constraints, a billing change for the temp-disk path, and older-region footprint compared with newer confidential VM families.
Cautions
IAS EPID attestation is not supported on DCdsv3, and Microsoft's guide says Intel ended IAS support on April 2, 2025. You can resize from DCsv2 to DCdsv3, but you cannot directly resize from a temp-disk DCsv2 VM to diskless DCsv3. Microsoft also says DCsv2, DCsv3, and DCdsv3 are not being deployed in new regions, and all DCsv2-based uses retire together, including AKS and VM Scale Sets.
Move to DCasv5 or DCadsv5 confidential VMs and rework around AMD SEV-SNP
Microsoft's retirement guide lists DCasv5/DCadsv5/ECasv5/ECadsv5 as lift-and-shift confidential VM alternatives when you prefer broader availability instead of staying on the SGX path. The DC family docs say DCasv5 and DCadsv5 use 3rd Gen AMD EPYC 7763v processors and AMD SEV-SNP, with 2 to 96 vCPUs and 8 to 384 GiB RAM. DCasv5 has no local disk, while DCadsv5 includes local temporary storage. As of 2026-04-02, exact price differences versus DCsv2 should be checked in official pricing docs.
When to choose
Use this when you can move from enclave-centric design to confidential VMs that protect the whole guest and you want a current-generation Azure confidential-computing platform. It is the decisive choice when portability and broader rollout matter more than preserving Intel SGX-specific code paths.
Tradeoffs
You get modern confidential VM hardware and a clearer forward path than staying tied to retiring SGX SKUs. The tradeoff is that SEV-SNP is a different trust and attestation model from SGX, so enclave-specific assumptions, libraries, and attestation flows need revalidation.
Cautions
Do not treat DCasv5 or DCadsv5 as drop-in SGX replacements. The retirement guide positions them as alternatives for lift and shift, not as enclave-compatible continuations. If your current image, scripts, or paging behavior expect a local temp disk, prefer the local-disk variant or rework the guest layout first.
Sources
- learn.microsoft.com/en-us/azure/virtual-machines/sizes/retirement/dcsv2-series-retirement
- learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dc-family
- learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dcasv5-series
- azure.microsoft.com/en-us/pricing/details/virtual-machines/
Replatform containerized workloads to Azure Confidential Container Instances
Microsoft's retirement guide says teams with containerized workloads can consider Azure Confidential Container Instances instead of another VM SKU. The ACI confidential containers docs say this runs Linux containers inside a hardware-based, attested TEE with AMD SEV-SNP, remote guest attestation, and pay-per-use pricing. It is a platform shift rather than a VM resize, so it changes both packaging and operational model. As of 2026-04-02, check official ACI pricing docs for exact cost numbers.
When to choose
Use this when the workload is already containerized or can be containerized quickly and you want a serverless confidential-computing option instead of maintaining confidential VMs. It is the decisive choice when low-ops deployment matters more than preserving the current VM-based runtime shape.
Tradeoffs
This removes VM management overhead and aligns with Microsoft's cloud-native migration path. The tradeoff is higher migration scope because you are changing packaging, startup model, and confidential-computing controls.
Cautions
The ACI docs say confidential computing enforcement policies must be generated by the Azure CLI `confcom` extension and cannot be manually created. This is not an SGX enclave continuation, so existing enclave code and attestation assumptions need redesign rather than simple resize testing.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Azure DCsv2 Confidential VM Retirement Migration Before June 30, — when and how should I migrate?"