La mayoría de las empresas SaaS no saben explicar por qué atender a un cliente enterprise cuesta 20 veces más que atender a otro.
Los datos están ahí. Repartidos entre un cluster de Kubernetes, tres bases de datos compartidas, una cola de mensajes, una API externa de AI y un NAT gateway sin dueño. Para cuando llega la exportación de facturación, el costo ya se generó y el contexto que lo explica ya no aparece por ningún lado.
No es un problema de dashboard. Es un problema de datos. Y la mayoría de las herramientas lo intenta resolver con el dataset equivocado.
Cuándo basta con los datos de facturación y cuándo necesitas atribución en runtime
| Situación | ¿Basta con la exportación de facturación? |
| Infraestructura simple single-tenant | Sí |
| Equipo pequeño, una sola cuenta cloud | Sí |
| Microservicios en Kubernetes | Normalmente no |
| Producto SaaS multi-tenant | No |
| RDS, Kafka o Elasticsearch compartidos | No |
| Asignación de inferencia de AI por cliente o feature | No |
| Análisis de margen por cliente | No |
| Infraestructura self-managed (sistemas de datos alojados en EC2) | No |
| Atribución de NAT gateway y transferencia de datos | No |
Si tu entorno encaja en la mitad inferior de esa tabla, las exportaciones de facturación son apenas un punto de partida. No son una herramienta de optimización de costos. Para los equipos que operan features de AI, esta brecha es especialmente crítica: el gasto en tokens es solo una parte de la superficie de costos de AI. Las bases de datos vectoriales, las capas de orquestación, el egress y la infraestructura self-managed alrededor de la llamada al modelo suelen representar entre el 40 y el 60 por ciento del gasto total de un feature. Las herramientas que se limitan a leer la factura de tokens se pierden la mayor parte.
Por qué las herramientas tradicionales fallan al monitorear costos de Kubernetes
La facturación cloud se diseñó para un modelo estático: se aprovisiona un recurso, se le pone un tag y se lee el tag a fin de mes.
Kubernetes rompió todos los supuestos sobre los que se apoya ese modelo. Los pods son efímeros. Los servicios comparten infraestructura cruzando los límites de equipos y tenants. Una sola solicitud de un cliente atraviesa varios servicios antes de que se envíe una respuesta. ¿El resultado? Ningún tag captura quién consumió qué, solo quién es dueño del recurso. Y ser dueño no equivale a consumir.
La mayoría de las herramientas de monitoreo de costos de Kubernetes responden midiendo a nivel de cluster: asignación de CPU, requests de memoria, pod hours. Es contexto útil, pero no es atribución de costos. RDS, Kafka, Snowflake y la transferencia de datos suelen ser drivers de costo significativos y sub-atribuidos junto con el cluster. Las herramientas que se quedan a nivel de nodo y pod dejan la mayor parte de la factura sin atribuir.
De ahí se derivan cuatro fallos predecibles:
- El tagging termina siendo el proyecto. Los tags capturan propiedad, no consumo de recursos compartidos. El proyecto se alarga meses y nunca termina del todo.
- Los costos compartidos se asignan a ojo. Porcentajes estáticos y repartos parejos. Defendibles en una hoja de cálculo, pero no precisos.
- Falta la atribución a nivel de cliente. Se ve el gasto total, pero no el costo por tenant. Las cuentas rentables y las que no lo son se ven idénticas.
- Los datos llegan tarde. La exportación de facturación cierra a fin de mes. La pérdida ya ocurrió.
Cómo funciona realmente la atribución en runtime
La atribución en runtime parte de una fuente de datos totalmente distinta: lo que está pasando en el sistema justo ahora.
Attribute™ despliega un sensor eBPF sobre la infraestructura de cómputo: nodos EKS, tareas ECS, instancias EC2 y auto scaling groups. eBPF (extended Berkeley Packet Filter) es una tecnología del kernel de Linux que permite observar la actividad del sistema a nivel de kernel de forma segura y sandboxed. El sensor inspecciona paquetes de red en modo solo lectura, sin overhead de rendimiento y sin tocar el código de la aplicación.
Lo que observa el sensor:
- Cada llamada de red entre servicios
- Qué microservicio llama a qué base de datos y con qué frecuencia
- Cómo se está consumiendo realmente la infraestructura compartida
- Qué endpoints de APIs de AI son llamados por cada workload, con qué volumen de tokens y atribuidos a qué cliente, feature o agente
- Los headers HTTP que llevan identificadores de cliente
- Los destinos y volúmenes de transferencia de datos
A partir de estas observaciones, Attribute™ construye un grafo de dependencias entre servicios en vivo. Sabe qué servicios dependen de qué recursos, con qué intensidad y en qué proporciones. Ese grafo es el modelo de atribución.
Cuando una instancia RDS compartida genera costos, el modelo no aplica una regla estática. Analiza la distribución real de las queries a la base de datos entre servicios durante ese período y asigna el costo de forma proporcional al consumo real.
Los servicios nuevos se descubren automáticamente al aparecer. Las relaciones se actualizan a medida que cambian los despliegues. Sin catálogo de servicios estático. Sin reconfiguración manual.
Cómo se ve esto en la práctica
Caso de cliente: Island
La situación: Island está construyendo la categoría del enterprise browser con una valuación de US$5.000 millones y escalando a cientos de clientes enterprise. Su entorno AWS usa EKS, RDS y DynamoDB compartidos, además de una transferencia de datos AZ-a-AZ significativa. El tagging no era opción: no puedes ponerle un tag a un cliente en una arquitectura multi-tenant.
Antes: Sin visibilidad del costo real por cliente ni por feature. Sin forma de respaldar decisiones de pricing, modelado de crecimiento o GTM con datos de costo reales. Las herramientas nativas de la nube y las plataformas de terceros mostraban facturas y gráficos, pero no podían responder cuánto costaba realmente cada cliente.
Después: Attribute™ entregó costo por cliente y por feature con precisión en cuestión de días. Sin tagging, sin instrumentación y sin solicitudes al equipo de Engineering.
Cambio operativo: Engineering, producto y GTM ahora operan desde una fuente de costos compartida. Las decisiones de pricing y modelado de crecimiento se basan en datos de consumo reales, no en estimaciones.
"No puedes ponerle un tag a un cliente en un entorno multi-tenant. Attribute™ por fin nos muestra cuánto cuesta cada cliente y qué está detrás de esos costos.",
– Omri Cohen, Director of Engineering Platform, Island
¿Quieres leer más?: Haz clic aquí para leer cómo una plataforma líder de Work Management descubrió 360 cuentas no rentables, o aquí para ver cómo una empresa de seguridad desfragmentó los reportes de los departamentos de Finance y Engineering.
El mejor enfoque para la unit economics cloud y el cost-to-serve
La unit economics necesita un modelo de costos que mapee a la unidad real. En una empresa SaaS, esa unidad suele ser el cliente.
Esa pregunta no se responde desde las exportaciones de facturación. La facturación muestra costos de recursos, pero no muestra qué clientes consumieron esos recursos ni en qué proporciones.
La capa de atribución por cliente de Attribute™ mapea la actividad en runtime observada a identificadores de cliente, ya sea desde headers HTTP, etiquetas de workloads o convenciones de nombres en bases de datos o colas. Una vez establecida, cada evento de costo del modelo se atribuye al cliente que lo causó.
Al conectarlo con los datos de ingresos, el resultado es un P&L a nivel de cliente: qué cuentas son rentables, cuáles no y por cuánto.
Lo que se logra con esa visibilidad:
- Identificar cuentas de margen negativo antes de que se acumulen las pérdidas
- Detectar features de AI con costos fuera de control antes de que cierre el ciclo de facturación
- Dar a los equipos de plataforma números defendibles para el chargeback de infraestructura compartida
- Fijar el precio de contratos enterprise a partir del consumo real, no de suposiciones
- Justificar inversiones de arquitectura con datos reales de costos antes y después
- Poner fin a la disputa mensual entre finanzas e ingeniería sobre la metodología de asignación
Cómo es realmente el despliegue
Time to value: El sensor se despliega en Kubernetes mediante un DaemonSet. El descubrimiento inicial de workloads se completa en horas. La atribución de costos significativa está disponible en cuestión de días. Sin necesidad de un proyecto de tagging.
Overhead de rendimiento: El sensor eBPF es de solo lectura y corre en un sandbox a nivel del kernel. No intercepta ni modifica el tráfico. El overhead de cómputo es insignificante.
Integraciones: Attribute™ se instala sobre la infraestructura de cómputo (EKS, ECS, EC2) y monitorea el tráfico desde la capa de aplicación hacia otros recursos cloud, incluidos proveedores SaaS de terceros como MongoDB Atlas, Snowflake, OpenAI y otros. No requiere instrumentación a nivel de aplicación.
¿Reemplaza a Kubecost o CloudHealth? Para las empresas SaaS cuyas preguntas de costos van más allá del reporte a nivel de cluster, sí. Attribute™ va más lejos en atribución de recursos compartidos, cost-to-serve a nivel de cliente, cobertura de infraestructura self-managed y visibilidad completa de la superficie de costos de AI, incluida la atribución de tokens por cliente, feature o agente junto con el gasto de la infraestructura circundante que esas herramientas no ven.
Datos históricos: El histórico de facturación cloud se ingesta durante el setup. Para los equipos que necesitan entregables de chargeback antes de desplegar el sensor, Attribute™ puede generar reportes a partir de exportaciones de facturación proporcionadas por el cliente, sin necesidad del sensor.
Entornos soportados: AWS, GCP, Azure. Kubernetes (EKS, GKE, AKS), ECS, EC2. Snowflake, MongoDB Atlas, OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Vertex AI. Kafka self-managed (con granularidad a nivel de topic), Elasticsearch, RabbitMQ.
Seguridad: Se eliminan PII, credenciales, secretos, API keys y cookies antes de que ningún dato salga del entorno del cliente. Se transmiten eventos mínimos vía OpenTelemetry cifrado, autenticado con JWT y protegido con TLS. Los paquetes crudos nunca se transmiten. Opcionalmente, los clientes pueden enrutar la telemetría a través de su propio endpoint de OpenTelemetry para tener capacidad de auditoría completa.
Atribución en runtime vs herramientas basadas en facturación
Las herramientas basadas en facturación preguntan qué se cobró. La atribución en runtime pregunta qué pasó realmente en el sistema y quién lo causó.
Para los equipos que evalúan plataformas, cinco preguntas separan a las herramientas que responden lo que importa de las que no:
- ¿Funciona sin tags desde el día uno?
- ¿Puede asignar los costos de recursos compartidos con base en el consumo observado y no en reglas estáticas?
- ¿Puede atribuir costos por cliente en un sistema multi-tenant?
- ¿Puede ver la infraestructura self-managed y el gasto externo de AI?
- ¿Puede mostrar señales de costo durante el ciclo de facturación y no cuando ya cerró?
Para los equipos con un gasto significativo en AI, suma una sexta: ¿puede atribuir el costo de tokens a un cliente, feature o agente específico, y no solo a una API key? Las herramientas basadas en facturación responden algunas de esas preguntas de forma parcial, para ciertos entornos y con una inversión de setup considerable. La atribución en runtime las responde todas desde el despliegue.