La revisión que no mira la cuenta
Un cambio de infraestructura se revisa por seguridad, por nombres, por estilo. Casi nunca por su efecto en la factura. Y sin embargo, un cambio de tamaño de instancia, una réplica adicional o un almacenamiento más rápido pueden sumar cientos de euros al mes con una línea de código.
Ese costo aparece semanas después, en un informe que ya nadie relaciona con el cambio que lo provocó.
La estimación en el mismo sitio que el plan
Como el plan ya sabe qué recursos se crean, modifican o eliminan, y con qué tamaño, se puede calcular con precios públicos cuánto costará cada uno. La estimación se añade a la revisión del cambio:
- Costo mensual antes y después, y la diferencia.
- Desglose por recurso, para ver qué explica la subida.
- Supuestos de uso cuando el costo depende del tráfico o del volumen.
Qué cambia en la práctica
Se decide con la cifra delante. "Esta réplica añade 300 euros al mes" abre una conversación útil: ¿la necesitamos ya?, ¿basta con una más pequeña?
Se fijan umbrales. Un cambio que sube el costo por encima de cierta cantidad exige una aprobación adicional, igual que uno destructivo.
Se cierra el círculo con FinOps. La estimación de cada cambio es el presupuesto esperado; el pipeline de costos mide después el real. Si la diferencia es grande, algo del supuesto estaba mal y se aprende (es la misma idea que en el costo como requisito de diseño).
Lo que no es
La estimación no es la factura. No conoce descuentos negociados ni compromisos, y el uso real puede ser otro. Su valor no es la exactitud, sino que el costo se ve en el momento en que todavía se puede decidir.
Con el código de la infraestructura bajo control, queda la otra mitad del problema: que cada servidor, una vez creado, siga siendo el que debe ser.
Cómo lo aplicamos: Automatización e IaC.