Cloud Intelligence™
Reportes en los que Finanzas realmente confía
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
About Devorah Klartag
Marketing director. 15+ years turning marketing vision into infrastructure that actually scales - GTM, demand gen, ops, and the AI-powered systems that keep the whole thing moving. At Attribute, I built the marketing function from the ground up and hit top-3 AI search rankings on competitive FinOps queries in ChatGPT, Perplexity, and Claude.
Previously: senior growth and marketing ops at D-ID (led the self-service studio launch that hit #1 Product of the Day on Product Hunt and landed coverage in TechCrunch, Fast Company, and Forbes), digital marketing at CyberProof, and $7M campaigns at McCann Tech for NICE and Amdocs. Earlier, hospitality marketing across NYC restaurants and cruise lines.
Ex-New Yorker in Tel Aviv. Still misses the bagels most.
My personal pagePasaste meses construyendo reportes y dashboards. Costos por equipo, costos por workload, chargeback por unidad de negocio. Para los Engineers, todo cuadra. Finanzas se suma a la revisión y pregunta: "¿Puedes respaldar estos números?"
Es complicado. Tus herramientas se apoyan en exports de facturación, motores de reglas y una cobertura de tags que apenas llega al 70%. Eso no es lo suficientemente sólido para tomar decisiones de negocio, hacer forecasts y proyecciones.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Por qué los números no se sostienen
Las herramientas de FinOps se crearon para leer el archivo de facturación que genera tu proveedor de nube, segmentarlo con reglas y tags, y mostrar el resultado en un dashboard.
Finanzas y la dirección del negocio hacen preguntas desde otro ángulo. ¿Cuánto cuesta atender al Cliente X? ¿Cuál de nuestros productos tiene margen positivo? La mayoría de las herramientas de FinOps te dan una respuesta. Muy pocas te dan una respuesta auditable.
Qué significa realmente "basura"
Cuando un stakeholder califica un reporte de costos como "basura", está reaccionando a números que no coinciden con lo que sabe que es cierto, o no logra entender cómo se calcularon.
En la práctica, casi siempre se reduce a tres cosas:
Reglas que alguna vez tuvieron sentido, pero quedaron obsoletas.
Tus reglas de asignación se configuraron hace 18 meses. Tres migraciones y dos rebrands de producto después, las reglas siguen apuntando a servicios y etiquetas que ya no significan lo mismo. Los números se ven consistentes en el dashboard porque las reglas se ejecutan de forma consistente. Nadie verificó si las reglas seguían siendo correctas. Todos asumieron que la limpieza era responsabilidad de alguien más.
Tags que nunca alcanzaron cobertura total.
La atribución basada en tags solo cubre los recursos etiquetados. El 30% que Engineering nunca etiquetó se descarta o se distribuye mediante un reparto sintético. Cuando Finanzas pregunta "qué hay en la categoría sin asignar", la respuesta honesta es: una porción significativa del gasto real. La inferencia de IA lo empeora: la mayoría de los equipos ni siquiera sabe cómo etiquetar las llamadas a modelos, mucho menos por funcionalidad o por cliente.
Datos obsoletos en el modelo. Cuentas antiguas, servicios dados de baja, contratos que terminaron, pero los datos históricos siguen en el modelo.
El problema del P&L por producto
El problema de confianza se agrava cuando los equipos de FinOps intentan responder la verdadera pregunta de Finanzas: no "cuánto cuesta este workload", sino "cuánto cuesta este producto, por región, por segmento de cliente".
Esa pregunta requiere más que datos de costos. A un cliente que ejecuta tres productos en cinco regiones no le importa a qué namespace de Kubernetes pertenece el gasto. Lo que importa es si el cliente es rentable. Requiere saber qué workload atiende a qué producto, qué clientes consumen qué workloads y cómo se reparte la infraestructura compartida entre todo lo anterior. Las herramientas estándar de FinOps pueden aproximarlo con suficiente etiquetado y definición de reglas. Pero las aproximaciones no resisten cuando un VP pide la metodología subyacente.
Lo que Finanzas realmente quiere es el costo de servir a nivel de cliente y de producto, incluyendo componentes fijos y variables, incluyendo el gasto en SaaS de terceros como Snowflake o Twilio, en un formato que pueda defender ante la junta directiva. Los equipos de Precios lo necesitan para fijar márgenes. Finanzas lo necesita para reportar el COGS. Los líderes de producto lo necesitan para saber qué funcionalidades están erosionando el margen.
La mayoría de las herramientas de costos de nube son muy buenas respondiendo "¿por qué subió nuestra factura de AWS?". Nunca se diseñaron para responder "¿este producto está dando ganancias?".
El mismo problema está llegando ahora más rápido con el gasto en IA. Los costos de inferencia de LLM no se comportan como EC2. Dependen de las solicitudes, son por cliente y se acumulan rápido. Un export de facturación te dice cuánto te cobró Bedrock u OpenAI el mes pasado. No te dice qué funcionalidad del producto lo generó, qué segmento de clientes lo consumió, ni si los unit economics se sostienen a escala. Volumen de tokens, selección de modelo, longitud del prompt: nada de eso se refleja en una línea de facturación. Finanzas está empezando a preguntar por el COGS de IA de la misma forma en que pregunta por el COGS de nube. La brecha de datos es idéntica. Y hay más en juego, porque los costos avanzan más rápido.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
El problema de reconstruir la realidad
Toda herramienta basada en exports de facturación tiene la misma limitación estructural. El archivo de facturación te dice cuánto te cobraron. No te dice por qué, qué clientes lo generaron ni cómo se reparten realmente los recursos compartidos entre los consumidores.
Attribute lee el sistema en vivo en lugar del archivo de facturación. Un sensor eBPF ultraligero, desplegado en tu infraestructura de cómputo, observa qué workloads se comunican con qué bases de datos y servicios usando datos de runtime, en la capa de red. La atribución de costos sigue el comportamiento real, no reglas sobre el comportamiento esperado.
La diferencia importa sobre todo cuando un stakeholder pregunta de dónde salió un número. Con la atribución basada en facturación, lo rastreas a través de una cadena de reglas y supuestos. Con la atribución en runtime, lo rastreas hasta la actividad de red observada.
Cómo se ve esto en la práctica
Tomemos la visibilidad de costos por equipo, una de las solicitudes más frecuentes en FinOps. Con una herramienta basada en tags, la visibilidad de los costos por equipo llega solo hasta donde llegan tu cobertura de tags y la higiene de tus etiquetas. Los namespaces compartidos son un problema. Los servicios que Engineering desplegó la semana pasada y aún no etiquetó son invisibles.
El sensor de Attribute detecta los nuevos workloads automáticamente, porque los observa comunicándose en la infraestructura en lugar de esperar a que alguien los etiquete. Cuando tu equipo necesita mostrar el " costo facturable por equipo", el enfoque de runtime produce un número que puedes defender porque refleja lo que realmente está en ejecución.
El mismo principio aplica a nivel de cliente. Si necesitas saber cuánto cuesta realmente atender a un cliente específico, incluyendo infraestructura fija, cómputo variable y herramientas SaaS, no puedes llegar ahí desde un export de facturación sin un mapeo manual considerable. Attribute construye ese mapeo a partir de lo que observa: qué workloads de cada cliente tocan qué servicios, en qué volumen y a qué costo. Cuando los clientes piden el costo del producto por región o la rentabilidad del producto en distintos tipos de servicio, esa pregunta tiene una respuesta real y no una estimación.
Lo mismo aplica a los costos de IA. El sensor de Attribute lee las llamadas en la capa de red: qué servicio hizo la llamada, qué workload de cliente la disparó y cuánto costó. Ese es el número que un equipo de Precios puede usar para decidir si absorbe el costo de inferencia o lo traslada al cliente.
Attribute ayuda a los equipos de FinOps y Finanzas a entender qué está pagando realmente su gasto en nube y SaaS, usando atribución en runtime en lugar de tags manuales y exports de facturación.
¿Por qué los reportes de costos de nube no pasan las revisiones de Finanzas?
La mayoría de las herramientas de FinOps construyen reportes a partir de exports de facturación, reglas de asignación y tags. Las reglas quedan obsoletas. La cobertura de tags rara vez es completa. Cuando Finanzas pregunta cómo se calculó un número, la respuesta honesta lleva a una cadena de supuestos, no a datos observados. Esa es la brecha.
¿Qué es la atribución de costos en runtime?
La atribución en runtime significa que los costos siguen el comportamiento real del sistema en lugar de reglas sobre el comportamiento esperado. Attribute despliega un sensor eBPF que observa qué workloads se comunican con qué servicios a nivel de runtime. Cada costo se rastrea hasta la actividad de red observada, no hasta una decisión de etiquetado tomada hace 18 meses.
¿Cómo se maneja el gasto sin etiquetar?
Con las herramientas basadas en tags, los recursos sin etiquetar se descartan o se distribuyen mediante un reparto sintético. El sensor de Attribute detecta los workloads sin importar si fueron etiquetados o no, porque los observa comunicándose en la infraestructura. Los nuevos servicios desplegados la semana pasada son visibles de inmediato.
¿Puede Attribute mostrar el costo de servir por cliente?
Sí. Attribute mapea el gasto en nube y SaaS a cada cliente final observando qué workloads de cliente tocan qué servicios, en qué volumen y a qué costo. Eso produce el verdadero costo de servir, incluyendo infraestructura fija, cómputo variable y herramientas de terceros como Snowflake o Twilio.
¿Qué pasa con los costos de IA y de inferencia de LLM?
Los costos de inferencia no aparecen en los exports de facturación con el detalle suficiente para ser útiles. El sensor de Attribute lee las llamadas a los modelos en la capa de red, atribuyendo cada solicitud al servicio, cliente y funcionalidad que la disparó. Ese es el número que los equipos de Precios necesitan para fijar los márgenes de las funcionalidades de IA.
¿En qué se diferencia de CloudZero o Apptio?
Esas herramientas trabajan a partir de exports de facturación y requieren etiquetado antes de mostrar datos significativos. Attribute lee el sistema en vivo. No requiere tags ni mantenimiento de reglas, y la metodología se sostiene cuando un stakeholder pregunta de dónde salió un número.
