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 entre el 20 y el 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, esto sustituye a 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 multicloudIcono de nube de Amazon Web Services, referencia habitual en el contexto FinOps para gestión de coste multicloud (Imagen: Amazon webservices, CC BY-SA 4.0, vía Wikimedia Commons)

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 tres principios con SRE: SLOs, postmortems y 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.

Fuentes:

  1. FinOps Foundation: qué es FinOps[11]
  2. AWS Cost Explorer: visualización y análisis de gasto en AWS[2]
  3. Google Cloud Billing: informes y análisis de coste[3]
  4. OpenCost: proyecto CNCF de visibilidad de coste en Kubernetes[8]
  5. Infracost: estimación de coste de Terraform en PRs[9]

Preguntas frecuentes

¿Por dónde empiezo a aplicar FinOps si mi factura cloud no para de crecer?

Por la visibilidad, no por la optimización: sin tagging riguroso, ahorrar es búsqueda a ciegas. Etiqueta cada recurso con servicio, equipo, entorno y producto. Monta dashboards de coste por equipo (con AWS Cost Explorer, GCP Cost Tools, Azure Cost Management o terceros como CloudHealth) y añade forecasting con alertas cuando el gasto se sale de banda. Invertir primero en esta fase Inform y después en optimización continua suele rendir 2-3x en el primer año.

¿Cuánto se puede ahorrar con reservas, Savings Plans e instancias spot?

Pagar por adelantado capacidad predecible con reservas o Savings Plans da descuentos del 30-70 %. Las instancias spot o preemptible, para workloads tolerantes a interrupción como batch, CI o servicios stateless, pueden costar un 50-90 % menos que on-demand. A eso se suman el right-sizing de instancias sobredimensionadas, el desperdicio más común, y la eliminación de recursos huérfanos: volúmenes no atachados, snapshots antiguos e IPs elásticas sin asociar.

¿Debo incluir los entornos de staging y CI en el control de costes?

Sí: los entornos de staging, dev y CI suelen representar el 20-40 % del coste total, e ignorarlos es uno de los errores más frecuentes. Otros patrones que se repiten son centralizar todo en finanzas, cuando los ingenieros son los únicos que distinguen desperdicio real de inversión necesaria, y hacer una optimización puntual en vez de continua. Ahorrar un 30 % un trimestre y dejar crecer el gasto el siguiente es apagar un fuego, no FinOps.

Fuentes

  1. FinOps
  2. AWS Cost Explorer
  3. GCP Cost Tools
  4. Azure Cost Management
  5. AWS Compute Optimizer
  6. Densify
  7. Kubecost
  8. OpenCost
  9. Infracost
  10. Cloud Custodian
  11. FinOps Foundation: qué es FinOps