Hola a tod@s,

Cuando hablamos de Azure Local solemos centrarnos en la arquitectura, el rendimiento, la integración con Azure Arc o la operación híbrida. Pero hay una parte que, tarde o temprano, siempre aparece en cualquier proyecto real: el licenciamiento.

Y aquí es precisamente donde muchos de nosotros nos frenamos. No porque el modelo sea imposible de entender, sino porque mezcla conceptos que durante años hemos tratado por separado: licencias tradicionales de Windows Server, suscripciones mensuales en Azure, derechos de virtualización y beneficios híbridos.

La realidad es que Azure Local no se licencia como un clúster Hyper-V tradicional, ni tampoco como una máquina virtual en Azure. Tiene su propia lógica. Y si no la entendemos bien desde el principio, podemos sobredimensionar el presupuesto, elegir mal el tipo de despliegue o incluso pensar que una licencia existente nos cubre algo que en realidad no cubre.

En este artículo vamos a aterrizar todo esto con un enfoque práctico: qué se paga realmente en Azure Local, cómo encajan Windows Server Subscription y Azure Hybrid Benefit, qué cambia según el tipo de despliegue, y qué recomendaciones deberíamos aplicar antes de llevar un diseño a producción.

Para empezar:

• Azure Local se factura por núcleo físico (physical core) de los servidores on premises, no por número de máquinas virtuales.
• El host fee cambia en función del tipo de despliegue: L1 para hiperconvergencia sin almacenamiento externo, L2 para despliegues desagregados o con almacenamiento externo, y L3 para operaciones desconectadas con plano de control local.
• El sistema operativo del host Azure Local no requiere una licencia tradicional separada; lo que se factura es el servicio Azure Local. Sin embargo, las VMs invitadas siguen necesitando derechos de sistema operativo.
• Para las máquinas virtuales Windows Server existen dos caminos principales: Windows Server Subscription o Azure Hybrid Benefit, siempre que se cumplan los requisitos de elegibilidad.
• Si desmontamos un clúster sin eliminar su recurso de Azure Local en Azure, la facturación puede continuar durante más de 31 días. Este es uno de los errores operativos más importantes a evitar.

¿Qué se paga realmente en Azure Local?

El primer punto que debemos aclarar es que Azure Local es un servicio de Azure que se factura en la suscripción de Azure, aunque el hardware esté en nuestro datacenter o en una ubicación de edge. Es decir, Microsoft ya no lo trata como una licencia perpetua tradicional del host, sino como un servicio híbrido con facturación cloud-style.

Eso cambia radicalmente la conversación con negocio y con compras. Ya no estamos ante un pago único de software, sino ante un coste mensual recurrente asociado a la capacidad física del entorno.

La base del cálculo es simple: Azure Local se cobra por núcleo físico de CPU en los servidores que forman parte de la instancia. No importa cuántas VMs ejecutemos encima ni cuántos vCPU asignemos. El precio no se basa en consumo por VM, sino en la suma de cores físicos del sistema.

Idea clave: en Azure Local la variable económica principal no es el número de máquinas virtuales, sino el número total de núcleos físicos que estamos poniendo bajo gestión del servicio.

Modelo de precio por niveles: L1, L2 y L3

Uno de los cambios más relevantes es que Microsoft ya no nos presenta Azure Local como un único precio plano para todos los escenarios. La página oficial de precios y las últimas aclaraciones de la comunidad técnica muestran un modelo por niveles asociado al tipo de despliegue.

Esto es importante porque no cuesta lo mismo un entorno hiperconvergente clásico con Storage Spaces Direct que un diseño desagregado con almacenamiento externo o una implementación con operaciones desconectadas.

Interpretación práctica: si el diseño cambia de hiperconvergente clásico a desagregado, no solo cambia la arquitectura: también puede cambiar el coste mensual base del servicio.

Azure Local no es lo mismo que licenciar las VMs invitadas

Aquí existe una de las confusiones más frecuentes. Pagar Azure Local no significa que automáticamente queden cubiertas todas las máquinas virtuales Windows Server que ejecutemos sobre la plataforma.

La cuota del host cubre el servicio Azure Local, pero los sistemas operativos invitados siguen necesitando activación y derechos de uso. Para ello Microsoft plantea dos caminos principales dentro del propio ecosistema Azure Local: Windows Server Subscription y Azure Hybrid Benefit.

En otras palabras: una cosa es pagar la plataforma donde corren las VMs, y otra distinta es pagar o habilitar los derechos de Windows Server dentro de esas VMs.

Windows Server Subscription: simplicidad operativa a cambio de coste mensual

Windows Server Subscription es un add-on específico de Azure Local. Se factura también por núcleo físico y simplifica mucho la activación de VMs Windows Server mediante AVMA automático.

Su principal ventaja es operativa: elimina gran parte de la gestión clásica de claves para huéspedes Windows, da acceso a versiones evergreen y permite estandarizar la activación de todas las VMs Windows Server del entorno.

A nivel de precio público, Microsoft publica esta suscripción como un coste adicional por core físico al mes. Es decir, si la activamos, el TCO mensual del clúster puede incrementarse de forma importante si no contamos con beneficios híbridos previos.

• Activación simplificada de VMs Windows Server mediante AVMA.
• Cobertura para versiones de Windows Server permitidas en Azure Local, incluyendo Azure Edition cuando aplique.
• No requiere gestionar licencias individualmente por cada VM invitada.
• En Azure Local las Mvs con Windows Server no son requeridas las CAL.

Azure Hybrid Benefit: cuando nuestras licencias existentes sí marcan la diferencia

Si ya disponemos de Windows Server Datacenter con Software Assurance activo, Azure Hybrid Benefit puede cambiar completamente el modelo económico de nuestro proyecto.

La lógica es la siguiente: Microsoft nos permite intercambiar 1 core de licencia elegible de Windows Server Datacenter con Software Assurance por 1 core físico de Azure Local. Cuando el beneficio aplica, se puede eximir tanto la cuota del host Azure Local como la suscripción de Windows Server en el sistema.

Este punto es especialmente relevante para organizaciones que ya tienen un parque licenciado de forma correcta y quieren modernizar su plataforma sin pagar dos veces por el mismo derecho lógico.

Además, la documentación actual de Microsoft ya contempla Azure Hybrid Benefit también para determinados despliegues desagregados, por lo que conviene revisar la elegibilidad exacta del diseño con el partner o con el programa de licenciamiento antes de cerrar el presupuesto.

Muy importante: Azure Hybrid Benefit no es automático. Debe activarse y mantenerse en conformidad con el número de cores licenciados, el tipo de contrato y la vigencia del Software Assurance.

Qué cambios recientes merece la pena vigilar (Al Loro)

La conversación reciente en la comunidad técnica ha puesto el foco en dos cambios que conviene tener muy presentes cuando preparemos propuestas o comparativas económicas.

El primero es la clarificación del host servicing fee por niveles según el tipo de asignación de la instancia (L1, L2 y L3). Esto impacta directamente a escenarios SAN, desagregados o diseños con control plane local.

El segundo es la evolución del catálogo de soluciones Azure Local y sus distintos niveles de certificación de hardware. Aunque esto afecta más al plano de validación y soporte que a la licencia en sí, acaba influyendo en el coste total de nuestro proyecto y en la forma de plantear la compra con el OEM.

Dos ejemplos sencillos para aterrizar el coste

Veamos dos escenarios simplificados con precios públicos orientativos. No son una cotización; solo sirven para entender el impacto del modelo.

Escenario A: clúster hiperconvergente de 2 nodos, 32 cores por nodo (64 cores totales)

• Host fee L1: 64 x 9 € = 576 € /mes.
• Si añadimos Windows Server Subscription: 64 x 20 € = 1.280€/meses adicionales.
• Coste orientativo combinado: 2048 €/mes, sin incluir servicios Azure adicionales como Backup, Monitor o Site Recovery.
• Si la organización es elegible para Azure Hybrid Benefit y lo activa correctamente, ese escenario puede reducirse de forma muy importante en la parte de host y guest rights.

Escenario B: despliegue desagregado con 128 cores físicos en la capa computacional

• Host fee L2: 128 x 17,30 € = 2.214,40 /mes.
• Si además se activa Windows Server Subscription: 128 x 20 € = 2.560 €/meses adicionales.
• Coste orientativo combinado: 4.774,40 € /mes, antes de añadir otros servicios de Azure y sin contemplar ahorro por Azure Hybrid Benefit si existiese elegibilidad.

Conclusión de los ejemplos: el diseño técnico impacta directamente en el modelo económico. En Azure Local, arquitectura y licenciamiento no se pueden separar.

Errores comunes que conviene que evitemos

• Pensar que Azure Local incluye automáticamente derechos ilimitados para todas nuestras VMs Windows Server.
• Dimensionar el presupuesto solo con el host fee y olvidar la capa de guest licensing.
• No validar si el cliente tiene Software Assurance activa y elegible para Azure Hybrid Benefit.
• Elegir una arquitectura desagregada sin revisar el salto de coste frente al nivel L1.
• Desmantelar o apagar el clúster sin eliminar correctamente el recurso de Azure Local en Azure, provocando facturación residual.
• No contemplar los costes adicionales de servicios como Azure Backup, Azure Monitor o Azure Site Recovery.

Estas son mis recomendaciones prácticas antes de ir a producción.

• Realizar un inventario real de cores físicos por nodo y no una estimación rápida basada en vCPU o en número de VMs.
• Separa en el business case tres capas de coste: hardware/OEM, cuota Azure Local y licenciamiento/activación de VMs Windows Server.
• Valida por adelantado si puedes aplicar Azure Hybrid Benefit. Si no existe Software Assurance activa, el proyecto puede cambiar radicalmente de coste.
• Incluye un apartado operativo en el runbook para alta, baja y decommission del clúster, con el paso explícito de eliminar el recurso en Azure cuando corresponda.
• Si vas a presentar una comparativa frente a Hyper-V o VMware, hazla con escenarios equivalentes y no solo con una línea de precio por core. El contexto importa.

Para finalizar.

Azure Local es una plataforma muy potente, pero su valor real no depende solo de la tecnología. También depende de entender bien cómo se licencia.

Si nos quedamos únicamente con el dato de “precio por core”, nos perderemos una parte crítica de la película: el tipo de despliegue, los derechos de Windows Server en las VMs, la elegibilidad para Azure Hybrid Benefit y la forma correcta de operar el ciclo de vida del clúster.

Por eso, cuando diseñamos una implantación de Azure Local, no deberíamos separar nunca arquitectura, operación y licenciamiento. En este producto los tres forman parte del mismo diseño.

Ya sabemos cómo funciona el modelo de licenciamiento de Azure Local y, lo más importante, cómo interpretar sus implicaciones reales antes de aprobar una inversión.

Nos vemos en el próximo artículo.

Saludos.