AWS Bedrock Pricing, Explained

Part of a series on running AI workflows across model providers — this one is about the part of Bedrock that's easiest to misread from the headline numbers alone.

Bedrock's pricing page shows per-token rates for each model, and it's tempting to treat that as the whole story. It isn't. Bedrock actually offers several distinct pricing tiers for the same models, plus a handful of additional charges — Guardrails, Knowledge Bases, model customization — that don't show up until you're actually building something real. Understanding the shape of this before you commit to an architecture saves real money.

The four pricing tiers

Bedrock offers on-demand pricing under several tiers — commonly referred to as Standard, Flex, Priority, and Reserved — that trade cost against latency guarantees and commitment. Standard on-demand pricing is the default: pay per token, no commitment, available immediately. Provisioned throughput sits at the other end: you commit to a fixed capacity for a set period (typically one-month or six-month terms) in exchange for a lower effective per-token cost and, more importantly, guaranteed throughput that on-demand pricing doesn't promise during high-demand periods.

Batch inference: the discount most teams miss

For workloads that don't need a real-time response — nightly data processing, bulk document summarization, large-scale classification runs — Bedrock's batch inference pricing runs at roughly half the cost of the equivalent on-demand rate. The tradeoff is turnaround time: batch jobs aren't instant, so this only fits work that can tolerate being processed asynchronously rather than needing an answer inside a user-facing request.

The 50% batch discount is the single biggest lever most teams haven't pulled — and it costs nothing but a willingness to not need the answer instantly.

The charges that aren't in the per-token rate

Two features that sound like they'd be free add-ons actually carry their own line items:

Neither charge is large in isolation, but at meaningful volume they add a real, separate line to a cost model that a team planning purely off per-token model pricing will miss.

AgentCore has its own, separate pricing entirely

If you're layering AgentCore on top of Bedrock for full agent infrastructure — Runtime, Memory, Gateway, Identity, and the rest — that's billed independently from the underlying model calls, on a consumption basis: Runtime running as microVMs charges only for active CPU and memory with no charge for idle time, while Runtime running as dedicated instances bills the underlying EC2 cost plus a management fee. Budgeting for an AgentCore-based agent means adding this on top of, not instead of, the model-call costs it's making.

Working through a decision, not just a number

The practical question isn't "what's the cheapest option" in isolation — it's matching the pricing tier to the actual shape of the workload. A customer-facing chat feature needs Standard or Provisioned Throughput, since users are waiting on the response in real time. An overnight report-generation job that processes yesterday's data is a textbook Batch inference candidate. A workload with a known, steady volume that's currently paying more under Standard on-demand than a Provisioned Throughput commitment would cost is leaving money on the table by not switching.

Three honest questions — is this real-time, is the volume predictable, can it wait — point to a specific tier rather than a guess.

A real use case: a batch job that had been running at full price for months

A company running a nightly job that summarized the previous day's support tickets for a morning report had been calling Bedrock's Standard on-demand pricing the entire time — because the job was built quickly, under time pressure, without anyone specifically evaluating pricing tiers. The job ran overnight, had no user waiting on an immediate response, and processed a predictable, bounded batch of tickets — a close-to-perfect fit for Batch inference. Switching cut the job's model cost roughly in half with zero change to the summaries it produced, purely because the pricing tier finally matched the actual shape of the workload.

Frequently asked questions

Is Provisioned Throughput worth it for low-volume workloads?

Generally no — the commitment period means you're paying for capacity whether you use it or not. It only pays off once volume is high and predictable enough that the discount outweighs the fixed commitment.

Does Batch inference work for real-time chat features?

No — batch jobs aren't processed instantly, so they only fit work that can tolerate asynchronous turnaround, not a user waiting on a live response.

Are Guardrails and Knowledge Bases charges avoidable?

Only by not using those features. If you need content filtering or managed RAG, budget for them as separate line items rather than assuming they're bundled into model pricing.

Does switching pricing tiers require changing my application code?

Generally no for Standard versus Batch — it's primarily a configuration and workflow-timing decision, not an application rewrite.

The Bottom Line

Next in this series: Bedrock's Guardrails feature versus the kind of workflow-level controls DNotifier gives you — and why the honest answer is "use both," not "pick one."

Read part seven: Bedrock Guardrails vs. DNotifier's Approach. Explore dnotifier.com.