FinOps: controlar el coste en la nube sin frenar al equipo
Actualizado: 2026-05-03
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 — 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 al 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.
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.
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.
