FinOps: controlar el coste en la nube sin frenar al equipo
Actualizado: 2026-07-07
El coste en la nube ha pasado de ser "la factura de IT" a convertirse en una métrica operativa central. Con multicloud, microservicios y autoscaling, entender qué consume qué y por qué es ahora tan complejo como gestionar rendimiento o disponibilidad. FinOps es el marco que ha emergido para atacar este problema como disciplina de ingeniería, no como auditoría financiera a posteriori.
Puntos clave
-
FinOps convierte el coste cloud en una métrica de producto gestionable con las mismas prácticas que la fiabilidad.
-
El framework se organiza en tres fases cíclicas: Inform (visibilidad), Optimize (optimización) y Operate (operación continua).
-
El tagging riguroso es el primer paso imprescindible, ya que sin él cualquier optimización es búsqueda a ciegas.
-
Herramientas open-source como Kubecost, OpenCost e Infracost hacen la disciplina accesible sin licencias propietarias.
-
Los entornos de staging y CI representan habitualmente el 20-40% del coste total: ignorarlos es un error frecuente.
Qué es FinOps
FinOps[1] (Financial Operations o Cloud FinOps) es, según la FinOps Foundation, "una práctica operacional de gestión financiera en la nube que ayuda a las organizaciones a obtener máximo valor de negocio ayudando a equipos de ingeniería, finanzas, producto y operaciones a colaborar en decisiones basadas en datos sobre gasto".
En la práctica: en vez de que finanzas descubra el gasto al final del mes y pida explicaciones, los equipos que generan el coste lo ven en tiempo real, entienden su origen y lo gestionan como cualquier otra métrica de producto.
El framework de tres fases
Fase 1: Inform (visibilidad)
Antes de optimizar, hace falta ver. Los tres pilares de esta fase son:
-
Etiquetado/tagging riguroso. Cada recurso tiene etiquetas identificando servicio, equipo, entorno y producto. Sin esto, los informes de coste son opacos.
-
Dashboards de coste por equipo/servicio. No la factura total, sino "¿cuánto cuesta nuestro equipo esta semana?". Herramientas: AWS Cost Explorer[2], GCP Cost Tools[3], Azure Cost Management[4], o terceros como CloudHealth o Apptio Cloudability.
-
Forecasting. Predicción de coste basada en tendencia, con alertas cuando se sale de banda.
Fase 2: Optimize (optimización)
Una vez visible, se ataca el desperdicio mediante cinco palancas:
-
Right-sizing. Instancias sobredimensionadas son el desperdicio más común. Herramientas: AWS Compute Optimizer[5], Densify[6].
-
Reservas y Savings Plans. Pagar por adelantado capacidad predecible da descuentos del 30-70%.
-
Spot/Preemptible. Para workloads tolerantes a interrupción (batch, CI, stateless), spot puede costar un 50-90% menos que on-demand.
-
Eliminar recursos huérfanos. Volúmenes no atachados, snapshots antiguos, IPs elásticas sin asociar.
-
Arquitectura eficiente. Serverless vs. contenedores vs. VMs. El modelo adecuado depende del patrón de carga.
Fase 3: Operate (operación continua)
FinOps maduro incluye tres prácticas permanentes:
-
SLOs de coste. "Coste por millón de peticiones procesadas < X", integrado en dashboards de SRE.
-
Showback/chargeback. Cada equipo ve su coste como un KPI; en organizaciones maduras, se factura internamente al consumidor.
-
Retrospectivas de coste. Tras incidentes de coste (una query SQL disparó la factura, un dashboard se descontroló), postmortem blameless análogo a los incidentes de fiabilidad.
Icono de nube de Amazon Web Services, referencia habitual en el contexto FinOps para gestión de coste multicloud
Herramientas open-source
Para equipos que prefieren evitar soluciones propietarias, cuatro opciones sólidas:
-
Kubecost[7]: visibilidad de coste detallada en Kubernetes (open-core).
-
OpenCost[8]: proyecto CNCF derivado de Kubecost, 100% abierto.
-
Infracost[9]: estima el coste de cambios de Terraform en PRs, antes del merge.
-
Cloud Custodian[10]: reglas declarativas para auditar y aplicar políticas de coste y seguridad cross-cloud.
Errores frecuentes
Cuatro patrones que se repiten en equipos que comienzan:
-
Empezar por optimización sin visibilidad. Sin taggear primero, ahorrar es búsqueda a ciegas.
-
Centralizar todo en finanzas. Los ingenieros son los únicos que pueden identificar qué es desperdicio real vs. inversión necesaria.
-
Optimización puntual, no continua. Ahorrar un 30% en un trimestre y dejar crecer el gasto en el siguiente no es FinOps: es apagar un fuego.
-
Ignorar coste de desarrollo. Entornos de staging, dev y CI suelen representar el 20-40% del total.
FinOps comparte muchos principios con SRE: SLOs, postmortems, métricas continuas, trasladados al dominio del coste. Para clusters Kubernetes, Kubecost y OpenCost se integran directamente con las métricas operativas. Las prácticas de platform engineering e IDPs facilitan que los equipos de producto vean su coste como parte del portal interno.
Read this in English: FinOps: Controlling Cloud Cost Without Slowing the Team.
Conclusión
FinOps convierte el coste cloud en una métrica de producto, gestionable con las mismas prácticas que ya usamos para fiabilidad y rendimiento. Para equipos con facturas cloud crecientes, la inversión en visibilidad primero (fase Inform) y luego en optimización continua suele rendir dividendos de 2-3x en el primer año.
