When your Amazon Bedrock bill jumps and nobody can say which feature caused it, you do not have a pricing problem. You have an observability problem. The invoice tells you the account spent more on tokens. It does not tell you which agent, which tenant, or which code path did the spending, and without that attribution every cost conversation is a guess. You cannot optimise what you cannot measure, and most teams are measuring the total and nothing underneath it.

Token spend has a property that makes this worse than ordinary cloud cost: it is generated by a non-deterministic system. A prompt change, a retry loop, a chatty agent, or a user who found a way to make the model think harder can all move the bill, and none of them show up as a new resource on the invoice. The spend hides inside a single Bedrock line item. The job is to break that line item apart before it surprises you, not after.

Attribution is the whole game

The question that matters is never "how much did we spend on Bedrock." It is "how much did this spend, and is it worth it." Answering that needs a dimension on every unit of token spend. At minimum, tag each call with:

  • Feature or product area, so you can ask whether the summarizer or the chat assistant is the cost driver.
  • Tenant or customer, so you can see whether one account is subsidised by the rest and whether your pricing covers your cost to serve.
  • Agent or workflow, so a multi-step pipeline's cost is visible per step rather than as one opaque total.
  • Model, so you can tell when expensive traffic is going to a frontier model that a cheaper one would have handled.

Without these dimensions, cost optimisation degrades into blanket measures: cap everyone, or turn features off and watch which complaint arrives. With them, you can point at the exact path that grew and decide whether it earned the growth.

Two layers of instrumentation

Cost allocation tags for the invoice

AWS cost allocation tags are the coarse layer. Tag the resources and requests that drive Bedrock usage so the billing data itself carries your dimensions, and cost reports can group by feature or environment instead of showing one undifferentiated Bedrock figure. This is the view finance and platform owners live in. It is monthly-grained and good for the "where is the money going" conversation, not for catching a spike in the moment.

CloudWatch metrics for the real-time picture

The invoice is a lagging indicator. The leading indicator is token throughput, and that belongs in CloudWatch. Bedrock emits usage metrics, and you can publish your own custom metrics dimensioned per agent, per tenant, or per feature straight from the application:

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

Now spend is a graph you can alarm on. A per-agent token metric that triples overnight fires an alert on Tuesday, instead of a finance question at the end of the month. Read input and output separately, because output is priced higher and a runaway generation shows up there first.

What the visibility lets you do

Once every token is attributed, the optimisations stop being blunt. You can route the cheap, mechanical calls a per-agent metric reveals to a smaller model, and keep the frontier model for the reasoning that earns it. You can find the tenant whose cost to serve exceeds their plan and fix the pricing or the usage. You can catch the retry loop that a prompt change introduced, because its token count spiked while its request count did not. Every one of those moves requires knowing which slice of the bill to cut, which is exactly what the instrumentation gives you and the raw invoice never will.

The takeaway

A Bedrock bill you cannot decompose is a bill you cannot manage. Treat token spend as telemetry, not just an invoice line: tag it with cost allocation tags for the billing view, emit per-agent and per-tenant token metrics to CloudWatch for the real-time view, and alarm on the leading indicator so a spike is a page, not a postmortem. The teams whose LLM costs stay under control are not the ones with the best prices. They are the ones who can see, at any moment, exactly which feature, tenant, and agent is spending the money.

Read this next

For the FinOps and cloud cost-visibility playbook beyond LLMs, the cloud field notes live at ercan.cloud, and the hub is at ercanermis.com.