Six everyday words carry the whole topic. Learn them once and the rest is easy.

Most modern software does not run on computers that a company owns. It runs on computers rented from a cloud provider such as Amazon Web Services, Google Cloud or Microsoft Azure. You rent only what you need and pay by the hour, by the gigabyte or by the request. That is wonderfully flexible, and it also means the bill changes every single day depending on what your software did.

OpenTelemetry, usually written OTel, is the free, vendor-neutral standard for producing and moving metrics, traces and logs. It gives every language the same way of attaching descriptive labels to telemetry, which is exactly what attribution needs. The labels are called attributes, and they are the thread that ties a cost to a cause.

A plain definition, a restaurant, and the difference between guessing and measuring.

Cost attribution is the practice of assigning each unit of spend to the thing that caused it. That “thing” is called the cost object, and it can be a team, a product, a customer, a feature, an environment such as testing or production, or even a single type of request. The goal is to be able to say, with evidence, “this much of last month’s bill was caused by that.”

You will often hear two related words. Cost allocation is the act of splitting a cost among owners by some rule. Cost attribution puts the stress on cause: the split should follow what each owner actually consumed. In everyday speech the two are used almost interchangeably, and this guide does the same, but it keeps the stress on evidence.

Three ways to split a bill

• Even split. Divide by the number of owners. Easy to do and easy to resent.
• Tag-based split. Charge each resource to the owner named in its tag. Fair when a resource has exactly one owner.
• Usage-based split. Measure how much of a shared resource each owner used, then divide the cost in that proportion. This is where telemetry becomes essential.

Real organizations use all three, in layers. Resources with a clear single owner are charged directly. Shared resources are split by measured usage. Whatever cannot be measured is split by a simple, openly stated rule. A good attribution system also tells you how much of the bill falls into each layer, so you know how much of the answer is measured and how much is estimated.

Why this matters more every year

Three trends make attribution harder to skip. First, systems are split into more and smaller services, so a single customer action may touch thirty of them, and nobody sees the whole cost of that action. Second, cloud spending has moved from a quiet line in the technology budget to one of the largest items a company pays, which means finance leaders now ask engineers detailed questions. Third, new kinds of usage-based services, such as language models that charge per chunk of text, can multiply a bill within days when a feature becomes popular.

Without attribution, the usual reaction to a surprising bill is a company-wide request to “reduce cloud spend by ten percent.” That sounds firm, but it punishes everybody equally, including the teams that were already efficient. With attribution, the reaction can be precise: the cost of one feature rose, here is the cause, and here is who can fix it.

The bill is organized the way the provider sells things, not the way your business works.

A cloud bill is a perfectly honest record of what the provider charged. The trouble is the shape of that record. It is organized by the provider’s catalog: so many hours of this server type, so many gigabytes of that storage class. Your business is organized differently, around products, customers and teams. The two views do not line up on their own.

Four reasons tags cannot do it alone

Three words from the world of cloud financial management, and what each one asks of your data.

The discipline that deals with cloud money is called FinOps, a blend of “finance” and “operations.” It is a practice, not a product, and it has an industry body, the FinOps Foundation, that publishes shared vocabulary. Attribution sits at its heart because every other FinOps activity, such as budgeting, forecasting and optimization, needs to know whose money is being discussed.

The industry also maintains a common data layout for billing records, called FOCUS, short for the FinOps Open Cost and Usage Specification. Its purpose is to let cost data from different providers look alike, so a single attribution system can read all of them. If you join telemetry to billing data, using a common layout saves a great deal of translation work.

Why telemetry is the key to the third one

Showback and chargeback need to know who. Unit economics needs to know how many. The number of orders, the number of active customers and the number of messages processed are all business events, and a well-instrumented system already counts them, because the same counts feed its dashboards. Telemetry therefore supplies both halves of the fraction: the cost on top, split by cause, and the unit count underneath.

Each kind of telemetry measures something different. Knowing their strengths tells you which to use for which cost.

No single signal answers every attribution question. Think of them as different instruments in a workshop.

Notice that the last card is not telemetry at all. Attribution needs two data sources: usage evidence from your own software, and cost data from your provider. The craft is in joining them over a shared key, such as a resource identifier, a namespace or a service name, and over a shared time window, such as an hour or a day.

flowchart LR
A["Metrics of resource use"] --> J["Join on resource and time window"]
B["Traces and business events"] --> J
C["Cloud billing export"] --> J
J --> D["Cost per team, customer and feature"]
    

A cost can only be assigned to an owner if the telemetry names that owner. This chapter is about the labels.

Every piece of telemetry can carry attributes, which are simple name and value pairs. For attribution, a handful of attributes matter far more than the rest. They answer the questions “which team,” “which service,” “which customer,” “which feature” and “which environment.”

Three places an attribute can live

Resource attributes describe the thing producing telemetry and stay the same for the life of a process. Span attributes describe one particular operation and can differ on every request. Baggage is a standard way of carrying small name and value pairs along with a request as it hops from service to service, so that a service deep in the chain still knows which customer started the request.

sequenceDiagram
participant C as Customer App
participant G as Gateway
participant O as Orders Service
participant D as Database
participant W as Queue Worker
C->>G: Place order
Note over G: Gateway sets baggage tenant and feature
G->>O: Call with baggage in headers
O->>D: Query tagged with tenant
O->>W: Message with baggage in its headers
Note over W: Worker reads tenant and records usage
    

Where identity gets lost

• Queues and background jobs. The request ends, and the work continues later with no connection to the original caller unless the identity is copied into the message.
• Caches. A cache hit serves one customer with data that another customer paid to compute.
• Batch jobs. A nightly job processes everyone at once and needs its own per-customer accounting.
• Services without instrumentation. One silent service breaks the chain for everything beyond it.

Four rules cover almost every case. A small worked example shows how they fit together.

Every line of the bill gets sorted into one of four buckets, each with its own rule.

flowchart TB
C["A line on the cloud bill"] --> T{"Does it carry a trusted owner tag?"}
T -- "Yes" --> D["Direct allocation to that owner"]
T -- "No" --> U{"Can telemetry measure who used it?"}
U -- "Yes" --> P["Proportional allocation by measured usage"]
U -- "No" --> S{"Is it shared by everyone?"}
S -- "Yes" --> F["Shared pool split by a fixed rule"]
S -- "No" --> X["Unallocated bucket to investigate"]
    

A worked example

A shared cluster costs $30,000 for the month. Over that month it could have supplied 100,000 core-hours of processing, where a core-hour is one processor core running for one hour. Telemetry shows three teams used 80,000 core-hours in total.

The price of one core-hour of capacity is $30,000 divided by 100,000, which is $0.30. Now charge each team for what it used.

The idle cost of $6,000 is spread in proportion to use. Checkout used 50 percent of the 80,000 used core-hours, so it carries 50 percent of the idle cost, which is $3,000. Search used 31.25 percent and carries $1,875. Recommendations used 18.75 percent and carries $1,125. Add the final column: 15,000 plus 9,375 plus 5,625 equals 30,000. Every dollar is explained, and none is counted twice.

Five stations take raw telemetry and raw billing records and turn them into a number a finance team will trust.

An attribution system is not one program. It is a short pipeline, much like a factory line, in which each station does one job. Here is the whole picture.

flowchart LR
A["Applications with OTel SDK"] --> B["OpenTelemetry Collector"]
B --> C["Usage Store"]
E["Cloud Billing Export"] --> F["Cost Warehouse"]
H["Service Catalog of owners"] --> G["Allocation Engine"]
C --> G
F --> G
G --> I["Dashboards and Reports"]
G --> J["Budget Alerts"]
    

The Collector does much of the heavy lifting

The OpenTelemetry Collector is a standalone program that receives telemetry, changes it and forwards it. Several of its parts are especially useful here. A resource detection processor adds cloud and host facts automatically. A Kubernetes attributes processor labels telemetry with the pod, namespace and deployment it came from. An attributes or transform processor renames values and fixes inconsistent labels, for example mapping “prod,” “production” and “PRD” to one spelling. A span metrics connector turns traces into counters and timing summaries, grouped by chosen labels. Component names and options change between releases, so check the documentation for your version.

Why aggregate early

Raw traces and logs are enormous. Attribution does not need every individual event. It needs totals by owner and hour. Summing close to the source cuts storage and speeds up every later step. The trade-off is that an aggregated record cannot be unpicked later, so keep a short window of raw data for investigations.

Choosing the join key

The join is the hardest step, so it is worth planning. A join key is a value that appears on both sides and lets you match a usage record to a cost record. The best keys, from strongest to weakest, are these. A resource identifier, such as the unique name of a server or database, matches exactly, but only works when telemetry records that identifier. A cluster and namespace pair works well for container platforms. A service name works when the owner catalog maps service names to billing groups. A tag value works when tags are consistent. When no strong key exists, fall back to a weaker one and mark the result as lower confidence.

Time is the second key. Billing records usually cover an hour or a day, while telemetry arrives every few seconds. Bring both to a common window, for example one hour, before matching. If one side is late, hold the window open until it arrives instead of joining half-finished data, because a half-joined hour produces a number that looks precise and is wrong.

Containers make resources efficient and bills opaque. Here is how telemetry cuts through.

Kubernetes is software that packs many programs, each running in a small box called a container, onto a pool of shared servers called nodes. This is efficient, because ten teams can share one pool. It is also confusing for billing, because the provider charges for the nodes and knows nothing about the containers on them.

flowchart LR
N["Node pool cost from the bill"] --> A["Namespace Checkout"]
N --> B["Namespace Search"]
N --> C["Namespace Recommendations"]
N --> I["Idle capacity"]
I --> A
I --> B
I --> C
    

Two ways to measure a container

Each container usually declares a request, which is the amount of processor and memory it asks the cluster to reserve, and then actually uses some amount. Both numbers appear in standard Kubernetes metrics. Processor use is commonly exposed by the node’s container monitor, and requests are exposed by a state-reporting add-on. A request-based charge pays for room that was reserved, and a usage-based charge pays for room that was consumed.

Which is right? Tools in this area, including the open-source OpenCost project, commonly charge the larger of the two. The reasoning is fair: if a team reserved four cores, nobody else could use them, so the team should pay for blocking them, even if it used only one. This gives teams a direct reason to size their requests honestly, and it turns a vague complaint about “wasteful teams” into a measurable gap of $648 per month in this example.

What else lives on the nodes

Not everything in a cluster belongs to a team. The cluster’s own system programs, monitoring agents and networking components consume resources too. Treat these as a shared platform cost and spread them by a stated rule, usually in proportion to each team’s own consumption. Namespaces, labels and annotations on workloads give you the owner. If a workload has no owner label, that is a finding in itself, and it belongs in the unallocated bucket until someone claims it.

Servers are only part of the bill. Every other category needs its own meter.

The previous chapters used processor time as the measuring stick. Real bills contain many other kinds of cost, and each one needs a different piece of evidence.

An AI example

Language models bill by tokens, with different prices for what you send in and what comes back. OpenTelemetry’s semantic conventions for generative AI define standard attribute names for these token counts, although the area is still evolving, so check the current status. Suppose an “email summary” feature makes 2,000 calls a day, each sending 1,500 input tokens and receiving 500 output tokens. Using made-up prices of $3 per million input tokens and $15 per million output tokens: input is 2,000 x 1,500 = 3,000,000 tokens, or $9 a day. Output is 2,000 x 500 = 1,000,000 tokens, or $15 a day. The feature costs $24 a day, about $720 for a 30-day month. Without per-feature token counts, that spend would be one anonymous line labeled “AI provider.”

Once costs are attributed, dividing them by business activity shows whether you are making or losing money.

Imagine a software company whose platform costs $90,000 a month to run. It serves three customers, called tenants, and telemetry counts the requests each made.

The cost per million requests is $90,000 divided by 100, which is $900. Acme made 60 of those millions, so $54,000. Borealis made 30, so $27,000. Cinder made 10, so $9,000. The three add to $90,000, as they must. The surprise sits in the Borealis row: the company earns $25,000 from a customer that costs $27,000 to serve. Without attribution, that customer looks healthy because it brings in real revenue. With attribution, it is a conversation about pricing, limits or efficiency.

Not every request costs the same

Counting requests treats a simple page load and a heavy report generation as equals. A more accurate approach gives each request type a weight based on measured resource use. If a report request uses five times the processing of a simple one, count it as five units. Traces provide the timings to calculate these weights, and you can refresh them every few months.

Other useful unit costs

• Cost per order, per booking or per message for product teams.
• Cost per active user for consumer products.
• Cost per thousand requests for platform and API teams.
• Cost per environment, to see how much the test and staging copies add on top of production.

Two properties of telemetry quietly distort the numbers. Both are easy to handle once you know about them.

Sampling: the missing receipts

Storing every trace is expensive, so most systems keep only a fraction. This is called sampling. It is fine for debugging, but dangerous for counting. If you keep one trace in ten, a naive count of stored traces is ten times too small.

flowchart LR
S["Spans from services"] --> M["Span metrics connector counts every span"]
M --> U["Usage metrics for attribution"]
S --> T["Tail sampler keeps about 10 percent"]
T --> B["Trace backend for debugging"]
    

Two safe approaches exist. The first is to count before sampling, as the diagram shows, so the usage numbers see every request, and only the stored traces are reduced. The second is to record the sampling probability with each kept trace and multiply by its inverse. If 1,000 sampled spans each represent a one-in-ten chance, the estimate is 10,000. The first approach is simpler and exact. The second is useful when only sampled data exists, but it adds statistical error, especially for small customers who appear in few samples.

Cardinality: too many labels

Cardinality is the number of different label combinations a metric can have. Every combination becomes a separate series that a monitoring system must store and usually charges for. Adding a tenant label to a metric is tempting, because it is exactly what attribution wants. But consider 5,000 tenants, 50 endpoints and 5 status codes. That is 5,000 x 50 x 5 = 1,250,000 separate series from one metric, and a big bill for your monitoring system on top of the cloud bill you were trying to understand.

Ways to keep cardinality under control

• Separate a usage stream. Emit one compact usage record per tenant per hour, rather than putting tenant on every request metric.
• Group the small ones. Label the top fifty tenants individually and put the rest in an “other” group, or use a plan tier.
• Keep the identifier in traces and logs. Those systems handle detailed fields better than metric stores do.
• Drop labels nobody uses. Every label should answer a question someone actually asks.

An attribution report is only useful if finance believes it. Trust comes from a few simple checks.

The first rule is the one the worked examples already followed: the attributed amounts must add up to the bill. After allocation, sum every owner’s cost, plus any unallocated bucket, and compare it with the provider’s invoice total for the period. If the two differ, something was dropped or counted twice. This single check catches a surprising share of bugs, and it is what turns a clever dashboard into an auditable report.

Which price are you dividing?

Cloud providers publish several versions of cost, and they can differ a lot. Unblended cost is what each line was charged on the day. Amortized cost spreads upfront commitments, such as a prepaid discount for committing to a year of usage, across the months that benefit from them. Using unblended cost means the team that happens to be running on the day a big payment is made looks expensive. Amortized cost is usually fairer for attribution, and finance teams should agree which view the reports use, and write it down.

Timing issues

• Billing data arrives late. Final charges, credits and corrections can take days after the month ends. Publish a provisional report early, mark it provisional, and replace it when the bill is final.
• Time zones and windows. Billing records and telemetry may use different clocks and windows. Align them to the same hour boundaries before joining.
• Credits and discounts. Decide whether they are shared across everyone or credited to the team that earned them.

Showing confidence

When someone disputes a number

Sooner or later a team will say “that cost is not ours.” Disputes are healthy, because they find real mistakes, but they need a calm routine. Keep every step of the calculation reproducible, so that anyone can see which usage records and which cost lines produced a given figure. Offer the team a view of the raw usage behind its number, for example the hourly processor use by namespace. Most disputes end there, because the data answers the question.

• Missing identity. The team is right, a service did not carry its label, and the fix is to repair the label and re-run the month.
• Shared rule disagreement. The measurement is right, but the team disagrees with the rule for sharing a common cost. That is a policy conversation, not a data bug, and it belongs with finance and the platform owners.
• Timing difference. A late credit or a correction has moved the final bill. Update the report and note the change.

Record every correction with a date and a reason. Over time that log becomes the best evidence that the system is honest, because it shows mistakes being found and fixed in the open.

Cost data names customers and teams. Handle it with the same care as any other business data.

Attribution data is sensitive in two ways. Per-customer cost and margin can reveal how much each contract is worth, which is information a company rarely wants everyone to see. And per-customer identifiers inside telemetry can be personal data, which privacy laws regulate.

An attribution system that quietly breaks is worse than none, because people keep trusting it.

Like any pipeline, attribution can decay. A team renames a service, a deployment drops a label, a new region appears with no tags. Each change moves a little more money into the “unknown” bucket, and nobody notices until a report looks odd. So the pipeline needs a small set of health measures of its own.

Cost anomalies are a bonus

Once cost is attributed per service and per hour, spotting oddities becomes straightforward. A service whose cost doubles overnight while its request count stays flat has probably shipped a regression, such as a loop that retries, an unbounded query or a debug setting left on. Alerts on cost per unit, rather than on total cost, avoid false alarms when traffic simply grows.

Eight patterns that mature teams use, and an honest look at what each choice costs.

A key trade-off: measure everything, or sample?

Another trade-off: precise or simple rules?

The sensible middle path is to start simple, which means owner tags and processor-time shares, and add detail only where the money justifies it. A team spending a few hundred dollars a month does not need per-request attribution. A product spending a million does.

Four habits that look sensible and quietly spoil the numbers.

Other frequent mistakes

• Counting sampled traces as if they were complete.
• Forgetting background jobs, queues and caches, so identity is lost.
• Reporting a number to the cent when the inputs are rough estimates.
• Changing allocation rules mid-year without versioning them.
• Ignoring the unallocated bucket because it is embarrassing.

A practical order of work that delivers useful answers early and adds precision later.

Maturity at a glance

Five illustrative stories showing how attribution changes decisions.

The scenarios below are illustrative composites. The numbers are chosen for clarity and are not measurements from any named company.

Common cloud tooling makes a first step easy. AWS offers cost allocation tags and detailed cost and usage reports, Google Cloud exports billing records to its BigQuery warehouse, and Azure provides cost management with tag-based grouping. The open-source OpenCost project covers Kubernetes. These supply the money side. Telemetry supplies the usage side.

Short answers to the questions people ask most often.