What AWS Bedrock Actually Costs You

AWS Bedrock offers one API across many model families, so that an application can call Claude, Llama, or Nova through the same code and switch providers without a rewrite. In practice, teams that build on it inherit two separate cost centres: the ordinary difficulty of getting structured, reliable output from an LLM, and the ordinary difficulty of AWS’s SDK, IAM, and API Gateway stack. No library sits between the developer and either.

The trade being made

A team on Supabase or a direct OpenAI integration ships fast, and the cost shows up later, when small apps have multiplied and nobody owns the billing (a credit card silently declining on a side project nobody remembers provisioning is the common failure mode). Bedrock trades that velocity for IAM-native access control and a bill that lands in the same place as the rest of an organisation’s cloud spend, visible to whoever already monitors it (the same client pattern, boto3.client("bedrock-runtime", ...), repeats at module level across the codebase, a small sign of how uniform the integration surface is meant to be). That governance is a genuine benefit and one most teams would otherwise have to build themselves. It comes stacked on top of the flexible-inference tax, not instead of it.

Tax one: model capability is not actually abstracted

The premise of “same code, different models” is that the models agree on request shape, and several do not. Some do not accept a system role in converse() the way the API’s design implies. In one debugging session, a system prompt ended up stuffed into a second user-role message, because the model in use (meta.llama3-2-3b-instruct-v1:0) rejected the conventional shape and left no clear error explaining why. Documentation does not surface this kind of disagreement, so a model refusing, rambling, or ignoring half its instructions tends to cost an afternoon of working out whether the prompt is wrong or the request shape is wrong for that particular model. Multiplied across however many model families a product supports, “same code, different models” becomes same code, with the differences discovered one incident at a time.

Tax two: AWS’s plumbing becomes the application’s plumbing

A video generation endpoint returned base64-encoded video while an image endpoint on the same API worked correctly, and the cause had nothing to do with either model: the API Gateway’s Terraform configuration listed binary media types that did not include video/mp4, and a required header on the video endpoint had no default where the working image endpoint did. This is a generic API Gateway proxy-integration bug, one that would surface whichever service rendered the video. It landed on the team responsible for Bedrock because Bedrock is what introduced the need for a binary media type in the first place. Choosing a managed inference service does not remove AWS’s configuration surface; it adds inference, storage, and delivery to it, each with its own way to misconfigure.

Tax three: nothing manages the response

Calling OpenAI or Anthropic directly puts a developer inside an ecosystem built to turn “return a validated object” into a solved problem, through libraries like Instructor, function-calling response models, and provider-native structured output. Bedrock’s converse() returns raw text, and nothing in the boto3 client validates, retries, or extracts JSON from it. When the model’s text is not valid JSON (markdown fences, a refusal, an explanatory preamble), the code logs a warning and returns the raw string regardless, and nothing downstream checks for that. The failure surfaces three calls later as a Pydantic error, one that gives no indication the actual fault was an unparsed LLM response two layers up. Every LLM API has this problem in some form. Bedrock has it without the tooling that has grown up around it elsewhere, which means that tooling has to be rebuilt in-house.

When the trade is worth it

Bedrock can still be the right choice, particularly where data cannot leave a VPC, where a monitoring team needs LLM spend in the same dashboard as everything else, or where IAM roles are how an organisation actually enforces who can call what. Bedrock provides all of that without extra engineering. What it does not provide is a solved version of ordinary LLM integration, which still has to happen, with a smaller set of tools to help, on top of AWS’s own configuration surface. Budgeting for one tax and not the other is the mistake to avoid (neither seller’s pitch mentions the second one).


Questions about this? Get in touch.