La lección anterior terminó con una regla incómoda: antes de comprometerse hay que optimizar, porque reservar un recurso sobredimensionado es pagar tres años por un error. Pero para optimizar hace falta saber qué está mal dimensionado, qué lleva meses encendido sin que nadie lo use y qué se quedó atrás en una migración que terminó hace un año. En una plataforma con cincuenta y tantos recursos repartidos en dos suscripciones, esa información no la tiene nadie en la cabeza.

La tiene Azure. Azure Advisor analiza continuamente los recursos reales de tus suscripciones y produce recomendaciones concretas —con nombre de recurso, motivo y ahorro estimado— en cinco categorías. Es gratuito, no requiere ninguna configuración previa y está en el portal desde el primer día, que es exactamente la razón por la que casi nadie lo mira: no hay que activarlo, así que no hay ningún momento en el que alguien decida usarlo.

Esta lección lo recorre entero: las cinco categorías y su correspondencia con los pilares del Well-Architected Framework, la puntuación y cómo interpretarla sin obsesionarse, las recomendaciones de coste en detalle —infrautilización, recursos huérfanos, cambio de tamaño y compra de reservas—, el recorrido completo de lo que Advisor le dice a Contoso y qué hace el equipo con cada recomendación, los casos en que Advisor se equivoca, su automatización con CLI y API, su configuración, y por último el desperdicio que Advisor no ve y que hay que ir a buscar con Azure Resource Graph.

Recordatorio: todas las cifras en euros son orientativas y ficticias. Los precios reales varían por región y cambian con frecuencia; consúltalos en la calculadora oficial.

1. Qué es Advisor y por qué es el punto de partida
2. Las cinco categorías y los pilares del Well-Architected Framework
3. La puntuación de Advisor
4. Las recomendaciones de coste en detalle
5. El recorrido de Contoso: aplicar, posponer o descartar
6. Cuándo Advisor se equivoca
7. Consultar y automatizar Advisor
8. Configuración: exclusiones, umbrales y ámbito
9. Integración con Defender for Cloud y Cost Management
10. El desperdicio que Advisor no ve: Azure Resource Graph
11. El informe mensual de Marta
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Advisor es un motor de recomendaciones que evalúa la configuración y la telemetría reales de tus recursos contra un conjunto de buenas prácticas de Microsoft. La diferencia con cualquier lista de consejos publicada en internet es sustancial:

Tres propiedades que conviene tener claras desde el principio. Advisor solo lee: no cambia nada por su cuenta, sus recomendaciones son propuestas y aplicarlas es siempre una acción explícita. Necesita tiempo y datos: las recomendaciones de infrautilización se basan en ventanas de observación de días, así que en una suscripción recién creada aparecerán pocas. Y su cobertura no es total: hay desperdicio que Advisor no detecta, y por eso existe el apartado 10.

La correspondencia con el Well-Architected Framework no es casual: Advisor es, en la práctica, la implementación automatizada de una parte del marco sobre tus recursos reales. El marco completo —sus principios, sus preguntas de revisión y sus compromisos entre pilares— se trata en la lección 09-02; aquí basta con retener la idea de que las cinco categorías no son independientes y a menudo tiran en direcciones opuestas. Una recomendación de coste que propone eliminar una réplica choca de frente con una de fiabilidad que pide redundancia. Advisor presenta ambas sin resolver el conflicto, porque resolverlo requiere conocer el negocio. Ese arbitraje es el trabajo del arquitecto, no de la herramienta.

Advisor calcula una puntuación de 0 a 100 global y por categoría, ponderando el impacto potencial de las recomendaciones pendientes sobre el consumo de los recursos afectados. Sirve para dos cosas legítimas: medir la tendencia en el tiempo y comparar suscripciones o equipos.

Y conviene decir con claridad para qué no sirve, porque el uso indebido de esta métrica hace daño real:

• No es un objetivo en sí misma. Perseguir el 100 % lleva a aplicar recomendaciones que no proceden solo para que desaparezcan de la lista.
• No es comparable entre organizaciones. Depende de la composición de tus recursos.
• Baja al crecer. Desplegar recursos nuevos genera recomendaciones nuevas; una caída puede significar que el equipo está construyendo, no empeorando.
• Descartar una recomendación con motivo sube la puntuación, y eso está bien: es la forma de decirle a la herramienta que ya has decidido.

En Contoso, la puntuación de coste pasó de 61 a 84 en dos meses. Nuria preguntó, con razón, cuántos euros eran esos 23 puntos. La respuesta honesta fue: los euros están en la tabla del apartado 5; la puntuación es un indicador de proceso, no de resultado. La cifra que se lleva al comité es el ahorro en euros; la puntuación se usa internamente para ver si el equipo está atendiendo la lista o dejándola crecer.

Las recomendaciones de la categoría de coste caen en cuatro grupos, y merece la pena conocerlos porque cada uno se decide de forma distinta.

Recursos infrautilizados. Advisor observa la CPU y la red de las máquinas virtuales durante una ventana configurable (7, 14, 21, 30, 60 o 90 días) y marca las que se mantienen por debajo de un umbral. Propone apagar o redimensionar. Es la recomendación con más ahorro potencial y también la que más juicio exige, porque una máquina al 3 % puede ser un desperdicio o puede ser un servidor de licencias que hace muy poco pero es imprescindible.

Recursos huérfanos: el desperdicio silencioso. Son recursos que siguen facturando sin estar asociados a nada. No dan error, no aparecen en ninguna alerta y nadie los echa de menos:

Cambio de tamaño y de SKU. Advisor propone bajar de nivel bases de datos con uso bajo, cambiar a SKU más modernas y baratas (por ejemplo, de una serie antigua a su equivalente actual con mejor relación precio/rendimiento), o pasar a niveles sin servidor donde el patrón lo justifica.

Recomendaciones de compra de reservas y planes de ahorro. Son las mismas que se ven en Cost Management y se rigen por lo que ya sabes de 08-03: no se aceptan a ciegas, porque miran hacia atrás y calculan sobre el estado sin optimizar.

Marta abrió Advisor sobre las dos suscripciones y trabajó la lista entera. Cada recomendación termina en una de tres decisiones, y las tres son respuestas válidas siempre que quede constancia del motivo:

Cuatro observaciones sobre esa tabla, que son las que hacen que el ejercicio valga la pena:

• Ninguna de las acciones aplicadas afecta a un recurso que alguien estuviera usando. Es desperdicio puro: 457 € al mes, 5.484 € al año, por limpiar.
• Las dos recomendaciones descartadas son técnicamente correctas y económicamente equivocadas, y solo un humano con contexto podía saberlo (apartado 6).
• Posponer es una decisión, no una evasiva, siempre que tenga fecha y motivo. Las tres pospuestas tienen ambas cosas.
• Los huérfanos volverán a aparecer. Esto no es un proyecto que se termina; es una revisión mensual (apartado 11).

Antes de aplicar nada, la salvaguarda que Contoso escribió: instantánea de 30 días antes de borrar cualquier disco, y verificación de que ninguna IP pública tiene un registro DNS apuntando. Borrar un disco huérfano es irreversible, y ahorrar 9 € para provocar una restauración de dos días es un mal negocio.

Advisor no se equivoca en los datos: se equivoca en el contexto, porque no lo tiene. Los patrones en los que hay que desconfiar:

• Estacionalidad. La recomendación 9 propone reducir vmss-api-disponibilidad-pro porque su CPU media es baja. Es cierto y es irrelevante: la API existe para soportar la apertura de la temporada de verano, cuando el autoescalado sube a 14 instancias y cada una necesita su tamaño. Una recomendación calculada sobre 30 días de febrero no puede saberlo.
• Recursos deliberadamente inactivos. disk-motor-datos-copia es una copia intencionada previa a una migración de motor. Para Advisor es un disco huérfano; para el equipo es una red de seguridad con fecha de caducidad.
• Infraestructura de contingencia. Todo el piloto ligero de North Europe (07-05) está, por definición, infrautilizado. Esa es su función.
• Cargas de arranque en frío. Una instancia mínima siempre activa en ca-motor-disponibilidad está casi ociosa, y existe precisamente para que la primera petición no espere.
• Ventanas de observación cortas. Un proceso que se ejecuta el día 1 de cada mes es invisible en una ventana de 14 días.

La conclusión, que vale para cualquier herramienta de recomendación automática: Advisor propone; una persona con contexto decide. Y cuando decida descartar, debe hacerlo con la función de descarte de la propia herramienta, indicando el motivo y una fecha de revisión. Descartar «para siempre» y en silencio convierte la lista en ruido; descartar con motivo y con caducidad la mantiene útil.

extendedProperties es donde viven los datos interesantes y su contenido varía según el tipo de recomendación: annualSavingsAmount, savingsCurrency, targetSku, currentSku, region. Merece la pena inspeccionar una recomendación completa con -o json la primera vez, para saber qué campos hay.

Para automatizar el informe mensual, Contoso ejecuta esto desde un runbook de aa-contoso-operaciones (07-04) el día 1 de cada mes, deja el resultado en stlagocontosopro y publica el resumen en Teams:

Existen además alertas de recomendaciones nuevas: se configura una regla que notifica cuando Advisor genera una recomendación de una categoría e impacto determinados, con destino a un grupo de acciones. Contoso la tiene sobre recomendaciones de coste de impacto Alto, dirigida a ag-equipo-contoso, el mismo grupo de acciones de 07-01 y de los presupuestos de 08-02. Un consejo práctico: no alertes sobre recomendaciones de impacto bajo o medio, o el canal se llenará de ruido y dejará de leerse en una semana.

Y una advertencia con la API de Advisor: las recomendaciones se recalculan periódicamente, y sus identificadores no son estables entre generaciones. Un script que guarde identificadores para compararlos de un mes a otro no funcionará; hay que comparar por recurso y tipo de recomendación.

Advisor se configura, y hacerlo bien es lo que separa una lista útil de una lista que nadie mira:

Las dos decisiones que más rendimiento dan. Un umbral distinto por entorno: en desarrollo interesa un umbral alto, porque cualquier máquina por debajo del 20 % probablemente esté sobredimensionada y el riesgo de redimensionarla es nulo; en producción interesa un umbral bajo y conservador, porque un falso positivo cuesta una incidencia. Y una ventana larga en producción: con 14 días, la estacionalidad de una aerolínea genera recomendaciones absurdas cada temporada baja.

Las reglas de exclusión conviene usarlas con moderación. Excluir un recurso lo saca del radar para siempre y en silencio, mientras que descartar una recomendación con fecha la devuelve a la lista cuando toca. La exclusión es para infraestructura cuya naturaleza es estar ociosa —contingencia, arranque en frío—; el descarte es para todo lo demás.

Advisor no calcula todo lo que muestra: es también un escaparate de otros servicios.

Las consecuencias prácticas de ese diagrama: la categoría de seguridad de Advisor es la puntuación de seguridad de Defender for Cloud, así que se trabaja allí y no aquí —los planes de pago del módulo 4 amplían mucho lo que se detecta—; y las recomendaciones de compra de reservas son las mismas de Cost Management, calculadas por el mismo motor, así que da igual desde dónde se miren, pero se deciden con los criterios de 08-03.

Advisor cubre bien lo estándar, pero hay desperdicio que no detecta: recursos sin etiquetar que no se pueden imputar, entornos de desarrollo encendidos de noche, recursos creados fuera de las regiones permitidas, o cualquier convención propia de la organización. Para eso está Azure Resource Graph (07-04), que consulta el inventario completo con KQL en segundos.

Discos huérfanos, con su tamaño y su nivel —incluye los que Advisor aún no ha procesado—:

Recursos sin las etiquetas obligatorias, que es el origen del cubo «sin imputar» de 08-02:

IP públicas sin asociar y equilibradores sin backend, en una sola consulta:

Entornos de desarrollo que deberían estar apagados: máquinas etiquetadas horario=laborable que están en ejecución. Ejecutada por la mañana confirma que el runbook las encendió; ejecutada de madrugada revela las que se le escaparon.

Cuentas de almacenamiento sin contenido reciente y recursos fuera de región, dos comprobaciones más de higiene:

Estas consultas viven versionadas en contoso-infra junto a las plantillas Bicep, y esa es una recomendación importante: una consulta de desperdicio que solo existe en el historial del portal de una persona no es un proceso. En un repositorio, cualquiera la ejecuta, se revisa en la solicitud de incorporación de cambios y evoluciona con la plataforma.

Todo lo anterior se condensa en un documento de una página que Marta lleva al comité el primer martes de cada mes, con esta estructura fija:

Dos rasgos hacen que este informe funcione donde otros mueren. Cabe en una página, así que se lee. Y incluye lo que se descartó y por qué, que es lo que impide que el comité pregunte cada mes por la misma recomendación y lo que demuestra que el equipo decide en vez de obedecer a una herramienta. La sección de acciones ejecutadas, con el ahorro real —no el estimado—, es la que construye credibilidad con finanzas: la primera vez que Nuria comprobó que los 457 € prometidos aparecían efectivamente en la factura del mes siguiente, la conversación sobre costes cambió de tono para siempre.

• No mirar Advisor nunca, precisamente porque no hay que activarlo. Es el error más común y el más barato de corregir.
• Aplicar todo lo que dice. Advisor no conoce la estacionalidad, ni la contingencia, ni tus copias deliberadas.
• Descartar en silencio y para siempre. El descarte sin motivo ni fecha convierte la lista en ruido.
• Perseguir la puntuación. Es un indicador de proceso; el resultado se mide en euros y en riesgo evitado.
• Borrar discos huérfanos sin instantánea previa. Ahorrar 9 € y provocar una restauración de dos días es un mal negocio.
• Aceptar la recomendación de compra de reserva antes de redimensionar. Se paga tres años el tamaño equivocado (08-03).
• Usar la misma ventana y el mismo umbral en desarrollo y en producción. Producen recomendaciones inútiles en un sitio y peligrosas en el otro.
• Guardar identificadores de recomendación para comparar entre meses: no son estables.
• Consejo: ejecuta hoy las consultas de discos huérfanos e IP sin asociar. Es el minuto mejor invertido de esta lección.
• Consejo: alerta solo sobre recomendaciones de coste de impacto alto. El resto se ve en la revisión mensual.
• Consejo: versiona tus consultas de Resource Graph en el repositorio de infraestructura, junto a las plantillas.

Ejercicio 1. Advisor propone para vm-motor-disponibilidad-dev bajar de Standard_D4s_v5 a Standard_D2s_v5 por CPU media del 3 % en 30 días. Enumera las comprobaciones que harías antes de aplicarlo y en qué caso concreto rechazarías la recomendación pese a que el dato sea correcto.

Ejercicio 2. Escribe una consulta de Azure Resource Graph que encuentre todas las instantáneas de disco con más de 180 días de antigüedad, mostrando nombre, grupo de recursos, tamaño, propietario y centro de coste, ordenadas por tamaño. Explica qué harías con el resultado antes de borrar nada.

Ejercicio 3. Contoso Millas (centro-coste=CC-2077) acaba de recibir sus primeras recomendaciones: reducir la SKU de su App Service (impacto medio, 40 €/mes), eliminar dos discos no asociados (18 €/mes), comprar una reserva de 3 años del PostgreSQL (impacto alto, 55 €/mes) y activar copias de seguridad en la base de datos (categoría fiabilidad, sin ahorro). Prioriza las cuatro, indica decisión y motivo, y di qué configuración de Advisor ajustarías para este proyecto.

Solución 1: comprobaciones previas. (1) Ventana y estacionalidad: 30 días pueden no cubrir un proceso mensual; ampliar la ventana a 60 o 90 días y mirar el percentil 95 de CPU, no solo la media —una máquina al 3 % de media que llega al 90 % durante dos horas cada noche está bien dimensionada—. (2) Otras dimensiones: la recomendación se basa en CPU y red, pero la máquina puede estar limitada por memoria o por IOPS de disco; hay que mirar la memoria disponible en log-contoso-pro antes de reducir un tamaño que también reduce RAM e IOPS máximas. (3) Requisitos del software: algunos motores exigen un mínimo de vCPU por licencia o configuración. (4) Impacto operativo: el cambio de tamaño exige reiniciar la máquina, así que necesita ventana, aunque en desarrollo sea trivial. (5) Coherencia con la línea base: si esa VM está cubierta por una reserva, redimensionarla puede dejarla sin uso —aquí no aplica, es desarrollo y no está reservada—. Se rechazaría, pese al dato correcto, si la máquina fuera el agente de un proceso mensual de cierre que consume toda la CPU un día al mes, o si estuviera ahí como capacidad de contingencia para asumir la carga de otro entorno. En este caso concreto —desarrollo, sin reserva, sin proceso mensual— se aplica: el riesgo es nulo y el ahorro es real.

Solución 2: la consulta y el procedimiento.

Antes de borrar: (1) agrupar por propietario y enviar a cada uno su lista, con plazo de 10 días para reclamar lo que quiera conservar —quien creó la instantánea sabe por qué—; (2) cruzar con el registro de actividad en log-contoso-pro para descartar que alguna se haya usado recientemente para crear un disco; (3) comprobar si alguna precede a una migración de esquema o a un cambio importante, que es justo la que hay que conservar; (4) etiquetar en lugar de borrar en la primera pasada, con una etiqueta caducidad=2026-10-01, y borrar en la siguiente revisión mensual lo que nadie haya reclamado; y (5) dejar constancia en el informe mensual. La instantánea sin propietario es el caso difícil: si nadie la reclama y no hay traza de uso, se borra, pero esa situación es en sí misma una recomendación de gobernanza —exigir la etiqueta propietario con una directiva Deny del módulo 4—.

Solución 3: prioridad y decisiones. Primero, activar las copias de seguridad (fiabilidad, sin ahorro): no es una recomendación de coste, pero es la única cuya ausencia puede costar el proyecto entero; el criterio de priorización nunca es solo el euro. Segundo, eliminar los discos no asociados (18 €/mes): riesgo nulo, esfuerzo mínimo, con instantánea previa de 30 días. Tercero, reducir la SKU de App Service (40 €/mes): se aplica solo si hay 60 días de datos y el percentil 95 lo respalda, y teniendo en cuenta que bajar de Premium v3 a un nivel inferior puede hacer perder ranuras de despliegue, redundancia de zona o escalado automático —hay que comprobar qué se pierde antes de mirar lo que se gana—. Cuarto y pospuesta, la reserva de 3 años del PostgreSQL (55 €/mes): es el mayor ahorro y la decisión más peligrosa, porque el proyecto tiene cuatro meses de vida y no cumple la regla de Contoso de tres meses de uso estable; se pospone 60 días y, si el consumo se confirma, se compra a 1 año en lugar de 3, dado el horizonte de negocio de dos años. Configuración de Advisor a ajustar: incluir la suscripción del proyecto en el ámbito, fijar la ventana de observación en 60 días para que la estacionalidad de canjes no genere ruido, un umbral de CPU del 10 % intermedio por tratarse de producción de bajo riesgo, y una alerta de impacto alto dirigida a ag-equipo-contoso con el responsable del proyecto como destinatario adicional.

Ya sabes qué es Azure Advisor y por qué es el punto de partida obligatorio de cualquier ejercicio de optimización: es gratuito, analiza tus recursos reales en lugar de darte consejos genéricos, cuantifica el ahorro de cada recomendación y está ahí desde el primer día. Conoces sus cinco categorías —fiabilidad, seguridad, excelencia operativa, rendimiento y coste—, su correspondencia con los cinco pilares del Well-Architected Framework que verás en 09-02, y el hecho fundamental de que tiran en direcciones opuestas: la herramienta presenta el conflicto, el arquitecto lo resuelve. Interpretas la puntuación como indicador de proceso y no como objetivo, sabiendo que baja cuando creces y que descartar con motivo es una forma legítima de subirla.

Dominas las recomendaciones de coste en sus cuatro grupos: infrautilización con su ventana y su umbral, recursos huérfanos —discos no asociados, IP públicas reservadas, instantáneas antiguas, puertas de enlace sin conexiones, equilibradores sin backend, cuentas vacías—, cambio de tamaño y de SKU, y las recomendaciones de compra que ya sabías no aceptar a ciegas. Has recorrido la lista completa de Contoso decidiendo una por una entre aplicar, posponer o descartar, con 457 € al mes de desperdicio puro eliminados sin tocar un solo recurso en uso, y con las dos recomendaciones descartadas que demuestran el límite de la automatización: la reducción de vmss-api-disponibilidad-pro, que ignora la temporada de verano, y el disco disk-motor-datos-copia, que es una copia deliberada. Advisor propone; una persona con contexto decide, y deja constancia del motivo y de la fecha de revisión.

Sabes además consultarlo y automatizarlo con CLI, alertar solo sobre el impacto alto hacia ag-equipo-contoso, y configurarlo con criterio: umbral alto en desarrollo, umbral bajo y ventana de 60 días en producción, exclusiones solo para infraestructura cuya naturaleza es estar ociosa. Sitúas su papel de escaparate de Defender for Cloud y de Cost Management. Y, sobre todo, sabes ir a buscar el desperdicio que Advisor no ve con Azure Resource Graph: discos huérfanos, recursos sin las cuatro etiquetas obligatorias, IP y equilibradores sin uso, entornos de desarrollo encendidos de madrugada pese al runbook, cuentas de almacenamiento fuera de región. Todo ello versionado en contoso-infra y condensado en el informe mensual de una página que Marta lleva al comité, con su sección de descartes y su ahorro real medido.

Con esto tienes las tres grandes fuentes de ahorro identificadas y cuantificadas: la estimación que evita el gasto antes de crearlo, el compromiso que rebaja el precio de lo que ya funciona, y la limpieza que elimina lo que no sirve a nadie. Falta lo más difícil, que no es técnico: convertir todo esto en una forma de trabajar que no dependa de que alguien se acuerde. La lección que cierra el módulo trata de FinOps: sus tres fases y sus tres protagonistas —Nuria, Marta y Diego—, el catálogo completo de palancas de optimización consolidando todo lo aprendido en el curso, el compromiso consciente entre coste, fiabilidad, rendimiento y seguridad, el plan priorizado de Contoso con su tabla de antes y después, el coste unitario como indicador que de verdad importa, la revisión mensual como proceso de gobierno, y los anti-patrones que arruinan cualquier iniciativa de optimización —empezando por el más caro de todos: ahorrar cincuenta euros a costa de veinte horas de ingeniería—.