La factura de la nube responde a la pregunta «cuánto cuesta una instancia EC2», pero calla sobre cuánto cuesta tu payments-api. En un mismo nodo viven decenas de workloads, y en la factura son indistinguibles. Según datos de la CNCF para 2026, la utilización media de los clústeres de Kubernetes es del 35–50 %: la mitad de la capacidad pagada está ociosa, y nadie ve de quién es esa mitad. Hasta el 35 % del gasto en la nube son pérdidas evitables, y la primera razón por la que no se evitan es que no hay a quién imputarlas. FinOps no empieza con la optimización, sino con la asignación: quién gasta cuánto.
Por qué Kubernetes rompe la facturación de la nube
Tres problemas que la nube tradicional no tiene. Infraestructura compartida: la facturación opera con instancias, no con workloads — «EC2 = $X», pero nunca «pod payments-api = $Y». La trampa del overprovisioning: un ingeniero cuyo servicio murió una vez por OOM duplica el memory request; individualmente racional, colectivamente derrochador — y ese margen defensivo es la fuente principal del waste. El problema del tiempo: un pod que quemó memoria de más durante 72 horas y murió hace tres semanas es invisible en la factura mensual — las señales lentas de facturación nunca capturan recursos efímeros.
La conclusión es una sola: el coste hay que medirlo a nivel de pod y en tiempo real.
OpenCost: un motor, no un dashboard
OpenCost es un proyecto CNCF Incubating (Apache 2.0) que creció del motor de asignación de costes de Kubecost; entre los contribuidores están AWS, Google y Microsoft, y el objetivo declarado es convertirse en «el Prometheus de la monitorización de costes». La mecánica es transparente: el motor toma métricas de Prometheus (kube_pod_container_resource_requests) más los precios de la nube y desglosa: coste del pod = CPU request × precio de CPU-hora + memory request × precio de memoria + storage (PVC) + network. Se instala con un único helm install apuntando a Prometheus; hacia fuera expone una API del tipo GET /allocation?window=1d&aggregate=namespace.
La trampa principal: la UI integrada de OpenCost es un visor fino, no un almacén de datos. Mantiene una ventana limitada en memoria y «pierde» el historial tras una semana aproximadamente — y no es un bug. La arquitectura prevista es otra: OpenCost exporta las métricas de coste de vuelta a Prometheus o VictoriaMetrics, y el dashboard se construye en Grafana. Quien monta su reporting sobre la UI integrada choca rápido contra un muro.
OpenCost, Kubecost y AWS SCAD: dos soluciones, no tres
Una confusión frecuente es tratarlos como una carrera a tres. OpenCost y Kubecost son una misma clase y un mismo motor: asignación en tiempo real dentro del clúster. La elección entre ellos es esfuerzo contra control: OpenCost es el motor vendor-neutral que necesita Prometheus y Grafana; Kubecost es el mismo motor más una UI con retención y recomendaciones de ahorro, gratis para un clúster, con multi-cluster y SSO desde ~$449 al mes (el proyecto es propiedad de IBM). Para EKS de un solo clúster existe un bundle gratuito optimizado para EKS.
AWS SCAD es otra categoría: una función de facturación que divide el coste de EC2 hasta nivel de pod directamente en los datos de la factura. Los datos llegan solo al CUR — Cost Explorer no los ve, y se consultan vía Athena. A cambio, SCAD cuadra con la factura real — Savings Plans, RI y Spot incluidos, mientras que OpenCost y Kubecost calculan todo a precios de lista on-demand y no cuadrarán con la factura. El montaje maduro mantiene ambos: OpenCost o Kubecost para la eficiencia de ingeniería («dónde está el waste ahora mismo»), SCAD para el chargeback de grado financiero («qué se imputa a qué equipo»).
Idle cost y reglas de asignación
La regla base: namespace = equipo. Más fino — asignación por labels (team, cost-center, service). Un pod sin resources.requests no se asigna en absoluto — no hay nada que imputarle; la obligación de requests debe vivir en una admission policy vía Kyverno o Gatekeeper.
Una categoría aparte es el idle cost: (capacidad del nodo − suma de requests) × precio del nodo. Esconderlo no es una opción: o se reparte a prorrata entre los namespaces, o se crea un namespace dedicado __idle__ — para que el propio hecho del overprovisioning quede visible en el dashboard. El anti-patrón: un namespace compartido por varios equipos — la asignación se convierte en ficción.
De la asignación a la unit economics
El siguiente nivel es el coste por unidad de negocio: coste por request, coste por tenant. Una consulta PromQL divide la métrica de coste del namespace entre la métrica de negocio del servicio — y el dashboard muestra «$X por millón de requests, tendencia del Y % al mes». A partir de ahí el coste se vuelve un quality gate igual que la error rate: un AnalysisTemplate de Argo Rollouts bloquea el despliegue si el coste por request supera el umbral.
Para los casos básicos también hay un camino sin OpenCost: AWS importa los labels de K8s como Cost Allocation Tags, y «cuánto gastó el equipo X» aparece directamente en Cost Explorer. Pero la asignación del idle, la atribución de red y las consultas de unit economics quedan fuera de ese camino.
El despliegue cabe en una semana: OpenCost exportando a Prometheus, un dashboard en Grafana, labels en los workloads, el idle hecho explícito. Los 10 namespaces principales suelen concentrar el ~80 % del gasto — empezar por ahí. Las prácticas FinOps maduras alcanzan ahorros del 20–54 %, pero el primer paso es siempre el mismo: ver quién gasta. Optimizar sin asignar es adivinar.