Problema

En entornos de producción que usan Azure, los cambios de configuración predeterminada y la retirada de SKUs de máquinas virtuales pueden romper pipelines de CI/CD, scripts de aprovisionamiento y políticas de seguridad. Cuando Microsoft anuncia que Trusted Launch será el modo por defecto para cualquier VM Gen2, o que los SKUs cc_v5 de máquinas confidenciales se retirarán, los equipos se ven obligados a revisar plantillas Bicep/Terraform, scripts de PowerShell y procesos de despliegue. Además, la llegada de funcionalidades como Azure Virtual Network Routing Appliance (VNRA), Azure Firewall explicit proxy, Route Server route maps y IPv6 Private Link implica que los diseños de red que antes funcionaban sin esas opciones pueden quedar desalineados con las mejores prácticas actuales. El patrón típico es: una actualización de plataforma introduce un nuevo comportamiento por defecto o elimina recursos, y el código de infraestructura existente no se adapta, generando fallos en despliegues, errores de compatibilidad o brechas de seguridad.

Causa

  1. Cambios de defaults sin revisión de IaC – Trusted Launch pasa a ser predeterminado, pero los módulos de Bicep/Terraform siguen sin declarar explícitamente la opción. En algunos casos, la ausencia de la propiedad lleva a configuraciones inesperadas (por ejemplo, desactivación de Secure Boot en VMs heredadas).

  2. Retiro de SKUs – Los SKUs cc_v5 son descontinuados el 1 Sept 2026. Los pipelines que usan az vm create --size Standard_CCv5 fallan con “SKU not available”. La causa suele ser una referencia estática en scripts o variables de entorno.

  3. Nuevas capacidades de red no aprovechadas – VNRA, proxy de Azure Firewall y IPv6 Private Link requieren configuraciones explícitas (subnet, rutas, políticas). Cuando la arquitectura sigue usando appliances tradicionales o IPv4‑only, se pierden beneficios de escalabilidad y seguridad.

  4. Dependencias cruzadas – Algunas funcionalidades (por ejemplo, Route Server route maps) dependen de versiones mínimas de BGP o de la habilitación de “allow‑advertise‑default”. Si el entorno tiene versiones antiguas de Azure CLI o módulos de PowerShell, los comandos fallan silenciosamente.

Solución

Adoptar un enfoque de validación y actualización continua de la infraestructura como código (IaC). El proceso consta de tres pasos:

  1. Inventario automatizado – Ejecutar consultas que enumeren VMs, SKUs, configuraciones de red y políticas de firewall. Con Azure CLI se pueden obtener listas filtradas y exportarlas a JSON para comparar con la configuración deseada.

  2. Plantillas declarativas actualizadas –

    • En Bicep/Terraform, declarar explícitamente trustedLaunch: true para evitar sorpresas cuando el default cambie de nuevo.
    • Sustituir cualquier referencia a Standard_CCv5 por la SKU de la generación siguiente (Standard_CCv6 o equivalente) usando variables.
    • Añadir módulos de VNRA y de Azure Firewall proxy con los parámetros requeridos (subnet, enableExplicitProxy: true).
    • Definir routeMap en el recurso Microsoft.Network/routeServers para controlar la publicidad de rutas y habilitar BGP communities.

  3. Pipeline de pruebas de integración – Incorporar etapas que desplieguen en un sandbox los recursos modificados y ejecuten pruebas de conectividad (pings, traceroute, pruebas de TLS a través del firewall proxy). Si alguna prueba falla, el pipeline bloquea el merge.

Ejemplo de actualización de Bicep

resource vm 'Microsoft.Compute/virtualMachines@2024-03-01' = {
  name: vmName
  location: location
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_CCv6' // reemplazo de cc_v5
    }
    securityProfile: {
      securityType: 'TrustedLaunch' // explícito
      trustedLaunch: {
        enabled: true
        secureBootEnabled: true
        vTPMEnabled: true
      }
    }
    // resto de la definición...
  }
}

Configuración de Azure Firewall como proxy explícito (CLI)

az network firewall create \
  --resource-group rg-prod \
  --name fw-prod \
  --sku AZFW_VNet

az network firewall policy create \
  --resource-group rg-prod \
  --name fwpolicy-prod

az network firewall policy update \
  --resource-group rg-prod \
  --name fwpolicy-prod \
  --set explicitProxy.enabled=true \
  --set explicitProxy.httpPort=3128 \
  --set explicitProxy.httpsPort=3129

az network firewall update \
  --resource-group rg-prod \
  --name fw-prod \
  --firewall-policy-id $(az network firewall policy show -g rg-prod -n fwpolicy-prod --query id -o tsv)

az network private-endpoint create \
  --resource-group rg-prod \
  --name pe-storage-ipv6 \
  --vnet-name vnet-prod \
  --subnet subnet-storage \
  --private-connection-resource-id $(az storage account show -g rg-prod -n mystorage --query id -o tsv) \
  --group-id blob \
  --connection-name conn-ipv6 \
  --enable-ipv6 true

Cuándo aplicar esta solución

  • Síntomas: despliegues que fallan con “SKU not available”, VMs que aparecen sin Secure Boot, tráfico que sigue pasando por appliances tradicionales pese a haber habilitado VNRA, o clientes que no pueden resolver nombres internos sin salto extra de DNS.
  • Entornos: cualquier suscripción que use IaC para VMs Gen2, redes con Azure Firewall o Route Server, y que dependa de Azure Storage, SQL o Databricks.
  • Exclusiones: entornos totalmente on‑premise que no consumen recursos de Azure, o despliegues que usan exclusivamente SKUs no afectados por la retirada (por ejemplo, series D). En esos casos, la actualización de defaults no impacta.

Código

# 1. Listar VMs con SKU cc_v5
az vm list -g rg-prod --query "[?hardwareProfile.vmSize=='Standard_CCv5'].{name:name, sku:hardwareProfile.vmSize}" -o table

# 2. Exportar configuración actual de Trusted Launch
az vm show -g rg-prod -n vm-example --query "securityProfile.trustedLaunch" -o json > trustedLaunch.json

# 3. Actualizar todas las VMs a la SKU v6 (bash loop)
for vm in $(az vm list -g rg-prod --query "[?hardwareProfile.vmSize=='Standard_CCv5'].name" -o tsv); do
  az vm update -g rg-prod -n $vm --set hardwareProfile.vmSize=Standard_CCv6
done

Verificación

  1. Comprobar SKU: az vm list -g rg-prod --query "[].{name:name, sku:hardwareProfile.vmSize}" -o table debe mostrar solo la nueva SKU.
  2. Validar Trusted Launch: az vm show -g rg-prod -n <vm> --query "securityProfile.trustedLaunch.enabled" debe devolver true.
  3. Probar proxy: Configura un navegador para usar http://<fw-ip>:3128 y verifica que una petición a https://www.microsoft.com pasa por el firewall (mirar logs en Azure Monitor).
  4. IPv6 connectivity: Desde una VM con IPv6, ejecuta ping6 <private-endpoint-ipv6>; la respuesta indica que el Private Link está activo.
  5. Route Server: Ejecuta az network route-server show -g rg-prod -n rs-prod --query "routeMaps" y confirma que los mapas están aplicados.

Notas adicionales

  • Versiones de CLI: Azure CLI 2.65+ incluye los flags --enable-ipv6. Actualiza con az upgrade antes de ejecutar los scripts.
  • Rollback rápido: guarda la salida de az vm show antes de cambiar la SKU; si algo falla, puedes volver a crear la VM con la configuración anterior usando az vm create y el JSON exportado.
  • Política de Azure Policy: considera crear una política que obligue a trustedLaunch: true y que bloquee SKUs obsoletos; así el control se mantiene a nivel de suscripción.
  • Costos: la activación de VNRA y de IPv6 Private Link no genera cargos adicionales, pero el tráfico interno puede incrementar el consumo de datos de ExpressRoute si se habilita el peering privado.
  • Documentación de referencia: revisa los artículos de Microsoft sobre “Trusted Launch default”, “VM SKU retirement” y “Azure Firewall explicit proxy” para confirmar los nombres exactos de los parámetros en caso de actualizaciones futuras.