Most SaaS companies cannot explain why one enterprise customer costs 20x more to serve than another.
The data exists. It is spread across a Kubernetes cluster, three shared databases, a message queue, an external AI API, and a NAT gateway with no ownership attached. By the time the billing export arrives, the cost has happened. The context that explains it is gone.
This is not a dashboard problem. It is a data problem. Most tools are solving it with the wrong dataset.
When Billing Data Is Enough vs When You Need Runtime Attribution
| Situation | Billing Export Enough? |
| Simple single-tenant infrastructure | Yes |
| Small team, one cloud account | Yes |
| Kubernetes microservices | Usually no |
| Multi-tenant SaaS product | No |
| Shared RDS, Kafka, or Elasticsearch | No |
| AI inference allocation by customer or feature | No |
| Customer margin analysis | No |
| Self-managed infrastructure (EC2-hosted data systems) | No |
| NAT gateway and data transfer attribution | No |
If your environment maps to the bottom half of that table, billing exports are a starting point. They are not a cost optimization tool. For teams running AI features, this gap is especially acute: token spend is only part of the AI cost surface. Vector databases, orchestration layers, egress, and self-managed infrastructure around the model call routinely represent 40 to 60 percent of total feature spend. Tools that read only the token bill miss most of it.
Why Traditional Tools Fail at Kubernetes Cost Monitoring
Cloud billing was designed for a static model: provision a resource, tag it, read the tag at month end.
Kubernetes broke every assumption that model depends on. Pods are ephemeral. Services share infrastructure across team and tenant boundaries. A single customer request spans multiple services before a response is sent. The result: no tag captures who consumed what, only who owns the resource. And ownership is not consumption.
Most Kubernetes cost monitoring tools respond by measuring at the cluster level, CPU allocation, memory requests, pod hours. That is useful context. It is not cost attribution. RDS, Kafka, Snowflake, and data transfer are often a significant and under-attributed cost driver alongside the cluster. Tools that stop at the node and pod level leave most of the bill unattributed.
Four failures follow predictably:
- Tagging becomes the project. Tags capture ownership. They cannot attribute shared resource consumption. The project takes months and never fully finishes.
- Shared costs get allocated by guesswork. Static percentages and even splits. Defensible in a spreadsheet. Not accurate.
- Customer-level attribution is missing. Total spend is visible. Cost per tenant is not. Profitable and unprofitable accounts look identical.
- The data arrives too late. The billing export closes at month end. The waste already happened.
How Runtime Attribution Actually Works
Runtime attribution starts from a different data source entirely: what is actually happening in the system right now.
Attribute™ deploys an eBPF sensor on compute infrastructure, EKS nodes, ECS tasks, EC2 instances, auto scaling groups. eBPF (extended Berkeley Packet Filter) is a Linux kernel technology that enables safe, sandboxed observation of system activity at the kernel level. The sensor inspects network packets read-only, with no performance overhead and no changes to application code.
What the sensor observes:
- Every network call between services
- Which microservice is calling which database, and how often
- How shared infrastructure is actually being consumed
- Which AI API endpoints are called by which workload, at what token volume, and attributed to which customer, feature, or agent
- HTTP headers carrying customer identifiers
- Data transfer destinations and volumes
From these observations, Attribute™ builds a live service dependency graph. It knows which services depend on which resources, at what intensity, in what proportions. That graph is the attribution model.
When a shared RDS instance incurs costs, the model does not apply a static rule. It looks at the actual distribution of database queries across services during that period and allocates cost proportionally to real consumption.
New services are discovered automatically when they appear. Relationships update as deployments change. No static service catalog. No manual reconfiguration.
What This Looks Like in Practic e
Customer Case Study: Island
The situation: Island is building the enterprise browser category at a $5B valuation, scaling to hundreds of enterprise customers. Their AWS environment uses shared EKS, RDS, DynamoDB, and significant AZ-to-AZ data transfer. Tagging was not an option, you cannot tag a customer in a multi-tenant architecture.
Before: No visibility into true cost per customer or cost per feature. No ability to support pricing, growth modeling, or GTM decisions with real cost data. Native cloud tools and third-party platforms could show bills and charts. They could not answer what each customer actually cost.
After: Attribute™ delivered accurate cost per customer and per feature within days. No tagging, no instrumentation, no engineering requests.
Operational change: Engineering, product, and GTM now operate from a shared cost source. Pricing and growth modeling decisions are based on real consumption data, not estimates.
“You can’t tag a customer in a multi-tenant environment. Attribute™ finally shows us what each customer costs and what’s driving those costs.”,
– Omri Cohen, Director of Engineering Platform, Island
Want to read more?: Click here to read how a leading Work Management platform discovered 360 unprofitable account, or here to read how a security company defragmented reporting for Finance and Engineering departments.
The Best Approach to Cloud Unit Economics and Cost-to-Serve
Unit economics require a cost model that maps to the actual unit. For a SaaS company, the unit is usually the customer.
That question cannot be answered from billing exports. Billing shows resource costs. It does not show which customers consumed those resources or in what proportions.
Attribute™’s customer attribution layer maps observed runtime activity to customer identifiers, from HTTP headers, workload labels, or naming conventions in database or queue names. Once established, every cost event in the model is attributed to the customer that caused it.
When connected to revenue data, the output is customer-level P&L: which accounts are profitable, which are not, and by how much.
What follows from that visibility:
- Identify negative-margin accounts before losses accumulate
- Detect AI features with runaway cost before the billing cycle closes
- Give platform teams defensible numbers for shared infrastructure chargeback
- Price enterprise contracts from actual consumption, not assumptions
- Justify architecture investments with real before/after cost data
- End the monthly dispute between finance and engineering about allocation methodology
What Deployment Actually Looks Like
Time to value: The sensor deploys on Kubernetes via a DaemonSet. Initial workload discovery completes within hours. Meaningful cost attribution is available within days. No tagging project required.
Performance overhead: The eBPF sensor is read-only and sandboxed at the kernel level. It does not intercept or modify traffic. Compute overhead is negligible.
Integrations: Attribute™ is installed on compute infrastructure (EKS, ECS, EC2) and monitors traffic from the application layer to other cloud resources, including third-party SaaS providers like MongoDB Atlas, Snowflake, OpenAI, and others. No application-level instrumentation required.
Does this replace Kubecost or CloudHealth? For SaaS companies whose cost questions go beyond cluster-level reporting, yes. Attribute™ goes further on shared resource attribution, customer-level cost-to-serve, self-managed infrastructure coverage, and full AI cost surface visibility, including token attribution by customer, feature, or agent alongside the surrounding infrastructure spend those tools don’t see.
Historical data: Cloud billing history ingests on setup. For teams that need chargeback deliverables before sensor deployment, Attribute™ can generate reports from customer-supplied billing exports without the sensor.
Supported environments: AWS, GCP, Azure. Kubernetes (EKS, GKE, AKS), ECS, EC2. Snowflake, MongoDB Atlas, OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Vertex AI. Self-managed Kafka (including topic-level granularity), Elasticsearch, RabbitMQ.
Security: PII, credentials, secrets, API keys, and cookies are stripped before any data leaves the customer environment. Minimal events transmitted via encrypted OpenTelemetry, JWT-authenticated, TLS-protected. Raw packets are never transmitted. Customers can optionally route telemetry through their own OpenTelemetry endpoint for full audit capability.
Runtime Attribution vs Billing-Based Tools
Billing-based tools ask what got charged. Runtime attribution asks what actually happened in the system and who caused it.
For buyer teams evaluating platforms, five questions separate tools that can answer the questions that matter from those that can’t:
- Does it work without tags from day one?
- Can it allocate shared resource costs based on observed consumption rather than static rules?
- Can it attribute cost by customer in a multi-tenant system?
- Can it see self-managed infrastructure and external AI spend?
- Can it surface cost signals during the billing cycle, not after it closes?
For teams with meaningful AI spend, add a sixth: can it attribute token costs to a specific customer, feature, or agent, not just an API key? Billing-based tools answer some of those questions partially, for some environments, with significant setup investment. Runtime attribution answers all of them from deployment.