I am Lino
30 de abril de 2026

La nube ya no es barata: bienvenidos a la era del FinOps

Publicado el 30 de abril de 2026  •  13 minutos  • 2599 palabras
Table of contents

Múdate a la nube. Ahorrarás dinero. Los detalles, ya los veremos luego.

A fuerza de escucharlo, en algún momento dejaste de leer la letra pequeña.

Lo cierto es que dejar de comprar hierro cada tres años es maravilloso; poder apagar entornos de prueba cuando no se usan, también.

El “luego” ha llegado en forma de facturas mensuales con más dígitos de los esperados y correos de Finanzas preguntando, con mucha educación pero con el cuchillo preparado, qué es exactamente kinesis-analytics-something-us-east-1-prod y por qué cuesta tanto .

Lo que estamos viviendo ahora tiene nombre y apellidos: FinOps.

No es una herramienta mágica ni un nuevo rol que lo arregla todo, sino la constatación de que la nube dejó de ser “barata por defecto” y pasó a ser flexible por defecto.

Y la flexibilidad, sin criterio, sale cara .

Del “la nube abarata costes” al “¿quién ha dejado esto encendido?”

Cuando leías los primeros artículos evangelizadores sobre cloud, casi todos sonaban igual: paga solo por lo que usas, elasticidad infinita, sin inversión inicial, adiós a los datacenters tristes.

En lo que respecta a transparencia, impecable. En lo que respecta al extracto bancario, la cosa cambió cuando el uso empezó a subir… y nadie miraba demasiado qué se estaba usando exactamente.

Hay un caso documentado de una empresa gastando más de 50 millones al año en nube, con paneles de control, alertas y contratos negociados… y aun así, una cantidad obscena de despilfarro: datos conservados sin necesidad, servicios sobredimensionados “por si acaso”, soluciones carísimas donde bastaba algo estándar. No es un caso raro, es el caso habitual con nombres cambiados.

Los números que circulan por el sector, tanto de la FinOps Foundation como de consultoras como KPMG , rondan el 25-30% de desperdicio sobre el gasto total. Tómatelo como una estimación, no como una ley física - pero la dirección es la correcta: mucho de lo que pagas no hace nada útil.

Y lo más frustrante es que no es por negligencia. La nube hizo tan fácil pedir recursos con un clic que los procesos clásicos de control financiero simplemente no dieron abasto. Lo que antes requería un ticket, un PO y tres firmas, ahora se consigue con una tarjeta de crédito corporativa y un rato libre.

“El problema no es Finanzas, son tus sistemas”

La reacción más humana cuando las facturas suben es mirar hacia Finanzas y señalarles con el dedo, con mucha calma: “esto es vuestro problema”. Finanzas hace lo que puede: monta paneles, saca informes, manda el correo de “hemos detectado un pico en tal cuenta” con copia al jefe de equipo. Todo muy bien. El único inconveniente es que Finanzas no diseña tus sistemas; solo paga las facturas que tus decisiones arquitectónicas generan.

La verdad incómoda es que el coste en la nube no suele ser un fallo financiero, sino un síntoma arquitectónico .

Tu aplicación, tu forma de desplegar, tus decisiones sobre dónde viven los datos… todo eso define cuánto se gasta.

Si tu sistema fue diseñado asumiendo que la infraestructura es fija y barata, la elasticidad de la nube no va a arreglar nada; va a amplificar el problema con más elegancia y a mayor velocidad.

Por eso los intentos de “optimizar gasto” solo con recortes fracasan tan a menudo. Puedes apagar algún zombie obvio, sí, pero mientras tu arquitectura siga creando VMs enormes para cada microservicio, moviendo datos entre regiones sin mirar el egress o dejando procesos ejecutándose indefinidamente porque “nadie sabe muy bien si eso todavía hace algo útil”, el coste va a seguir subiendo aunque tengas el mejor Excel del universo conocido.

FinOps, cuando tiene sentido de verdad, es justo ese cambio: el coste deja de ser un número en un informe que llega tarde y pasa a ser una métrica más del sistema.

Igual que miras latencia o errores, miras también euros gastados por producto, por funcionalidad, por cliente. Sin esperar al resumen de fin de mes para enterarte de la fiesta.

Por qué tu factura sube aunque creas estar haciendo “las cosas bien”

Date una vuelta por foros de FinOps y verás siempre el mismo hilo:

“llevamos un año con FinOps, tagging perfecto, reservas compradas, alertas por todos lados… y la factura sigue subiendo un 10-15% cada trimestre, ¿qué estamos haciendo mal?”.

La respuesta que nadie quiere escuchar es que probablemente no están haciendo nada mal - es que el sistema está haciendo más cosas, y nadie se paró a pensar si esas cosas añaden valor al mismo ritmo que añaden coste.

Más funcionalidades, más servicios, más regiones, más datos… no siempre acompañados de más usuarios de pago o más ingresos. Solo de más factura.

El grueso del gasto no viene de picos dramáticos ni de incidentes, viene de lo aburrido como esas cargas que llevan meses funcionando mucho después de que nadie las necesite, las APIs que mueven más datos de los que cualquier usuario va a ver jamás, esas aplicaciones diseñadas para infraestructura fija que en la nube escalan como un globo con agujeros.

Es el equivalente a dejar todas las luces de la oficina encendidas el fin de semana porque “ya hemos pagado la instalación eléctrica”.

Y no podemos olvidar el efecto “todo es mejor con IA”: modelos enormes para casos que resolverían cuatro reglas if-else, pipelines que procesan terabytes para generar recomendaciones que nadie mira, entornos de entrenamiento que siguen encendidos porque “igual volvemos a entrenar el mes que viene” - spoiler: no volvéis.

En cargas de IA, el almacenamiento, los snapshots y el tráfico pueden destruir el presupuesto incluso más que el compute, precisamente porque nadie los mira con tanto cuidado.

La conclusión es que puedes tener FinOps perfectamente documentado en la superficie, pero si por debajo tu arquitectura incentiva el despilfarro - overprovisioning por defecto, datos duplicados sin pensar, funcionalidades que nadie usa pero que quedaban muy bien en el roadmap -, tu factura va a seguir subiendo con puntualidad suiza.

Lo que un equipo técnico puede hacer sin convertirse en contable

La buena noticia - y la hay - es que esto no requiere que ningún desarrollador abra un Excel y llore sobre fórmulas. Lo que sí requiere es que el coste aparezca donde se toman las decisiones que lo generan, no tres semanas después en un correo de Finanzas.

Piénsalo así: si tu Terraform no dice nada sobre cuánto va a costar lo que está desplegando, estás tomando decisiones arquitectónicas a ciegas que más tarde van a doler.

La idea de “FinOps as Code ” es exactamente eso: anotar expectativas de coste junto a los recursos, poner políticas que impidan desplegar un RDS r6g.16xlarge “porque era el que venía en el tutorial”, hacer que el pipeline se queje de gasto inesperado igual que se queja cuando fallan los tests. No porque seas tacaño, sino porque tomar una decisión de 4.000€/mes sin saberlo no es agilidad; es un accidente que todavía no ha ocurrido.

El otro frente es hacer que el equipo de producto vea lo que cuesta su producto. No el CTO en un informe trimestral sino el equipo que decide qué features construir, qué arquitectura usar, cuántos entornos mantener encendidos.

Showback y chargeback son palabras feas, pero la idea detrás es sencilla - si el equipo de billing descubre que su servicio de generación de PDFs consume el 40% del gasto en cómputo, de repente la conversación sobre si realmente necesitan ese cluster cambia bastante de tono. Sin esa visibilidad compartida , la optimización es siempre cosa de otro, y ese otro nunca aparece.

En el día a día, las victorias más rápidas suelen ser las más aburridas: esa Lambda que lleva nueve meses corriendo con factura de serverless que ya no tiene ningún sentido porque en realidad es un proceso batch que corre siempre, los tres entornos de staging que nadie recuerda haber pedido, el almacenamiento replicado en cuatro regiones porque alguien leyó un artículo sobre resiliencia y lo aplicó a datos de prueba del sprint 3.

Y las alertas. No la alerta global de “gasto mensual supera X” que llega cuando el daño ya está hecho, sino alarmas por componente que avisan en horas, no en el resumen de fin de mes.

Nada de esto convierte a nadie en CFO. Solo requiere aceptar que el coste es una métrica más del sistema, igual que la latencia o la tasa de error: si se dispara sin que nada lo justifique, algo en el diseño no encaja.

El objetivo no es gastar menos. Es no tirar el dinero

FinOps tiene un problema de imagen. Cuando alguien lo menciona en una reunión, la mitad de la sala oye “vamos a recortar cosas” y empieza a mirar el suelo. No es culpa suya - los primeros años de FinOps en muchas empresas consistieron exactamente en eso: alguien de Finanzas con un Excel, señalando partidas como si estuviera en un concurso de encontrar objetos escondidos.

Pero la idea de fondo es otra: no se trata de gastar menos, sino de no pagar por cosas que no sirven para nada.

La diferencia parece sutil pero es enorme.

Apagar un entorno de staging que nadie usa desde hace cuatro meses no es austeridad; es higiene básica. En cambio, justificar con datos que un servicio gestionado más caro tiene sentido porque te ahorra contratar a dos personas para operarlo - eso también es FinOps, y en ese caso la decisión correcta es gastar más.

La parte que más cuesta aceptar es la del AI-washing propio. Es muy fácil señalar el AI-washing ajeno - “esa startup no tiene IA, tiene un if con sombrero” -, pero en muchas organizaciones hay funcionalidades “inteligentes” que consumen GPU, almacenamiento y tráfico de forma completamente desproporcionada a lo que aportan. Nadie las usa. Nadie las mide. Quedaron espectaculares en la demo del año pasado y ahora son un coste fijo que nadie tiene el valor de matar porque “igual alguien las necesita”. Spoiler: nadie las necesita.

Las organizaciones que han conseguido resultados sostenidos con FinOps no son las que tienen el equipo más agresivo recortando; son las que tratan el coste como parte del diseño , igual que tratan la resiliencia o la seguridad. No porque sean más tacañas, sino porque toman decisiones con información completa - y resulta que, cuando sabes cuánto cuesta algo, tiendes a no despilfarrarlo.

El precio de la flexibilidad

La nube sigue siendo maravillosa. En serio. Poder levantar infraestructura en segundos, escalar sin llamar a nadie, olvidarte de comprar hierro cada tres años - todo eso es real y no ha caducado.

Lo que sí ha caducado es la idea de que eso sale gratis por defecto. La flexibilidad tiene un precio, y ese precio lo decides tú con cada decisión de diseño, cada servicio que lanzas, cada entorno que dejas encendido “por si acaso”. Sin FinOps - entendido no como un departamento ni como una herramienta, sino como la costumbre de preguntarte cuánto cuesta lo que estás construyendo -, la nube es solo una forma muy cómoda de quemar el dinero de la empresa a velocidad variable.

Nadie te pide que te conviertas en controlador financiero ni que llores sobre informes de costes los viernes por la tarde.

Solo que, la próxima vez que alguien proponga “metemos IA aquí” o “desplegamos en tres regiones más”, alguien en la sala haga la pregunta más aburrida e imprescindible del mundo:

¿Y esto cuánto cuesta? ¿Y qué nos da a cambio?

Si tienes la respuesta, adelante.

Si nadie en la sala la sabe, igual merece la pena averiguarlo antes de que lo descubra Finanzas en el resumen de fin de mes - con mucha educación, pero con el cuchillo preparado.

Glosario rápido

Porque no todo el mundo nace sabiendo qué es un chargeback, y los que fingen saberlo suelen ser los que más gastan.

Fuentes y referencias

Todo lo que no querías saber sobre el coste de la nube pero que ya no puedes desaprender.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.