Part 1 of this series built the operating model that controls Amazon Bedrock spend: attribution with AWS Identity and Access Management (IAM) principal tags and Cost and Usage Report 2.0, observability with model invocation logging, enforcement at three tiers, and a review cadence. That layer answers who spent it, and you can stop them. It can’t tell you whether the spend was well spent.

This post answers two questions that Part 1 deliberately left open. First: Why is this workflow expensive? The answer requires thinking in cost per task, not cost per token. Second: Is the agent better than the humans were? The answer requires baselines, controlled experiments, and a scorecard tied to decisions.

In this post, you learn a framework for calculating true model cost (including four hidden cost drivers that the pricing page doesn’t show), techniques for reducing cost per task through caching, routing, and output constraints, and a discipline for measuring agent ROI with human baselines, holdout experiments, and a five-dimension scorecard. This post is written for two audiences: the application and platform engineers who own the optimization levers, and the product owners and FinOps partners who need to justify agent spend to leadership.

Price per token invites quick comparison, but it doesn’t reflect what you actually pay. The published rate reflects the cost of a single token. Your bill reflects the cost of completing a task. A task is one complete unit of work your application asks a model to do: resolve one support email, extract fields from one invoice, or answer one user question.

Source link