AWS Bedrock Pricing Explained: Modes and Costs (2026)

Bedrock pricing is per token by default, with batch, provisioned and caching options that change the rate or the commitment.

AWS Bedrock pricing: every mode, price and limit

Amazon Bedrock is AWS's managed service for calling foundation models through one API, whether the calls come from your own code or from a workflow tool like Activepieces. Pick the wrong mode and you pay for it on every request.

Read the last column first: it tells you which cells I couldn't confirm on 2026-11-01.

Mode	Price basis	Inclusions	Limits	Verified status
On-demand	Per input and output token	Pay-as-you-go inference, no commitment	Account quotas throttle bursts	Basis verified; quota values unverified
Batch	Per token, at a reduced rate	Asynchronous jobs from files	Results are not immediate; model support varies	Basis verified; discount size unverified
Provisioned throughput	Hourly per model unit, with commitment terms	Reserved capacity	You pay while idle	Basis verified; terms unverified
Prompt caching	Discounted rate for cached input tokens	Reuse of repeated prompt prefixes	Only supported models; cache expires	Unverified
Cross-region inference	Billed per token like the model it routes	Traffic spread across Regions	Data may be processed outside your home Region	Unverified

Start with on-demand. It is the default and suits unpredictable traffic, such as a support chat widget.

If nobody is waiting on the work, batch is the mode: it trades speed for a lower rate. Tagging last month's tickets fits. Anything a customer is watching does not.

Reserve capacity and you pay for it whether or not you use it. That is Provisioned Throughput, and it makes sense only when traffic is steady and high. A quiet month still bills in full.

The unit here is the model unit: reserved capacity for one model, bought by the hour. Two model units cost twice as much as one, busy or idle.

Confirm tier and cross-region rates on the AWS pricing page before budgeting. They trade price against latency and data location, and I couldn't verify them on the check date.

A tier is a service level you choose for the same model. A faster tier answers sooner and costs more per token, and a slower one costs less.

Once you customize a model, training or storage charges land on top of inference, and a customized model usually needs its own serving cost.

What Bedrock costs at three realistic usage levels

Pricing the whole lifecycle starts with a sum you can do yourself: input tokens times the input rate, plus output tokens times the output rate, then add the services around it.

Rates change and differ by region, so take them from the current Bedrock pricing page and run the sums on your own ticket and document counts.

Workload	Model	Assumed monthly tokens	On-demand	Batch	Provisioned
Support chatbot	Haiku 5.5	Modest, set by ticket count	Fits uneven traffic	Wrong fit, customers are waiting	Idle capacity costs more than it saves
Document summarisation	Sonnet 5.5	Large but predictable	Works, at the full rate	Fits, nobody is waiting	Unneeded, the job is not time-critical
High-volume agent	Opus 5.5	Very large, steady, many calls per task	Costs climb with every step	Only for work that can wait	Worth pricing once load is steady

For a small team chatbot, on-demand is the sensible start. A slow Tuesday and a Monday-morning rush bill the same per token, so you never pay for capacity nobody used.

The cost to watch is the knowledge base behind the bot, not Haiku 5.5.

Nightly document summarisation in batch

Nobody reads these summaries at 2 a.m., so batch is the natural choice and the lower rate is the reward for waiting.

The cost of a wrong choice is the reverse of the chatbot's: running this on-demand pays the full rate for speed no one uses.

For a high-volume production workload, agents multiply tokens, because each step re-sends context and calls tools. Count calls per task, not tasks. Once load is steady, compare provisioned against on-demand using your own measured volume, and add guardrail and storage charges before deciding.

Hidden Bedrock costs beyond the per-token price

Whether or not a user ever sends a prompt, several line items still bill, and they're the ones most often missing from a budget.

• OpenSearch Serverless floor, $345 to $700 a month, so a small pilot can cost more than its model calls.
• Guardrails at $0.15 per 1,000 text units for content filters, charged on every input and output checked.
• Data Automation at $0.010 per page, so a 200-page contract costs $2.00 before a model reads it.
• Flows, CloudWatch logging and idle provisioned throughput, each on its own meter.

A text unit is up to 1,000 characters of text, and anything longer counts as several units. So a 2,500-character message is three units.

To see what $0.15 becomes in a month, say a chatbot handles 100,000 conversations, and each question and each answer is under 1,000 characters.

That is 200,000 checked texts, or 200,000 units, which is 200 blocks of 1,000 and comes to $30 for one content filter.

Bedrock Knowledge Bases vector store minimum costs

Before a knowledge base answers anything, it needs a vector store, and the store sets your idle cost. AWS Builder Center puts the classic OpenSearch floor at $350 a month and Aurora pgvector at $30.

S3 Vectors sits at $11.38, and OpenSearch NextGen at $0, making OpenSearch NextGen the cost-minimizing choice for vector storage.

Run a low-traffic assistant on classic OpenSearch and you pay about thirty times the S3 Vectors floor for the same quiet month.

Bedrock Guardrails and agent pricing overhead

At $0.15 per 1,000 text units, content filters and denied topics cost more than PII filters and grounding checks, which cost $0.10, so budget constraints will cause most teams to skip content filtering.

Run a low-traffic assistant on classic OpenSearch and you pay about thirty times the S3 Vectors floor for the same quiet month.

Switch on all four and you pay $0.50 per 1,000 units, over three times a single content filter.

Agents add a different cost: one user question can trigger several model calls, so you pay for every step of the reasoning, not for one answer.

Because output tokens usually cost more than input tokens, a verbose answer costs more than a long question. Cap answer length and retrieve fewer, better chunks before you blame the model's price.

Bedrock quotas and throttling limits that stall production

Usually it is not the budget that stops you but the quota:

• Each model has a ceiling on requests and tokens per minute in each region
• Past that ceiling, Bedrock rejects calls with a throttling error
• Provisioned capacity avoids that for the traffic it covers

Default requests and tokens per minute

Because defaults vary by model and region, and are often set for experimentation, not for a customer-facing launch, look yours up in Service Quotas rather than trusting a number from a blog post or a colleague's memory.

Watch the output burndown. For some models, each output token counts against your token quota as more than one token, so a long-answer feature uses quota faster than its raw token count suggests.

Ask well before launch, because quota increases must be requested and approval takes time.

1. Look up the model's tokens-per-minute and requests-per-minute quotas in Service Quotas for your region.
2. Estimate peak tokens per minute, applying the output burndown to your expected output length.
3. Request an increase for the model and region that need it, with that estimate attached.
4. Load test at the new limit, using realistic prompts and answer lengths, not short test strings.
5. Add retries with exponential backoff, so a brief spike slows users down instead of failing them.

Retry and fallback design for Bedrock throttling

A hundred clients that failed together will all retry together and throttle each other again, unless backoff adds randomness (jitter).

Cap the retries as well.

For sustained overload, fall back to a smaller model or a second region, and queue work that can wait. Test the fallback with a deliberate throttle before launch, because an untested fallback tends to fail in its own way.

If you build that retry, fallback and queue logic as a workflow around the Bedrock call, the platform running it has a meter of its own.

Activepieces charges 1 credit per flow run, so the retries, jitter and queue steps of the ten-step version add no credits over a two-step shortcut, while the smaller-model fallback is an AI step metered by model tier: 2 credits for a fast model, 10 for a smart one, 20 for a frontier one.

Zapier's per-task and Make's per-module billing, both on their pricing pages, add to the bill with every step you split out. MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.

Bedrock pricing versus OpenAI, Azure, and Google

On list price, Bedrock's Sonnet 5.5 ties for the cheapest input price of the four flagships and is cheapest on output. The rate card only starts the comparison, because the fallback you just tested will bill at a different rate than your primary model.

According to PlanPulse, the model pricing breaks down as follows:

• Bedrock's Sonnet 5.5 sits at $2 input and $10 output per million tokens
• OpenAI's gpt-6-astra sits at $10 input and $50 output per million tokens, five times Bedrock on both sides
• PlanPulse's earlier figures for Azure's gpt-5.5 were $5 input and $30 output per million tokens, an older model
• Vertex's Gemini 3.1 Pro sits at $2 input and $12 output per million tokens

Platform and model	Input per 1M tokens	Output per 1M tokens
Bedrock, Sonnet 5.5	$2	$10
OpenAI, gpt-6-astra	$10	$50
Vertex, Gemini 3.1 Pro	$2	$12

With Bedrock and Vertex this close, the surrounding services, not the token line, will decide which one is cheaper for you.

Before you send a latency-sensitive queue through a cheaper tier, check the rate for each one: faster tiers cost more per token and slower ones cost less, and cross-region routing can improve availability.

Direct APIs win when you want one vendor's newest model with no AWS services around it. Bedrock wins when the knowledge base, guardrails and storage already live in your AWS account, since one invoice and one permission model cost less to run than three.

Reducing Bedrock spend with early automation

Because the knowledge base, guardrails and storage share one invoice, Monday's work is making that invoice readable first, then shrinking what the model line charges for each request.

• Turn on cost allocation tags for every Bedrock workload, so each team's spend shows up under its own label.
• Set an AWS Budgets alert on those tags. A runaway loop, such as a retry bug calling the model all night, then reaches a person on Tuesday morning, not on the next invoice.
• Move non-urgent work to batch. Overnight summaries and backfills don't need an instant answer, and batch is priced meaningfully lower than on-demand, so you pay less for work nobody is waiting on. Never move anything a customer is staring at a screen for.
• Try a smaller model on each task. Test it against your real inputs, including the ugly ones: the rambling, angry email, not the tidy sample. A wrong answer sent to a customer costs more than any saving, so keep the larger model wherever the small one fails.
• Turn on prompt caching where a long system prompt or document repeats across calls. You stop paying full price to re-read the same text, which matters most for support bots that start every chat with the same instructions.
• Cap output length. Models will write as much as you allow, and output tokens usually cost more than input tokens, so an unbounded reply is an open tab.

What Activepieces does about this

Bedrock's bill is decided by the pipeline around the model, so the useful move is to put that pipeline in one place you can read.

In Activepieces you build it as a flow: the call, the retry, the queue for work that can wait, and the alert that reaches a named person when spend jumps.

Each of those is a step you can open and inspect, not a setting scattered across five AWS consoles.

The platform's own meter is simple enough to add to the estimate. A flow run costs 1 credit however many steps it has, and an AI step costs 2, 10 or 20 credits depending on whether the model is fast, smart or frontier.

The fallback to a smaller model therefore has a price you can read before launch.

The core is open source under the MIT licence, so you can self-host it in the same AWS account as your knowledge base and guardrails. MoneyGram, Moneypenny, Alan and FundingSocieties run it in production.

Frequently asked questions

Don't plan around a free tier for model inference. I couldn't confirm a standing free allowance for Bedrock model calls, so budget as if every token is billed.

If your company has AWS promotional credits, check on your account whether they cover Bedrock before you count on them.

Is Bedrock cheaper than calling model providers directly?

Not as a rule. For many models the per-token rates are close, so the saving, if any, comes from places other than the model line: one consolidated AWS invoice or committed-spend agreements.

Against that, you pay for the surrounding services you add, such as knowledge bases, guardrails and storage. Compare the full pipeline, not the token price.

How do I estimate my Bedrock bill before launching?

Estimate the whole pipeline, then test it with real traffic. Run a realistic sample of your busiest and messiest requests and read the usage from each service, not only the model. Then add a margin for retries and long conversations.

Below, survey results from Capgemini, WitnessAI and Mavvrik show how often teams skip this and get caught.

(chart)

Assume your first estimate is wrong: most organisations in those surveys overspent or misjudged their AI costs, so build in a review after the first month of real use.

Is Claude priced the same on Bedrock as on Anthropic's API?

Don't assume so. Check the Bedrock pricing page and Anthropic's own page for the specific model you plan to use, and compare the pricing modes as well as the base rates.

Features, discounts and available modes can differ between the two, and a rate that matches on paper can still cost you more once you add the services around it.

Can I set a hard spending cap on Bedrock?

Not with a single switch that I could confirm. What you can do is set AWS Budgets alerts, attach budget actions that restrict permissions when a threshold is crossed, and set service quotas that limit throughput.

Quotas limit volume, not dollars. Billing data arrives with a delay, so a runaway job can spend real money before any alert reaches a person; name who receives the alert and what they're allowed to shut off.

Related reading

• Amazon Bedrock Pricing (2026): Models and Token Costs
• Amazon SNS Pricing: Cost Per Message (2026 Guide)
• Amazon Lambda Pricing: Cost Breakdown for 2026

References

• PlanPulse
• AWS Builder Center
• AWS