Your Bedrock bill, graded every week

A month ago we put the Bedrock bill on the weekly report: which model, which token type. That answered "where did it go". It did not answer the question that comes right after: is that healthy?

Today the scan answers it. unusd.cloud started as a tool for idle AWS resources. AI inference is now a standing line on the same bills we scan, so it gets the same treatment: read-only, deterministic, every week, in the same report and the same digest.

The playbook, as a weekly scan

At the end of October, AWS published a playbook for managing Amazon Bedrock costs. It asks FinOps and platform teams to attribute every dollar, log every request, enforce budgets, fix the platform defaults, and review a short scorecard every week.

That last step is the one most teams skip, because someone has to build the dashboard first. A weekly scan is already a review cadence. So the scorecard is now part of it.

Three signals, each green, yellow, or red:

• Cache efficiency. The share of prompt tokens read from the prompt cache. Above 60% is green, under 30% is red. A cache read costs a tenth of the input price, or less on the newest models.
• Model mix. The share of calls that land on cost-efficient models such as Haiku or Nova Lite. Above 50% is green, under 30% is red. Not every task needs the largest model.
• Failed requests. Errors and throttles over all requests. Under 1% is green, over 5% is red. A client that times out and retries can pay twice.

The cache and mix thresholds are the playbook's. The failed-request ones are ours, because the playbook names that signal without numbers. The numbers come from your CloudWatch metrics over the last 14 days, across every region we scan. The executive digest carries the grades next to each account's Bedrock total.

One finding with dollars, on purpose

A prompt cache write costs 1.25 times the input price. If the next call reads it, the write pays for itself almost at once. If nothing reads it, you paid a premium for nothing. That happens when something in the prompt changes before the cache point on every call: a timestamp, a session ID, a user name.

So this is a finding: a model whose cache writes were almost never read back last month. The savings are the premium you paid, minus what the few reads saved. We assume the cheapest cache setting, so the number can only be too low, never too high.

That is the only Bedrock dollar we count as recoverable. We still do not invent savings for "switch to a smaller model". Whether a smaller model is good enough for your task is a quality question, and only your evaluation can answer it. The model mix grade tells you where to look.

Two more things show up on the card:

• Legacy models still called. AWS marks older models as Legacy before they reach end of life. If your account still calls one, you hear about it while there is time to test a replacement.
• Caching left on the table. A model with large prompts, at least 2,000 input tokens per call on average, and no caching at all. We show what the input bill could drop by, and keep it out of the savings total.

What it needs from you

Nothing new. The scan uses the same read-only role, the same Cost Explorer access, and CloudWatch metrics it already reads. There is no proxy in front of your models and no change to how you call them. That is also the limit: we can grade and point, but we cannot block a runaway agent. Budgets and gateways stay with you.

Next

Attribution comes next: which team and which application spent the money, and whether invocation logging is on in every region with spend. After that come idle provisioned throughput and Bedrock budgets. Same rules as everything else: read-only, deterministic, and no number we cannot defend.

If your Bedrock bill is at least $10 a month, the next scan shows the scorecard. 59+ detections, 30+ services, one weekly email.

Keep on chasing 🧡