Microsoft ha añadido el 5 de agosto de 2026 un aviso de retirada para cuatro series de máquinas virtuales confidenciales anidadas de Azure. Según Azure Updates, las series DCas_cc_v5, DCads_cc_v5, ECas_cc_v5 y ECads_cc_v5 dejarán de estar disponibles para uso o compra el 1 de septiembre de 2026. Las máquinas afectadas que no se hayan redimensionado antes de esa fecha serán desasignadas.
Hay dos fechas oficiales y no conviene elegir la más cómoda
El aviso de Azure Updates fue añadido y modificado el 5 de agosto y señala el 1 de septiembre. Sin embargo, la guía de migración de Microsoft Learn, actualizada el 1 de agosto, continúa indicando el 1 de agosto como fecha de retirada. Son dos páginas oficiales que ahora mismo no están alineadas.
El hecho verificable es esa discrepancia. Mi valoración es que no debería tratarse como una prórroga garantizada. Si todavía existe alguna carga en estas series, asumiría que está fuera del calendario documentado originalmente y abriría una solicitud de soporte para confirmar el estado concreto de la suscripción. Mientras llega la respuesta, avanzaría con la migración.
A quién afecta
La guía incluye cargas ejecutadas sobre esas cuatro familias mediante máquinas virtuales, Virtual Machine Scale Sets o servicios construidos sobre esos SKU. El anuncio no limita el cambio a una región determinada. Por eso, la revisión debe hacerse en todas las suscripciones y regiones, incluida cualquier plataforma que abstraiga el tamaño de VM y pueda ocultarlo a primera vista.
Estas series se diseñaron para virtualización confidencial anidada. No basta con escoger un tamaño que tenga una cifra parecida de vCPU y memoria: hay que comprobar si la carga necesita virtualización anidada, aislamiento confidencial, disco temporal, red acelerada y el mismo modelo operativo.
Las alternativas no son equivalentes
Para cargas generales, Microsoft propone familias como Dasv5/Dadsv5 o Easv5/Eadsv5. Para virtualización anidada sin requisitos confidenciales, recomienda elegir un tamaño general que la soporte. Si se necesita computación confidencial, la guía menciona DCasv6/ECasv6 y DCesv6, pero las presenta en Public Preview, además de alternativas con Azure Confidential Container Instances o nodos virtuales para AKS.
Esto obliga a separar disponibilidad de adecuación. Una opción en preview puede servir para validar, pero no debe darse por sustituto de producción sin revisar soporte, SLA, región, cuota y requisitos de seguridad. También puede cambiar el coste al pasar de SKU.
Qué revisaría hoy
- Inventariar las cuatro familias afectadas en VM, conjuntos de escalado y servicios dependientes.
- Confirmar copia de seguridad, dependencias y ventana de parada antes de redimensionar.
- Validar disponibilidad regional y cuota de vCPU para la familia de destino antes de tocar la VM.
- Revisar direcciones IP dinámicas: al desasignar la máquina pueden liberarse. Los discos de sistema operativo y datos no se ven afectados por el redimensionado, según Microsoft.
- Comparar rendimiento, precio y controles de confidencialidad; no elegir solo por tamaño.
- Abrir un caso con Azure para resolver la diferencia entre el 1 de agosto y el 1 de septiembre en el entorno afectado.
La acción importante no es discutir qué página se actualizará primero, sino evitar que una retirada automática decida la ventana de cambio. El inventario y la validación del destino deberían empezar ya.