La factura de julio de Contoso Airlines fueron 17.800 €, y toda ella se pagó a tarifa de pago por uso: la más flexible que existe y, precisamente por eso, la más cara. Azure cobra un sobreprecio por no exigirte ningún compromiso, y cuando llevas nueve meses ejecutando los mismos siete nodos de Kubernetes veinticuatro horas al día, pagar por una flexibilidad que no usas es tirar dinero.

Esta lección trata del mecanismo de descuento más potente de Azure y del que menos se aprovecha: comprometerse. Verás qué son las instancias reservadas —plazos, formas de pago, ámbitos, flexibilidad de instancia, intercambio y reembolso—, en qué se diferencian de los planes de ahorro, cuándo tolera una carga las instancias de acceso puntual, cómo se reutilizan licencias con Azure Hybrid Benefit, qué son los niveles de desarrollo y pruebas, y la decisión de compra completa de Contoso con su tabla de ahorro y su punto de equilibrio. Y sobre todo verás el riesgo, porque este es el único capítulo del módulo donde equivocarse cuesta dinero de verdad: reservar antes de estabilizar la arquitectura es la forma más cara que existe de ahorrar.

Recordatorio: todas las cifras y porcentajes de descuento de esta lección son orientativos y ficticios. Los descuentos reales dependen del servicio, la región, la SKU, el plazo, la moneda y tu acuerdo comercial, y cambian con frecuencia. Consulta siempre la calculadora oficial y la página de precios del servicio antes de comprar nada.

1. El principio: flexibilidad frente a precio
2. Instancias reservadas
3. Flexibilidad de instancia y cómo se aplica el descuento
4. Intercambio, reembolso y cancelación
5. Planes de ahorro de Azure
6. Reserva o plan de ahorro: criterios de decisión
7. Instancias de acceso puntual
8. Azure Hybrid Benefit
9. Niveles de desarrollo y pruebas
10. La decisión de compra de Contoso
11. El riesgo de comprometerse
12. Utilización, seguimiento y recomendaciones automáticas
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Todo el capítulo se resume en un eje. En un extremo, el pago por uso: enciendes y apagas cuando quieras, pagas por hora, precio máximo. En el otro, el compromiso a tres años pagado por adelantado: precio mínimo, y si mañana cambias de arquitectura el dinero ya está gastado.

Los porcentajes son orientativos y varían enormemente por servicio y región. Lo que no varía es la forma de la curva: cuanto más te comprometes, menos pagas. La habilidad no está en comprometerse mucho, sino en comprometerse exactamente con la parte de la plataforma que sabes que va a seguir existiendo.

Una reserva es un compromiso de consumir una capacidad concreta —un tamaño de VM, una cantidad de vCore de SQL, unas RU/s de Cosmos DB— durante uno o tres años, a cambio de un precio por hora rebajado. Es importante entender qué no es: no es una máquina que Azure te aparta, ni te obliga a tener nada encendido. Es un descuento de facturación que se aplica automáticamente al uso que coincida con lo reservado. Si no tienes uso que coincida, esa hora se pierde.

Los parámetros de compra:

El ámbito es la decisión que más errores produce. Compartido permite que el descuento se aplique a cualquier suscripción de la cuenta de facturación, lo que maximiza la probabilidad de aprovecharlo; ámbito de una suscripción o de un grupo de recursos lo restringe, y solo tiene sentido cuando se quiere que el descuento beneficie a un centro de coste concreto —chargeback, apartado 7 de la lección anterior—. El ámbito de grupo de administración es el término medio: el descuento se aplica a cualquier suscripción dentro de ese grupo, que es lo que Contoso usa para que las reservas compradas por plataforma no se «escapen» a proyectos ajenos.

Servicios que admiten reserva (lista orientativa, cambia con el tiempo):

Y el criterio de fondo: se reserva lo que está encendido de forma sostenida. Si un recurso está apagado la mitad del tiempo —por el runbook Detener-IniciarEntornosDev, por autoescalado o porque es de temporada— la reserva paga horas que no consumes y el descuento efectivo se desmorona.

Una duda razonable al comprar una reserva de VM: ¿tengo que ejecutar exactamente ese tamaño? Para la mayoría de familias, no. La flexibilidad de tamaño de instancia hace que la reserva se exprese en «unidades» de la familia y se aplique a cualquier tamaño de la misma serie dentro de la misma región.

Ejemplo con las máquinas de Contoso (relaciones orientativas dentro de una misma serie):

Así, si Contoso compra una reserva de dos Standard_D8s_v5 para los nodos aplicaciones de aks-contoso-operaciones y meses después el equipo redimensiona a cuatro Standard_D4s_v5, el descuento sigue aplicándose íntegro: 8 unidades reservadas, 8 unidades consumidas. Eso reduce mucho el miedo a comprometerse, aunque no lo elimina: la flexibilidad opera dentro de la serie y la región, no entre series. Cambiar de la serie D a la serie E, o mover la carga a North Europe, deja la reserva sin uso al que aplicarse.

Cómo se aplica el descuento cada hora, que es lo que hay que visualizar:

1. Azure agrupa el uso de esa hora que coincide con la reserva (misma región, misma familia, dentro del ámbito).
2. Aplica el descuento hasta agotar la cantidad reservada, empezando por el uso más caro —lo que es una buena noticia: no hay que ordenar nada a mano—.
3. El uso restante se factura a pago por uso.
4. La capacidad reservada no consumida se pierde: no se acumula para la hora siguiente.

Ese cuarto punto es la razón de la regla de oro: se reserva la línea base, no la media y mucho menos el pico. Con vmss-api-disponibilidad-pro, que oscila entre 2 y 20 instancias con una media de 6, Contoso reserva 2. Las horas en que hay 6 instancias, dos van con descuento y cuatro a demanda; las horas en que hay 2, las dos van con descuento. Si hubiera reservado 6, todas las noches perdería cuatro reservas.

Las reservas no son totalmente irreversibles, pero sus salidas tienen límites que conviene conocer antes de comprar:

Dos avisos importantes. El primero: las condiciones de intercambio y reembolso han cambiado varias veces, y lo que era posible hace dos años puede no serlo hoy; verifica las condiciones vigentes en la documentación oficial en el momento de comprar, no en un artículo de blog. El segundo, más útil: planifica como si no hubiera salida. Si tu decisión de compra depende de poder deshacerla, es que aún no tienes datos suficientes para comprarla.

Un plan de ahorro de Azure para cómputo resuelve el punto débil de las reservas: la rigidez. En lugar de comprometer una capacidad concreta, comprometes un gasto por hora en cómputo.

Ejemplo: Contoso se compromete a gastar 0,80 € por hora en cómputo durante un año. A cambio, todo su consumo de cómputo hasta ese importe se factura con precios de plan de ahorro, que están rebajados respecto al pago por uso. El consumo por encima va a pago por uso; el consumo por debajo se factura igualmente hasta el compromiso —es decir, te comprometes a pagar esos 0,80 € cada hora, los uses o no—.

Lo decisivo es lo que abarca: el plan de ahorro se aplica a familias y servicios de cómputo distintos, y en regiones distintas. Una VM en West Europe, un plan de App Service Premium v3, una Container App, una Function en plan Premium y un nodo de AKS pueden consumir el mismo compromiso, y si mañana rediseñas y cambias unos por otros, el descuento sigue aplicándose. Esa es exactamente la flexibilidad que una reserva no tiene.

Un detalle importante: las reservas se aplican antes que el plan de ahorro. Si tienes las dos cosas, Azure descuenta primero lo que coincide con reservas y solo después consume el compromiso del plan. Por eso la estrategia habitual —y la de Contoso— es reservar el núcleo inmóvil y cubrir con plan de ahorro la periferia móvil, no elegir una cosa u otra.

Las instancias de acceso puntual (spot) usan capacidad sobrante de Azure con descuentos que pueden llegar al 70-90 % sobre el precio de lista. La contrapartida es dura y hay que tomársela literalmente: Azure puede desalojar la máquina con unos 30 segundos de aviso cuando necesita la capacidad o cuando el precio supera tu máximo. No hay SLA.

Lo que caracteriza a una carga apta para spot:

• Es interrumpible: si muere a mitad, se reintenta y no pasa nada grave.
• No guarda estado local: todo lo importante vive fuera de la instancia.
• No tiene compromiso de tiempo estricto con un usuario esperando al otro lado.
• Puede escalar horizontalmente: perder una de diez instancias es un contratiempo, perder la única es una caída.

En Contoso, dos cargas cumplen y ya están en spot:

Y lo que nunca va en spot en Contoso: app-contoso-reservas-pro, vmss-api-disponibilidad-pro, los nodos sistema de AKS —de los que depende el propio funcionamiento del clúster— y cualquier cosa que atienda a un pasajero en tiempo real.

--spot-max-price -1 significa «paga hasta el precio de pago por uso», que evita desalojos por precio y deja solo los desalojos por capacidad. El taint es imprescindible: sin él, el planificador colocaría cargas normales en nodos que pueden desaparecer, y el ahorro se convertiría en una incidencia. Y --min-count 0 permite que el grupo baje a cero nodos cuando no hay lotes que ejecutar, que es un ahorro adicional al del propio spot.

Azure Hybrid Benefit permite reutilizar licencias de Windows Server y SQL Server que ya tengas con Software Assurance o suscripción activa, de modo que Azure te cobra solo la infraestructura y no la licencia incluida en el precio.

Tres características que lo hacen especialmente interesante. Se acumula con las reservas: primero la reserva rebaja el precio de la infraestructura, después Hybrid Benefit quita el componente de licencia. Se activa y desactiva con un interruptor, sin migrar nada. Y no cuesta nada probarlo, porque el efecto se ve en la factura del mes siguiente.

Y ahora el aviso que no puede faltar, porque aquí no se juega dinero sino cumplimiento: activar la casilla es una declaración de que posees las licencias con la cobertura adecuada. Los requisitos —edición, número de núcleos, doble uso durante una migración, Software Assurance vigente— son responsabilidad del cliente y una auditoría puede reclamarlos. En Contoso, el interruptor no lo toca ingeniería: lo valida y lo autoriza por escrito el responsable de licencias de la organización, y esa autorización se guarda junto a la plantilla Bicep que la aplica. Ningún ahorro justifica una infracción de licencia.

Azure ofrece precios reducidos para entornos que no son de producción, mediante suscripciones de tipo Dev/Test:

Contoso Airlines - Desarrollo es una suscripción de este tipo, y su regla de uso está escrita: nada que atienda a un pasajero real vive ahí. La tentación de mover una carga «pequeña» de producción a la suscripción barata aparece siempre, y hay que cortarla la primera vez.

Con tres meses de datos de uso real en stlagocontosopro (08-02), Marta y Nuria montaron la propuesta. Cifras orientativas y ficticias, en euros mensuales:

Un ahorro del 16 % de la factura sin cambiar ni una línea de arquitectura, sin apagar nada y sin degradar ningún servicio. Es, con diferencia, la palanca de mayor relación resultado/esfuerzo de todo el módulo.

Qué se deja deliberadamente a demanda, y por qué:

Esa última fila contiene la mejor lección de la tabla: comprometer capacidad sobre datos que vas a dejar de ingerir es pagar un descuento por basura.

El punto de equilibrio. La reserva de tres años de los nodos de AKS, pagada por adelantado, cuesta 27.540 € frente a los 61.200 € que costaría el mismo uso a demanda durante 36 meses. Dividiendo el desembolso entre el coste mensual actual:

• 27.540 € ÷ 1.700 €/mes = 16,2 meses de punto de equilibrio.
• A partir del mes 17, todo es ahorro; si se abandona la carga antes, se ha perdido dinero.

La pregunta que Contoso se hizo, y que hay que hacerse siempre, no es «¿cuánto ahorro?» sino «¿estoy razonablemente seguro de que esta carga seguirá existiendo, en esta forma, dentro de 17 meses?». Para los nodos de AKS y para db-reservas, la respuesta fue sí. Para el portal en MySQL, la respuesta fue no, y por eso no se reservó.

Reservar mal es la única acción de todo este módulo que puede aumentar el coste. Los cuatro escenarios en que ocurre:

• Reservar antes de estabilizar. El equipo compra tres años de una SKU, dos meses después rediseña el componente y la reserva queda sin uso al que aplicarse. Se sigue pagando.
• Reservar el pico en vez de la línea base. La capacidad no consumida se pierde hora a hora, y el descuento efectivo puede caer por debajo del pago por uso.
• Reservar y después optimizar. Comprar la reserva y a continuación dimensionar mejor, apagar de noche o migrar a sin servidor deja la reserva colgada. El orden correcto es optimizar primero y reservar después, sobre la plataforma ya adelgazada.
• Ámbito demasiado estrecho. Una reserva con ámbito de un grupo de recursos deja de aplicarse en cuanto alguien mueve el recurso a otro grupo.

De ahí las cuatro reglas escritas de Contoso, que merecen copiarse tal cual:

1. No se reserva nada con menos de tres meses de datos de uso real.
2. No se reserva un componente con una revisión de arquitectura abierta.
3. Se optimiza primero y se reserva después.
4. Se reserva la línea base observada, no la media ni el pico.

Y una quinta de sentido común: cuando la duda es grande, 1 año en lugar de 3. Se renuncia a una parte del descuento a cambio de una opción de salida, y esa opción tiene valor.

Una reserva comprada no se olvida: se vigila. Cost Management ofrece informes de utilización de reservas —qué porcentaje de la capacidad reservada se está consumiendo cada día— y de ahorro obtenido.

Un patrón concreto que hay que reconocer: una reserva que estaba al 100 % y cae bruscamente casi siempre significa que alguien movió o redimensionó la carga sin saber que había una reserva detrás. Por eso Contoso configura una alerta sobre la utilización de reservas y anota en el README de contoso-infra qué recursos están cubiertos por un compromiso, para que quien vaya a tocarlos lo sepa antes.

Azure genera además recomendaciones de compra automáticas, visibles tanto en Cost Management como en Azure Advisor (08-04): analiza los últimos 7, 30 o 60 días de uso y propone la reserva que maximizaría el ahorro, con su porcentaje estimado.

Estas recomendaciones no se aceptan a ciegas, y hay tres motivos concretos:

• Miran hacia atrás, no hacia delante. Recomiendan tres años sobre 30 días de uso de un componente que quizá se va a retirar el trimestre que viene. Advisor no sabe lo que hay en la hoja de ruta.
• Recomiendan sobre el estado actual, no sobre el optimizado. Si una VM está sobredimensionada, la recomendación te propone reservarla sobredimensionada. Primero se corrige el tamaño (08-04), después se reserva.
• Suponen ámbito compartido y plazo largo por defecto, que es lo que maximiza el ahorro teórico y no siempre lo que conviene.

La forma correcta de usarlas: como punto de partida de una conversación entre quien conoce la hoja de ruta técnica y quien firma el desembolso. En Contoso, esa conversación es un punto fijo de la revisión mensual de costes (08-05).

• Creer que una reserva aparta capacidad. No lo hace: es un descuento de facturación. Si no ejecutas nada que coincida, la hora se pierde.
• Reservar el pico o la media. Se reserva la línea base. Con vmss-api-disponibilidad-pro, 2 y no 6.
• Reservar antes de optimizar. Dimensionar y apagar primero; comprometerse después, sobre la plataforma ya adelgazada.
• Comprometerse con una arquitectura en discusión. Si hay una revisión abierta, no se reserva.
• Ámbito de grupo de recursos por defecto. Un movimiento de recurso deja la reserva sin aplicar. Compartido o grupo de administración salvo motivo expreso.
• Dar por hecho el intercambio o el reembolso. Las condiciones cambian; planifica como si no hubiera salida.
• Activar Hybrid Benefit sin validar las licencias. Es una declaración contractual, no una casilla de optimización.
• Poner cargas en spot sin taint ni tolerancia en AKS: el planificador colocará ahí lo que no debe.
• Consejo: empieza siempre por 1 año en lo que no lleve seis meses estable. El descuento menor es el precio de la opción de salida.
• Consejo: anota en contoso-infra qué recursos están cubiertos por un compromiso. Evitarás que alguien redimensione una VM reservada sin saberlo.
• Consejo: revisa la utilización de reservas una vez al mes. Una caída brusca es siempre una señal de que algo cambió.

Ejercicio 1. vmss-api-disponibilidad-pro tiene el siguiente perfil mensual: 2 instancias durante 7 horas al día, 6 instancias durante 17 horas al día, y un pico de 14 instancias durante tres semanas de verano. Cada instancia cuesta 220 €/mes orientativos a demanda. Decide qué cantidad reservar y con qué plazo, y calcula el ahorro aproximado y el que se habría perdido reservando 6.

Ejercicio 2. Contoso Millas (centro-coste=CC-2077) lleva cuatro meses en producción con una App Service Premium v3, un PostgreSQL flexible de 2 vCore, blobs y una Function en plan de consumo. El proyecto tiene aprobación de negocio para dos años, pero se está evaluando migrar la web a Container Apps. Propón la estrategia de compromiso completa, indicando qué reservar, qué cubrir con plan de ahorro y qué dejar a demanda.

Ejercicio 3. Azure Advisor recomienda una reserva de 3 años sobre seis Standard_D8s_v5 de aks-contoso-operaciones con un ahorro estimado del 45 %. Sabes que: el grupo aplicaciones está sobredimensionado y funciona al 20 % de CPU, hay una migración a Standard_D4s_v5 planificada para dentro de dos meses, y el clúster seguirá existiendo al menos tres años. ¿Aceptas, pospones o rechazas? Justifícalo con números.

Solución 1: la línea base real es 2, porque es el mínimo que hay en cualquier momento del mes. Reservando 2 instancias a 1 año con un descuento orientativo del 30 %: 2 × 220 € × 30 % ≈ 132 €/mes de ahorro, con una utilización del 100 % porque nunca hay menos de 2 instancias funcionando. Reservando 6, la aritmética se estropea: durante las 7 horas nocturnas solo hay 2 instancias, así que 4 reservas se pierden cada noche; sobre un mes, la utilización cae a aproximadamente (7×2 + 17×6) / (24×6) ≈ 81 %, y el descuento efectivo sobre el gasto total baja en consecuencia, además de haber inmovilizado un compromiso mayor. El pico de verano no se reserva jamás: son tres semanas al año, y una reserva pagaría esa capacidad las 49 semanas restantes. Plazo: 1 año, porque el autoescalado y el perfil apertura-temporada-verano todavía se están ajustando y porque el ahorro adicional de 3 años sobre 440 € de base no compensa la rigidez. Regla generalizable: reserva el mínimo del percentil más bajo observado, nunca la media.

Solución 2: reservar el PostgreSQL flexible de 2 vCore a 1 año —lleva cuatro meses estable, no está en discusión, el negocio tiene horizonte de dos años y el servidor está encendido 24x7—, con ahorro orientativo del 20-25 % sobre el cómputo; el almacenamiento va aparte y no se reserva. No reservar la App Service Premium v3: aunque es reservable y sería el ahorro mayor, hay una migración a Container Apps en evaluación, y la regla 2 de Contoso lo prohíbe expresamente. En su lugar, plan de ahorro de cómputo a 1 año dimensionado por debajo del gasto actual de la App Service —por ejemplo, al 70 % del gasto horario observado—: se obtiene un descuento menor pero sobrevive a la migración, porque Container Apps también consume el plan. Dejar a demanda: la Function en plan de consumo, cuyo coste es proporcional al uso y no admite este tipo de compromiso, y los blobs, cuyo volumen aún crece y no tiene línea base fiable. Añadir capacidad reservada de Storage solo cuando el crecimiento se estabilice. Y una comprobación previa: el ámbito de todos los compromisos debe ser compartido o de grupo de administración, no de grupo de recursos, porque el proyecto todavía reorganiza sus grupos. Ahorro esperable: modesto en euros absolutos, pero sin ningún riesgo de quedarse con un compromiso huérfano.

Solución 3: se pospone, y la aritmética lo demuestra. Aceptar la recomendación significa comprometer tres años de seis Standard_D8s_v5; dos meses después, la migración a Standard_D4s_v5 reduce a la mitad las unidades consumidas. Gracias a la flexibilidad de tamaño de instancia la reserva no se pierde —seis D8s son 24 unidades y doce D4s serían también 24—, pero si el redimensionamiento es a seis D4s (12 unidades), la utilización cae al 50 % y se estarán pagando 34 meses de capacidad que nadie consume. Traducido: sobre 1.700 €/mes de gasto actual, la mitad de la reserva ociosa desperdicia del orden de 380 €/mes durante casi tres años, más de lo que ahorraría la parte bien aprovechada. La secuencia correcta es la regla 3: primero optimizar, después reservar. Se aplica el redimensionamiento a D4s en los dos meses previstos, se observan 30 días de uso ya optimizado, se identifica la nueva línea base y entonces se compra la reserva de 3 años sobre esa base —el clúster seguirá existiendo, así que el plazo largo está justificado—. Mientras tanto, si se quiere capturar algo de descuento sin riesgo, cabe un plan de ahorro de cómputo pequeño, dimensionado sobre el gasto que se mantendrá con seguridad tras la migración. Y se anota en el seguimiento de la revisión mensual, para que la decisión no se pierda.

Ya tienes interiorizado el eje que gobierna todo el capítulo: flexibilidad y precio son inversos, y la habilidad no consiste en comprometerse mucho, sino en comprometerse exactamente con la parte de la plataforma que sabes que seguirá existiendo. Conoces las instancias reservadas con todos sus parámetros —plazo de 1 o 3 años, pago por adelantado o mensual sin penalización, ámbito compartido, de suscripción, de grupo de recursos o de grupo de administración, cantidad y región—, la lista de servicios que las admiten, y las dos claves de funcionamiento que evitan casi todos los errores: la flexibilidad de tamaño de instancia dentro de la serie y la región, y el hecho de que la capacidad reservada no consumida se pierde cada hora, de donde sale la regla de reservar la línea base y nunca el pico. Sabes también qué salidas existen —cambio de ámbito, división, intercambio restringido, reembolso limitado— y que hay que planificar como si no hubiera ninguna.

Distingues los planes de ahorro de las reservas: compromiso de gasto por hora frente a compromiso de capacidad concreta, aplicable entre series, servicios y regiones de cómputo, con menor descuento a cambio de mucha más flexibilidad, y aplicándose siempre después de las reservas —por lo que la estrategia sensata es reservar el núcleo inmóvil y cubrir con plan de ahorro la periferia móvil—. Sabes cuándo una carga tolera instancias de acceso puntual y cómo se configuran con su taint en el grupo lotes de aks-contoso-operaciones, y cuándo no debe usarse jamás. Entiendes Azure Hybrid Benefit, que se acumula con las reservas y se activa con un interruptor, con el aviso ineludible de que su cumplimiento lo valida el responsable de licencias, no ingeniería. Y sitúas los niveles de desarrollo y pruebas con su requisito de suscriptores de Visual Studio y su prohibición contractual de alojar producción.

Tienes además la decisión completa de Contoso: unos 2.900 € al mes, el 16 % de la factura, sin cambiar arquitectura, sin apagar nada y sin degradar ningún servicio, repartidos entre reservas de tres años sobre AKS, App Service y el cómputo de db-reservas, reservas de un año sobre la línea base del VMSS, Cosmos y Storage, un plan de ahorro para la periferia y Hybrid Benefit; con lo que se deja deliberadamente a demanda y el porqué de cada exclusión, y con un punto de equilibrio de 16,2 meses que convierte la pregunta económica en una pregunta técnica: ¿seguirá existiendo esta carga, así, dentro de diecisiete meses? Y llevas las cuatro reglas que impiden que el ahorro se convierta en pérdida —tres meses de datos, ninguna arquitectura en discusión, optimizar antes de reservar, línea base y no media—, más el seguimiento de la utilización y el criterio para no aceptar a ciegas las recomendaciones automáticas, que miran hacia atrás y sobre el estado sin optimizar.

Y ahí queda el hilo suelto que abre la lección siguiente. Dos de las tres razones para desconfiar de una recomendación de compra apuntan al mismo sitio: antes de comprometerse hay que optimizar, y para optimizar hace falta saber qué está mal dimensionado, qué está huérfano y qué lleva meses encendido sin que nadie lo use. Azure lo sabe y lo dice gratis. Azure Advisor analiza tu suscripción real —no da consejos genéricos— y produce recomendaciones de fiabilidad, seguridad, excelencia operativa, rendimiento y coste: la VM al 3 %, los discos que nadie desasoció, las IP públicas reservadas y olvidadas, las instantáneas de hace un año, las puertas de enlace sin conexiones. Es el desperdicio silencioso, y en la lección siguiente lo vas a encontrar entero: con Advisor primero, y después con las consultas de Azure Resource Graph que descubren lo que Advisor no ve.