FinOps: el rol que hace que la nube no arruine tu empresa

Imagina que construyes una casa y no llevas registro de los materiales. Cada semana el contratista pide lo que necesita, el proveedor lo entrega, y al final del mes llega una factura. La factura siempre es más alta de lo esperado. El propietario pregunta por qué, el contratista culpa al arquitecto, el arquitecto culpa al cliente, y el proveedor ya cobró. Nadie mintió. Nadie saboteó el proyecto. Simplemente nadie conectó el trabajo técnico con el dinero real en ningún momento del proceso.

En cloud sucede exactamente lo mismo, pero en ciclos de horas en lugar de semanas. Un ingeniero sube un clúster de Kubernetes para hacer pruebas, lo olvida activo el fin de semana, y el lunes hay tres mil dólares adicionales en la factura de Azure. Nadie fue irresponsable — el ingeniero no vio el costo, el manager no vio el recurso, y finanzas vio la factura cuando ya era tarde para hacer algo al respecto.

FinOps existe para romper ese ciclo. No es una herramienta. No es un dashboard. Es una disciplina que conecta tres mundos que normalmente no hablan entre sí: ingeniería, finanzas y negocio.

El problema real que FinOps resuelve

Antes de cloud, el gasto en infraestructura era capital expenditure — CapEx. Comprabas servidores una vez, los depreciabas en cuatro años, y el costo era predecible. El departamento de finanzas podía planear sin sorpresas.

Cloud convirtió la infraestructura en operational expenditure — OpEx. Ahora el gasto es variable, granular y ocurre en tiempo real. Cada petición HTTP tiene un costo. Cada gigabyte de log almacenado tiene un costo. Cada segundo que un contenedor lleva activo tiene un costo. El equipo de finanzas aprendió a presupuestar CapEx durante décadas. OpEx en cloud es un modelo completamente diferente.

He visto empresas medianas con 30 ingenieros gastar el doble de lo necesario en AWS o Azure no porque sean descuidadas, sino porque nadie tenía visibilidad completa del gasto. El equipo de backend no sabía cuánto costaba su base de datos. El equipo de frontend no sabía que sus builds de CI corrían en instancias de 8 vCPUs cuando con 2 bastaba. El equipo de DevOps sabía el costo total, pero no tenía contexto de negocio para priorizar qué reducir primero.

FinOps resuelve el problema de visibilidad, el problema de responsabilidad y el problema de decisión.

Qué es FinOps como disciplina

La FinOps Foundation define FinOps como “una práctica de gestión financiera en cloud que permite a los equipos de ingeniería, finanzas y negocio colaborar en decisiones de gasto basadas en datos”. La definición es correcta pero académica.

En la práctica, FinOps es el proceso continuo de responder tres preguntas:

1. ¿En qué se está gastando el dinero? — Visibilidad granular por equipo, producto, entorno y servicio.
2. ¿Vale lo que cuesta? — Cada recurso debe tener un dueño y justificación de negocio.
3. ¿Cómo se puede gastar menos sin impactar el producto? — Optimización técnica y financiera combinada.

Ninguna de estas preguntas puede responderla solo ingeniería. Ninguna puede responderla solo finanzas. La disciplina vive en la intersección.

El modelo de madurez: Crawl, Walk, Run

La FinOps Foundation describe tres etapas de madurez. Entenderlas ayuda a saber dónde está tu organización y qué debería mejorar primero.

Crawl: visibilidad básica

En esta etapa el objetivo es ver. Si no puedes ver dónde se gasta el dinero, no puedes optimizar nada.

El primer paso práctico es implementar una estrategia de tagging consistente. Cada recurso en cloud debe tener al menos tres etiquetas: environment (production/staging/dev), team (backend/frontend/data) y project (nombre del producto o iniciativa). Sin estos tags, los reportes de costo son un número global imposible de desglosar.

# Azure: tagging de un grupo de recursos completo
az tag update \
  --resource-id /subscriptions/<sub>/resourceGroups/rg-api-prod \
  --operation merge \
  --tags environment=production team=backend project=payments-api

# En Terraform, política de tags obligatorios
locals {
  mandatory_tags = {
    environment = var.environment
    team        = var.team
    project     = var.project
    managed_by  = "terraform"
  }
}

Este bloque no es opcional. Si lo omites en un recurso, ese recurso es invisible para el análisis financiero. En empresas con cientos de recursos, la ausencia de tags consistentes significa que el 30-40% del gasto no tiene dueño identificable.

Una vez que los recursos tienen tags, se configuran los reportes de costo. En Azure esto es Azure Cost Management + Billing. En AWS es Cost Explorer. El objetivo de esta etapa es producir un reporte semanal de gasto por equipo que cualquier manager pueda leer sin conocimiento técnico.

Walk: responsabilidad distribuida

En esta etapa el objetivo es que cada equipo sea responsable de su propio gasto, no solo de verlo.

El patrón central es el chargeback o showback. La diferencia es importante: showback muestra a cada equipo cuánto gasta sin cobrarles internamente; chargeback asigna costos reales a centros de costo internos. La mayoría de las organizaciones empieza con showback porque chargeback requiere procesos financieros más maduros.

Lo que cambia el comportamiento es que los ingenieros vean el costo de sus decisiones técnicas en tiempo cercano a real. Un equipo que sabe que su entorno de staging cuesta $800 al mes va a apagar los recursos cuando no los usa. Un equipo que no sabe ese número no tiene razón para hacerlo.

En esta etapa también aparece el proceso de revisión de anomalías. Un gasto que sube 50% en un día sin cambio de código es una señal de problema, no solo de costo. Puede ser un loop infinito, un recurso que se replicó por error, o un ataque.

# Azure Monitor: alerta de anomalía de costo
{
  "alertRuleName": "cost-spike-backend-team",
  "description": "Gasto del equipo backend supera threshold diario",
  "enabled": true,
  "definition": {
    "scopes": ["/subscriptions/<sub>/resourceGroups/rg-backend-prod"],
    "condition": {
      "allOf": [
        {
          "type": "ActualCost",
          "timeAggregation": "Total",
          "operator": "GreaterThan",
          "threshold": 500,
          "dimensions": [
            {
              "name": "ResourceGroup",
              "values": ["rg-backend-prod"]
            }
          ]
        }
      ]
    },
    "actions": {
      "actionGroups": ["/subscriptions/<sub>/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/backend-team-alerts"]
    }
  }
}

La alerta no bloquea el gasto. Notifica al equipo dueño del recurso para que investigue. Esto es deliberado: FinOps no reemplaza la autonomía de ingeniería, la hace responsable.

Run: optimización continua

En esta etapa el objetivo es tomar decisiones financieras y técnicas en conjunto, de manera sistemática, sin fricción.

Aquí es donde aparecen los ciclos de optimización regulares, el uso de instancias reservadas, spot nodes, y la integración de costos en el ciclo de desarrollo — que el costo de un cambio sea visible antes del deploy, no después.

El rol del FinOps Engineer

Un FinOps Engineer no es un contador ni un arquitecto de cloud exclusivamente. Es alguien que habla los dos idiomas.

Las responsabilidades concretas del rol incluyen:

Análisis de costo y atribución. Mantener los dashboards actualizados, producir reportes periódicos por equipo, identificar recursos sin dueño y anomalías de gasto. Esto requiere conocimiento de la estructura de facturación del proveedor de cloud — que en Azure, AWS y GCP es sorprendentemente compleja.

Optimización técnica. Identificar recursos sobredimensionados, proponer right-sizing, evaluar si un workload puede moverse a instancias spot o de baja prioridad, identificar datos en storage que pueden moverse a tiers más baratos.

Gobernanza. Definir y hacer cumplir la política de tags, crear políticas de Azure Policy o AWS Service Control Policies que bloqueen el aprovisionamiento de recursos sin tags obligatorios, revisar que los entornos de desarrollo y staging se destruyan o escalen a cero fuera de horario laboral.

Comunicación financiero-técnica. Traducir el gasto técnico en impacto de negocio para ejecutivos, y traducir objetivos de reducción de costo en acciones técnicas específicas para ingenieros.

No es un rol de tiempo completo en organizaciones pequeñas. En equipos de hasta 20 ingenieros, FinOps suele ser una responsabilidad compartida dentro del equipo de DevOps o Platform Engineering. En organizaciones más grandes, es un rol dedicado o incluso un equipo.

Herramientas del ecosistema FinOps

El ecosistema tiene tres categorías de herramientas: nativas del proveedor, terceros, y open source.

Nativas del proveedor

Azure Cost Management + Billing es el punto de partida en Azure. Ofrece análisis de costos por grupo de recursos, tag, servicio y período, alertas de presupuesto, y recomendaciones de Advisor. Es gratuito y suficiente para la etapa Crawl y parte de Walk.

AWS Cost Explorer tiene una profundidad de análisis similar para AWS, con la ventaja adicional de sugerir instancias reservadas basadas en el historial de uso. El análisis de ahorro potencial de Reserved Instances es notablemente bueno.

Google Cloud Billing en GCP incluye BigQuery billing export, que permite hacer queries SQL directamente sobre los datos de facturación — lo cual da un nivel de análisis personalizado que las herramientas nativas de Azure y AWS no alcanzan directamente.

Terceros

Infracost es la herramienta más importante para integrar costos en el ciclo de desarrollo. Analiza cambios de Terraform y calcula el impacto de costo antes del merge. El output aparece como comentario en el pull request.

# Instalación
brew install infracost  # o curl -fsSL https://raw.githubusercontent.com/infracost/infracost/master/scripts/install.sh | sh

# Generar reporte de costo del plan de Terraform
infracost breakdown --path . --terraform-plan-flags "-var-file=prod.tfvars"

# En CI/CD: comentar el PR con el delta de costo
infracost diff --path . --compare-to infracost-base.json

El resultado de infracost diff muestra algo como:

Project: api-infrastructure

+ azurerm_kubernetes_cluster.aks
  + default_node_pool (Standard_D4s_v3 x3)  +$438.00/month

Monthly cost change: +$438.00

Este número en el PR cambia la conversación. Un ingeniero que ve +$438.00/month antes de mergear va a preguntar si realmente necesita un D4s_v3 o si un D2s_v3 alcanza. Cuando el número solo aparece en la factura del mes siguiente, la conversación ya no es posible.

OpenCost es el estándar open source para medir el costo de workloads en Kubernetes. Corre dentro del clúster y asigna costos a namespace, deployment, pod y label. Es la base de varias soluciones comerciales.

# Instalar OpenCost en Kubernetes con Helm
helm install opencost opencost/opencost \
  --namespace opencost \
  --create-namespace \
  --set opencost.exporter.cloudProviderApiKey="<azure-billing-key>"

Una vez instalado, OpenCost expone una API que permite consultar el costo de un deployment específico en el último mes:

curl "http://opencost.opencost.svc:9003/allocation" \
  -G \
  --data-urlencode "window=30d" \
  --data-urlencode "aggregate=deployment" \
  --data-urlencode "namespace=production" | jq '.data[].totalCost'

Esto conecta directamente el costo con el artefacto de software. El equipo de payments puede saber que su API costó $340 este mes, el equipo de notifications costó $180, y decidir en conjunto si el ratio tiene sentido dado el valor que genera cada servicio.

FOCUS (FinOps Open Cost and Usage Specification) es el estándar de datos emergente del sector, promovido por la FinOps Foundation. Define un esquema común para datos de facturación de todos los proveedores de cloud. Todavía en adopción, pero importante para organizaciones multi-cloud.

El ciclo FinOps en un sprint

FinOps no es un proyecto. Es un proceso recurrente. La forma más práctica de integrarlo es añadir tres momentos dentro del ciclo de desarrollo existente:

Al planificar (antes del sprint): revisar las recomendaciones de right-sizing generadas automáticamente por Azure Advisor o AWS Compute Optimizer. Estas herramientas analizan el uso real de CPU y memoria en los últimos 7-14 días y proponen instancias más pequeñas. No siempre tienen razón — un servicio con spikes periódicos puede parecer sobredimensionado en promedio — pero son el punto de partida para la conversación.

Al desarrollar (en el PR): usar Infracost para que cualquier cambio de infraestructura muestre el impacto de costo estimado. Esto no necesariamente bloquea el merge, pero genera visibilidad en el momento correcto.

Al revisar (semanal): una revisión de 15 minutos de los reportes de costo de la semana anterior. El objetivo no es aprobar cada gasto, sino detectar anomalías y recursos olvidados. Esta revisión debería incluir al menos una persona técnica y una persona con contexto de negocio.

# GitHub Actions: Infracost en PR
name: Cost Estimate
on:
  pull_request:
    paths:
      - 'infrastructure/**'
      - '**/*.tf'

jobs:
  infracost:
    name: Infracost
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Checkout base branch
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.base.ref }}
          path: base

      - name: Generate Infracost cost estimate baseline
        run: |
          infracost breakdown --path=base/infrastructure \
            --format=json \
            --out-file=/tmp/infracost-base.json

      - name: Generate Infracost diff
        run: |
          infracost diff --path=infrastructure \
            --format=json \
            --compare-to=/tmp/infracost-base.json \
            --out-file=/tmp/infracost.json

      - name: Post Infracost comment
        uses: infracost/actions/comment@v3
        with:
          path: /tmp/infracost.json
          behavior: update

Este pipeline no añade fricción al proceso de desarrollo. Añade información. La diferencia entre los dos es enorme en la práctica.

Errores comunes al implementar FinOps

Empezar por la optimización antes que por la visibilidad. He visto equipos gastar semanas buscando qué recursos eliminar sin tener una sola etiqueta implementada. Optimizas en la oscuridad. Primero tags, primero reportes, después optimización.

Tratar FinOps como un proyecto de una sola vez. “Redujimos el costo un 30% en Q3” es un éxito temporal si no hay un proceso continuo detrás. Sin revisión regular, los recursos vuelven a crecer, los entornos de prueba se quedan activos, y en seis meses el costo volvió a donde estaba.

Hacer FinOps solo desde DevOps. Si el equipo de ingeniería optimiza sin visibilidad de las prioridades de negocio, puede reducir el costo del servicio equivocado. Una API que cuesta $500 al mes y genera $50,000 en ingresos no es el lugar donde optimizar. Eso solo es visible si hay colaboración entre ingeniería y negocio.

Ignorar los costos indirectos de cloud. La transferencia de datos egress, los logs de diagnóstico, el API Management, el DNS — ninguno parece caro de forma individual. Juntos, en escala, pueden representar el 20-30% de la factura total. Las revisiones de FinOps deben incluir estos servicios secundarios, no solo los de cómputo.

Por qué FinOps es también una ventaja competitiva

Una empresa que controla su gasto en cloud puede tomar decisiones que una empresa sin esa visibilidad no puede. Puede lanzar un experimento técnico sabiendo exactamente cuánto costará. Puede escalar un servicio durante un evento sabiendo el costo marginal de cada instancia adicional. Puede comparar dos arquitecturas no solo por rendimiento o complejidad, sino por costo real de operación.

He visto startups que consiguieron 18 meses más de runway simplemente implementando FinOps básico — sin cambiar su producto, sin despedir gente, sin recortar features. Solo dejaron de desperdiciar dinero en infraestructura que nadie usaba o que estaba sobredimensionada sin razón.

La nube prometió costos variables que escalan con el negocio. FinOps es lo que hace que esa promesa se cumpla en la práctica.

El gasto en cloud no es un problema técnico ni un problema financiero. Es un problema de información. FinOps es la disciplina que pone esa información en las manos correctas, en el momento correcto, para tomar decisiones que el negocio puede sostener.