Contoso Airlines tiene ya todas las piezas sueltas: sabe estimar antes de desplegar, sabe qué gastó y de quién es, sabe qué compromisos comprar y sabe dónde está el desperdicio. Lo que no tiene todavía es lo más difícil, que no es técnico: una forma de trabajar en la que el coste se gestione solo, sin depender de que alguien se acuerde. Porque la optimización que se hace una vez se deshace sola en seis meses. Vuelven los discos huérfanos, vuelve el entorno encendido de noche, vuelve la ingesta de registros que nadie consulta, y el trimestre siguiente Nuria vuelve a preguntar lo mismo.

Esta lección cierra el módulo con ese salto: de las herramientas a la cultura FinOps. Verás sus tres fases y los tres papeles que la sostienen —Nuria, Marta y Diego—, el catálogo completo de palancas de optimización que consolida todo lo aprendido en el curso, el compromiso consciente entre coste y fiabilidad, rendimiento y seguridad, con los recortes que Contoso rechaza deliberadamente, el plan priorizado con su tabla de antes y después, el coste unitario como el indicador que de verdad importa, la revisión mensual como proceso de gobierno, el coste dentro del ciclo de vida del desarrollo, y los anti-patrones que arruinan cualquier iniciativa de ahorro.

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

1. Qué es FinOps y por qué es cultura, no herramienta
2. Las tres fases y los tres papeles
3. El catálogo completo de palancas de optimización
4. El compromiso: coste frente a fiabilidad, rendimiento y seguridad
5. Los recortes que Contoso rechaza
6. El plan de optimización de Contoso
7. Antes y después
8. Coste unitario: el indicador que importa
9. La revisión mensual de costes
10. Políticas que previenen el gasto
11. El coste en el ciclo de vida del desarrollo
12. Anti-patrones de la optimización
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

FinOps es una disciplina operativa para gestionar el gasto en la nube: un conjunto de prácticas que llevan la responsabilidad económica al equipo que toma las decisiones técnicas, con datos compartidos y en tiempo casi real. No es un producto, no es un panel y no se compra.

La razón por la que hace falta es estructural y ya apareció en 08-01: en la nube, quien gasta el dinero es el ingeniero, no el departamento de compras. Un modelo de control en el que finanzas aprueba y después ingeniería ejecuta no funciona cuando la ejecución tarda tres segundos. Solo quedan dos opciones: bloquear a la gente con procesos de aprobación que destruyen la agilidad que justificaba la nube, o dar a la gente el dato y la responsabilidad. FinOps es la segunda.

Los tres principios que lo resumen:

• Visibilidad: cada equipo ve lo que gasta, con detalle suficiente para actuar y sin pedirlo a nadie.
• Responsabilidad: el equipo que decide es el que responde de su factura, y tiene margen para decidir.
• Optimización continua: no es un proyecto trimestral, es una rutina mensual con dueños y fechas.

Y el motivo por el que se insiste en que es cultura: las tres cosas que más ahorraron a Contoso no fueron técnicas. Fueron un etiquetado que permite saber de quién es cada euro, una revisión mensual de una hora en la que alguien tiene que explicar sus cifras, y la costumbre de adjuntar una estimación a cada propuesta de arquitectura. Las herramientas ejecutan; la cultura es la que hace que alguien las mire.

El ciclo se recorre continuamente y no se puede saltar la primera fase: optimizar sin informar es adivinar. Contoso tardó dos meses en la fase de informar —etiquetado, política hereda-centro-coste, vistas, presupuestos, exportaciones— antes de tocar un solo recurso, y ese fue el motivo de que la fase de optimizar durase tres semanas en lugar de seis meses.

Los tres papeles, con nombre propio:

La disfunción clásica es que solo participen dos de los tres. Si faltan finanzas, el equipo optimiza sin saber si importa. Si falta ingeniería, se fijan topes que rompen producción. Y si falta negocio —el caso más frecuente— se recorta lo técnicamente fácil en lugar de lo económicamente irrelevante, que rara vez coinciden.

Esta es la tabla que consolida todo el curso. Cada fila es una palanca vista en algún módulo anterior, aquí puesta en su sitio económico.

Dos formas de leer esta tabla. En vertical, es la lista de todo lo que puedes tocar. En horizontal, es un aviso: la columna de riesgo dice que las palancas más rentables no son las más seguras, y que hay tres filas —redundancia, retención de copias y muestreo— donde ahorrar significa aceptar más riesgo, no eliminar desperdicio. Esa distinción es el tema del apartado siguiente.

Hay dos clases de optimización, y confundirlas es el origen de casi todos los desastres:

La primera columna se ejecuta sin pedir permiso: nadie tiene que aprobar que se borre una IP pública que no está asociada a nada. La segunda nunca la decide ingeniería en solitario, porque no es una decisión técnica: es un intercambio de dinero por riesgo, y el riesgo lo asume el negocio.

La forma de plantear correctamente un compromiso ante quien debe decidirlo tiene tres partes: cuánto se ahorra, qué se pierde exactamente y qué pasa el día que eso importe. Formulado así, la mayoría de recortes discutibles se caen solos. Formulado como «podemos ahorrar 190 € al mes en almacenamiento», casi todos se aprueban, y nadie recuerda por qué el día del incidente.

Estas propuestas aparecieron en la revisión y se rechazaron por escrito, que es tan importante como lo que sí se hizo:

Contoso podría haber bajado su factura otros 2.555 € al mes aplicando esta lista. Decidió no hacerlo, y lo escribió. Ese documento tiene más valor del que parece: cuando dentro de un año alguien pregunte por qué se paga GZRS, la respuesta estará escrita con su fecha y su firma, y nadie tendrá que reconstruir el razonamiento desde cero. Un equipo maduro no es el que más recorta: es el que sabe qué no recorta y por qué.

Partiendo de la factura analizada de julio —17.800 €—, el equipo priorizó las acciones por ahorro, riesgo y esfuerzo. Cifras orientativas y ficticias:

El criterio de ordenación no fue el ahorro absoluto, sino la relación ahorro ÷ (riesgo × esfuerzo), y por eso la acción 3 —457 € de limpieza sin riesgo ni esfuerzo— se ejecutó antes que la 1, pese a ahorrar seis veces menos. Hay además una dependencia dura entre ambas: la regla 3 de 08-03 exige optimizar antes de comprometerse, así que la limpieza y el redimensionamiento tenían que ir primero para que la reserva se comprara sobre la plataforma ya adelgazada.

Y una advertencia sobre la aritmética que conviene hacer siempre: estos ahorros no son perfectamente aditivos. La acción 2 reduce la ingesta y con ella la base sobre la que se calcularía un futuro compromiso de capacidad; la acción 4 reduce el egress pero también las transacciones de Storage, solapándose ligeramente con la 5. La estimación honesta que Contoso llevó al comité no fue una cifra sino un intervalo: entre 12.400 € y 13.000 € al mes, y el nuevo presupuesto se fijó en 13.000 € para no prometer el mejor caso.

Tres lecturas. Ningún servicio se degradó: los tiempos de respuesta, la disponibilidad y el RPO/RTO son idénticos antes y después, y así se verificó con los paneles del módulo 7 durante las cuatro semanas siguientes. Más de la mitad del ahorro vino de dos sitios —compromisos y observabilidad—, coherente con la regla de optimizar de arriba abajo. Y fw-contoso-hub-pro sigue costando lo mismo, porque no todo lo caro es optimizable, y reconocerlo es parte del trabajo.

Un total absoluto es un mal indicador, porque no distingue entre gastar más por crecer y gastar más por desperdiciar. El indicador que sí distingue es el coste unitario: coste dividido por unidad de valor de negocio. En una aerolínea, coste por reserva vendida.

La tercera fila es la que cambia la conversación en el comité. La factura de agosto sube un 10 % respecto a julio y, mirada en absoluto, parece un fracaso. Mirada en coste unitario, es la mejor noticia del año: la plataforma absorbió un 60 % más de reservas con un 10 % más de gasto, es decir, escala con eficiencia creciente. Una factura que sube puede ser una excelente noticia, y sin coste unitario no hay forma de demostrarlo.

El indicador se calcula uniendo la exportación diaria de coste de stlagocontosopro (08-02) con la tabla de reservas, en syn-contoso-analitica-pro:

Contoso publica tres indicadores unitarios: coste por reserva vendida, coste por tarjeta de embarque emitida y coste por millón de peticiones a la API de disponibilidad. Cada uno tiene dueño, y los tres se revisan mensualmente. La regla que los gobierna: el objetivo no es que la factura baje; es que el coste unitario baje. Si el negocio crece un 40 % y la factura crece un 15 %, el equipo ha hecho un trabajo excelente aunque Nuria pague más que el mes pasado —y lo sabe, porque el indicador se lo enseña—.

El proceso que sostiene todo lo demás cabe en una hora al mes:

Cuatro reglas aprendidas por las malas y que marcan la diferencia entre una reunión útil y una ceremonia:

• Se envía el informe antes. Una reunión que empieza leyendo datos no toma decisiones.
• Toda acción tiene nombre y fecha. «Habría que mirar el tema de los registros» no es una acción.
• Se compara el ahorro prometido con el realizado. Es el punto que da credibilidad, y también el que destapa las estimaciones optimistas.
• Se celebra el coste unitario, no la factura. Si se premia bajar la factura, alguien acabará frenando el crecimiento del negocio para conseguirlo.

La optimización más barata es la que evita el gasto antes de que exista, y para eso están las directivas del módulo 4, aplicadas desde la iniciativa «Base de gobernanza de Contoso»:

Ese último matiz merece atención porque es el bucle completo del módulo: una directiva pensada para mejorar la observabilidad crea gasto en log-contoso-pro. No es un argumento para no tenerla; es un argumento para desplegarla con las categorías de registro elegidas conscientemente, en lugar de activarlas todas.

Y una advertencia sobre el equilibrio: una directiva Deny demasiado estricta se convierte en una cola de excepciones que alguien tiene que aprobar, y eso reintroduce exactamente la fricción que la nube venía a eliminar. Contoso mantiene una lista corta de Deny —regiones, tamaños desproporcionados, etiquetas— y usa Audit para todo lo demás, revisando el resultado en la reunión mensual.

Que el coste sea un criterio de diseño y no una auditoría posterior exige integrarlo en cuatro puntos del proceso, todos ya vistos:

La pieza con más efecto cultural es la tercera. Cuando la solicitud de incorporación de cambios muestra automáticamente que subir la SKU de una base de datos son 380 € al mes (08-01), la conversación sobre coste ocurre entre dos ingenieros, en el momento en que cambiarlo cuesta editar una línea, y sin que nadie tenga que hacer de policía. El coste deja de ser una auditoría y se convierte en información de diseño, que es todo el objetivo de FinOps.

El tercero merece un comentario aparte porque es el más frecuente entre equipos técnicos motivados. Una jornada de ingeniería tiene un coste que suele estar en el orden de varios cientos de euros; dedicar veinte horas a un ahorro de 50 € al mes tarda casi un año en amortizarse, tiempo durante el cual esas veinte horas podrían haber estado en otra cosa. Antes de optimizar algo, estima cuánto cuesta optimizarlo. Es la misma disciplina de 08-01 aplicada al propio trabajo.

• Creer que FinOps es una herramienta. Se compra un panel y no cambia nada; lo que cambia las cosas es la revisión mensual con dueños.
• Confundir eliminar desperdicio con aceptar un compromiso. Lo primero se ejecuta; lo segundo se decide con el negocio y se escribe.
• Optimizar sin verificar después. Se aplica el cambio y nadie comprueba si el ahorro apareció en la factura.
• Medir solo la factura total. Sin coste unitario no se distingue crecer de desperdiciar.
• Recortar observabilidad a ciegas. Es la partida más fácil de tocar y la que te deja sin instrumentos.
• No escribir lo que se rechaza. Dentro de un año nadie recordará por qué se paga GZRS.
• Automatizar apagados sin salvaguardas por etiqueta. Un runbook mal filtrado apaga producción un martes.
• Consejo: fija hoy la revisión mensual en el calendario, aunque el primer informe sea malo. La rutina crea el dato, no al revés.
• Consejo: publica el coste unitario en el mismo panel donde el equipo mira la latencia. Lo que se ve, se gestiona.
• Consejo: guarda un registro de decisiones de coste —aplicadas y rechazadas— junto a las plantillas de contoso-infra.

Ejercicio 1. La factura de Contoso Millas (centro-coste=CC-2077) es de 1.240 €/mes: App Service Premium v3 (420 €), PostgreSQL flexible con alta disponibilidad (390 €), Log Analytics (180 €), blobs de justificantes en GZRS (140 €) y Functions en consumo (110 €). El proyecto tiene 6.000 canjes al mes y un presupuesto de 900 €. Propón un plan priorizado con ahorro, riesgo y esfuerzo, indica qué no recortarías y calcula el coste unitario antes y después.

Ejercicio 2. Un ingeniero propone reducir la retención de log-contoso-pro de 90 a 7 días, ahorrando 480 €/mes. Analiza la propuesta: qué se pierde, qué alternativas hay con el mismo ahorro y menor impacto, y cómo la plantearías al comité si aun así hubiera que hacerla.

Ejercicio 3. Diseña la reunión mensual de costes de una empresa de 40 personas con una sola suscripción y 4.000 €/mes de factura. Define asistentes, duración, orden del día, indicadores y qué automatizarías para que el informe se prepare solo.

Solución 1: coste unitario de partida: 1.240 € ÷ 6.000 canjes = 0,207 €/canje. Plan priorizado. (1) Log Analytics (180 €): aplicar las tres palancas de 07-02 —revisar con Usage qué tablas se ingieren, pasar los registros de contenedor o de aplicación no investigados a plan Basic y ajustar la retención por tabla—; ahorro estimado 90 €, riesgo bajo, esfuerzo medio; es la partida con mejor relación ahorro/riesgo. (2) PostgreSQL (390 €): la alta disponibilidad con redundancia de zona duplica el cómputo; esto es un compromiso, no desperdicio, así que lo decide negocio —si un programa de fidelización tolera unas horas de indisponibilidad, desactivarla ahorra unos 180 €; si no, se mantiene y se busca en otro sitio—. En paralelo, sí es desperdicio puro comprobar el dimensionamiento y reservar a 1 año si el uso lleva tres meses estable (unos 60 € más). (3) App Service (420 €): comprobar si Premium v3 es necesario por redundancia de zona y ranuras o si se eligió por inercia; si el proyecto tolera un nivel inferior, el ahorro es grande, pero se pierden ranuras y escalado —de nuevo, compromiso—. (4) Blobs GZRS (140 €): pasar a ZRS ahorra parte, pero los justificantes de canje pueden tener valor probatorio; no se recorta sin consultar a legal. (5) Functions en consumo (110 €): ya está en el modelo más eficiente; no se toca. Lo que no se recorta en ningún caso: la retención mínima legal de los justificantes, y las copias de la base de datos. Resultado plausible: ~330 € de ahorro sin compromisos (Log Analytics, reserva y limpieza) → 910 €/mes, coste unitario 0,152 €/canje, un 27 % menos, prácticamente dentro del presupuesto sin degradar nada. Si el negocio acepta además renunciar a la alta disponibilidad, se baja de 900 € con holgura, pero esa decisión no la firma ingeniería.

Solución 2: qué se pierde con 7 días de retención: la capacidad de investigar cualquier incidente de más de una semana, la comparación con la línea base del mes anterior, el análisis de tendencias que sustenta el propio ejercicio de optimización, y —crítico— el cumplimiento, porque AzureActivity y los registros de acceso suelen tener requisitos de conservación de meses o años; recortar a 7 días de forma indiscriminada puede ser directamente un incumplimiento. Además, los incidentes de seguridad y el ransomware se detectan tarde (07-05): sin registros no hay forma de reconstruir qué pasó. Alternativas con ahorro comparable y mucho menor impacto, en orden: (1) reducir la ingesta de lo que nadie consulta —la palanca de mayor impacto—, identificando con la tabla Usage las tablas que representan el grueso del volumen y desactivando categorías de diagnóstico no usadas o filtrándolas con transformaciones en la regla de recopilación; (2) plan Basic para tablas de alto volumen y baja consulta como los registros de contenedor; (3) retención diferenciada por tabla, que es lo que resuelve el conflicto: AzureActivity a 365 días por cumplimiento, AppTraces a 30, registros de depuración a 8; (4) archivo a largo plazo, mucho más barato, con trabajos de búsqueda cuando haga falta; y (5) exportación a stlagocontosopro para lo que solo se necesita de forma esporádica. Con la combinación de las cinco se alcanza un ahorro similar conservando lo investigable. Si aun así hubiera que hacer el recorte, se plantea al comité como compromiso explícito: «ahorramos 480 €/mes y aceptamos que cualquier incidente de más de una semana será no investigable y que los registros de auditoría dejarán de cumplir el requisito X», con la firma de quien asume ese riesgo y una fecha de revisión.

Solución 3: asistentes cuatro personas: quien lleva finanzas, quien lleva infraestructura, un representante de producto y el responsable técnico del producto principal; más de cinco personas para 4.000 € es desproporcionado. Duración 30 minutos mensuales. Orden del día: (1) factura del mes, variación y desviación frente al presupuesto, 5 min; (2) coste unitario del indicador de negocio elegido, 5 min; (3) top 5 de partidas y anomalías detectadas, 5 min; (4) desperdicio de Advisor y Resource Graph con decisión aplicar/posponer/descartar, 10 min; (5) acciones con responsable y fecha, 5 min. Indicadores: total, variación mensual, coste unitario, porcentaje de recursos sin etiquetar, ahorro realizado frente al prometido, y cobertura de compromisos si los hay. Automatización: un runbook mensual en Azure Automation que ejecute az advisor recommendation list --category Cost y las consultas de Resource Graph de huérfanos y de recursos sin etiquetar, vuelque el resultado en una cuenta de almacenamiento y publique el resumen en Teams 48 horas antes de la reunión; una exportación diaria de coste; presupuesto con alertas al 80 % real y 100 % previsto hacia el grupo de acciones existente; y detección de anomalías activada. A este tamaño no procede el chargeback —con una sola suscripción y cuatro personas, el showback y una conversación bastan— ni comprar reservas antes de tener tres meses de uso estable.

Ya sabes qué es FinOps y por qué es cultura y no herramienta: en la nube quien gasta el dinero es quien escribe la plantilla, y la única alternativa a bloquear a la gente con aprobaciones es darle el dato y la responsabilidad. Conoces sus tres fases —informar, optimizar, operar—, la regla de que no se puede saltar la primera, y los tres papeles con sus nombres: Nuria aportando presupuesto y contexto económico, Marta aportando el conocimiento de qué se puede tocar, y Diego y producto decidiendo qué merece la pena; con la disfunción típica de que falte negocio y se acabe recortando lo técnicamente fácil en vez de lo económicamente irrelevante.

Tienes el catálogo completo de palancas que consolida el curso entero —apagar, limpiar huérfanos, dimensionar, escalar automáticamente, instancias de acceso puntual, reservas y planes de ahorro, Hybrid Benefit, consolidar planes, niveles sin servidor con pausa, autoescalado de RU/s, pausar Synapse, niveles y ciclo de vida de almacenamiento, las tres palancas de Log Analytics, muestreo en Application Insights, caché y CDN contra el egress, planes de hospedaje adecuados, arquitecturas sin servidor y basadas en eventos, y límites de tokens— con su ahorro típico y, sobre todo, con su riesgo. Y con él, la distinción que evita los desastres: eliminar desperdicio se ejecuta sin pedir permiso, aceptar un compromiso lo decide el negocio informado, con las tres preguntas —cuánto se ahorra, qué se pierde exactamente y qué pasa el día que eso importe—. Por eso Contoso dejó 2.555 € al mes sobre la mesa rechazando por escrito quitar la redundancia de zona de db-reservas, la réplica fg-contoso-reservas, el WAF, Defender for Cloud, el GZRS de las tarjetas, la retención de copias y el bastión.

Llevas el plan priorizado completo, ordenado por ahorro dividido entre riesgo y esfuerzo, con la limpieza ejecutada antes que los compromisos; el resultado medido —de 17.800 € a 12.550 € al mes, un 29 % menos, sin degradar un solo servicio— y la honestidad de presentarlo como intervalo y presupuestar el peor caso. Sabes que el indicador que de verdad importa es el coste unitario, que bajó de 0,193 € a 0,136 € por reserva vendida y siguió bajando en la temporada alta pese a que la factura subía, porque una factura que sube puede ser una excelente noticia y sin ese indicador no hay forma de demostrarlo. Y tienes el proceso que lo sostiene: la revisión mensual de una hora con sus asistentes, su informe enviado con 48 horas, sus acciones con nombre y fecha y su comparación entre ahorro prometido y realizado; las políticas que previenen el gasto desde la gobernanza del módulo 4; la integración del coste en el ciclo de vida del desarrollo, con la estimación en la revisión de arquitectura y el comentario automático en la solicitud de cambios de Bicep; y los anti-patrones que arruinan cualquier iniciativa, con el más caro de todos bien identificado: ahorrar cincuenta euros a costa de veinte horas de ingeniería.

Con esto se cierra el módulo 8 y, con él, la construcción de la plataforma. Merece la pena mirar el conjunto: Contoso Airlines empezó este curso con una idea vaga de lo que era la nube y termina con una plataforma desplegada sobre cómputo, almacenamiento y redes bien elegidos; con sus datos en los servicios adecuados y sus niveles de servicio justificados; asegurada con identidad, RBAC, secretos, WAF, Defender for Cloud y directivas que impiden crear lo que no debe existir; entregada por pipelines e infraestructura como código en lugar de por clics; ampliada con contenedores, funciones, mensajería e IA; observada de extremo a extremo, investigable con KQL, automatizada y recuperable con un plan probado; y ahora estimada, medida, presupuestada, repartida, optimizada y gobernada, con cada euro imputado a un centro de coste y cada decisión de recorte —incluidas las que se rechazaron— escrita con su motivo. La pregunta de Nuria Peña, la que abrió este módulo, tiene por fin respuesta: se sabe cuánto cuesta cada pieza, qué parte de esa factura es valor y qué parte era desperdicio, y quién decide sobre cada una.

Queda una última cosa, y es mirar todo esto de una vez. A lo largo de ocho módulos has visto la plataforma por partes, cada una en su lección, y esa es la forma de aprenderla; pero no es la forma en que existe. El módulo 9 cierra el curso con la vista de conjunto: la arquitectura completa de Contoso Airlines dibujada entera, con todos sus componentes y todas sus conexiones, para que puedas leerla como se lee un plano; el Azure Well-Architected Framework, que es el marco que justifica —o desmonta— cada una de las decisiones que has ido tomando, con sus cinco pilares y sus compromisos entre ellos; los errores comunes que se repiten en todas las organizaciones y cómo evitarlos antes de cometerlos; cómo se migra una organización entera con el Cloud Adoption Framework, porque Contoso todavía tiene sistemas en Barcelona; y hacia dónde va Azure, con las certificaciones que acreditan lo que ya sabes hacer. Ya tienes todas las piezas: el módulo 9 es donde aprendes a leer el conjunto con criterio.