The Complete Guide to Amazon Bedrock Errors in 2026

Introduction

Amazon Bedrock is the largest LLM-as-a-service catalog on any cloud in 2026 — 62 foundation models across 42 AWS regions from 13 providers, spanning Anthropic Claude, Meta Llama, Mistral, Amazon Nova, Cohere Command, Stability AI, TwelveLabs, and more. One API, one billing relationship, IAM-based auth, cross-region routing built in. The value proposition is real. So is the complexity: on-demand vs Batch vs Provisioned Throughput vs Reserved Tier, in-region vs geo vs global inference profiles, Knowledge Bases, Agents, Guardrails, model evaluation, and fine-tuning are all separate cost lines. Teams routinely spend 1.5-2x their initial Bedrock budget for reasons the pricing page doesn't mention.

This guide is the definitive reference for Bedrock as it exists today. It covers the models currently live, the pricing after 2026's expansions, the IAM patterns, the difference between InvokeModel and Converse, the cross-region economics, and every provider-specific quirk that separates a working integration from a shipping one.

Who this guide is for

The guide assumes you have:

• An AWS account with Bedrock access enabled
• Made real Bedrock API calls, whether via boto3, LangChain, or the AWS console
• Hit at least one AccessDeniedException or ThrottlingException that sent you searching

If that's you, read this end-to-end once to build a full map of the API surface; return to specific chapters when you hit a related error. Each chapter links to the specific error-fix pages that answer narrower questions with tested code.

What Bedrock is (and isn't)

Bedrock is a proxy layer. AWS runs infrastructure that fronts models from Anthropic, Meta, Mistral, Cohere, Stability AI, AI21 Labs, TwelveLabs, and Amazon (Titan, Nova). You get one AWS billing relationship, IAM-based auth, VPC endpoint support, CloudTrail logging, and integration with the rest of AWS. What you don't get: the newest features from each provider on day zero. New Claude models typically arrive on Bedrock 1-4 weeks after their direct release; new Anthropic betas (MCP connector, Managed Agents) often don't arrive at all.

The three things that matter most in 2026

1. The catalog has stratified into "on-demand" and "provisioned" pricing. On-demand covers most use cases with pay-per-token. Batch inference is 50% off with a 24-hour SLA. Provisioned Throughput at $21-$50/hour/unit (1-6 month commit) is the only option for custom models and high-volume steady-state workloads. Reserved Tier adds 1-month and 3-month commit discounts for stable production.

2. Cross-region inference has nuanced pricing. The classic "no surcharge, source region pricing applies" rule still holds for some profiles. But geo and in-region cross-region inference profiles carry a ~10% uplift on certain models (Claude Sonnet 4.6 at $3.30/$16.50 vs $3.00/$15.00 base). Which profile you're on affects your bill directly. Chapter 7 walks the four profile types and their pricing.

3. The hidden costs are the real story. Knowledge Base with OpenSearch Serverless has a $350/month minimum. Bedrock Agents amplify tokens 5-10x per user query. CloudWatch logging captures everything by default. Cross-region left enabled after testing. Guardrails runtime. Model evaluation. These aren't hidden fees — they're separately-billed features you probably didn't realize you enabled. Chapter 10 has the full breakdown.

What's not in this guide

• Prompt engineering tutorials — we assume you know what works for your use case
• AWS account setup basics — we assume Bedrock is enabled and you have IAM permissions
• Deep coverage of every model's individual API — this is a Bedrock guide, model-specific quirks appear where they affect Bedrock behavior. For Claude specifics, see the Claude API pillar.

API architecture at a glance

Bedrock has two runtime endpoints — bedrock-runtime for inference and bedrock for control-plane operations. Two synchronous API shapes — InvokeModel (provider-native) and Converse (AWS-normalized). Plus streaming variants, Batch, Agents, Knowledge Bases, and Guardrails as separate surfaces. This chapter maps the whole thing so later chapters can reference specific pieces without re-explaining them.

Two services, many endpoints

The inference endpoint map

InvokeModel vs Converse

The most important architecture choice in Bedrock is between the two inference APIs:

• InvokeModel — you send the request body in the model provider's native format (Anthropic's Messages format for Claude, Meta's chat format for Llama, Amazon's format for Nova). You get back the response in the provider's native format. Full provider feature access, provider-specific parsing.
• Converse — you send an AWS-normalized request shape. AWS translates to the provider's format, calls the model, translates the response back. Same code works across every provider that supports Converse. Feature gaps: some provider-specific features aren't in Converse (Claude's newest betas, some Nova specialty modes).

Rule of thumb: use Converse for new development where portability matters, InvokeModel when you need a provider-specific feature Converse doesn't expose. Chapter 6 covers the choice in depth.

SDKs

Request lifecycle

1. SDK serialization — boto3 objects turn into a signed HTTP request
2. SigV4 signing — AWS credentials sign the request
3. IAM authorization — bedrock:InvokeModel or bedrock:Converse action checked
4. Model access check — is this model enabled in your account for this region?
5. Cross-region routing — if you're calling an inference profile, request may route to another region
6. Guardrail pre-check (if configured) — input evaluated
7. Model inference — the model generates the response
8. Guardrail post-check (if configured) — output evaluated
9. Response streaming or buffering — response returned
10. Usage + billing — tokens counted, cross-region surcharge applied if applicable

Errors fire at any stage. AccessDeniedException fires at step 3 or 4. ThrottlingException fires at step 5 or 7. ValidationException fires at step 1 (SDK-side) or step 7 (model rejects). Understanding which stage failed tells you where to look for the fix.

The core object model

Two object worlds — the InvokeModel body (provider-specific) and the Converse shape (AWS-normalized).

Converse objects:

• Message — role (user or assistant) and content (array of typed blocks)
• ContentBlock — text, image, document, toolUse, toolResult, guardContent (for guardrail wrapping)
• InferenceConfig — maxTokens, temperature, topP, stopSequences
• ToolConfig — tools (function definitions with JSON Schema), toolChoice
• Usage — inputTokens, outputTokens, totalTokens, cacheReadInputTokens, cacheWriteInputTokens

InvokeModel: the body is whatever the provider expects — anthropic_version + messages + max_tokens for Claude, provider-specific shapes for others.

The 2026 Bedrock model catalog

Bedrock's catalog spans 13 providers and 62 LLMs across 42 AWS regions. This chapter covers the models you'll actually use, current pricing (us-east-1, on-demand), and the migration hazards from models that moved to Legacy status in 2026.

Anthropic Claude on Bedrock

us-east-1 on-demand rates verified August 19, 2026. Bedrock Claude pricing matches Anthropic direct API pricing in standard regions. Cross-region inference profiles may add ~10% on certain models — see Chapter 7.

Amazon Nova family

Nova is Amazon's own model family, priced aggressively low. Nova Micro at $0.035/$0.14 is the cheapest text model in the entire catalog — cheaper per token than any other tier-1 provider option. For classification, extraction, and simple Q&A at massive scale, Nova Micro often beats the alternatives on pure cost. Cache reads on Nova are billed at 75% off input rate (a slightly different discount than the ~90% that Claude gets — see Nova cache economics).

Meta Llama on Bedrock

Other providers

Model selection: which one for what

Rough routing heuristic for a typical mixed workload:

• Nova Micro ($0.035/$0.14) — highest-volume classification, extraction, formatting. Cheapest usable text model on the platform. 428x cheaper than Opus per input token.
• Nova Lite ($0.06/$0.24) — multimodal at very low cost. Image-based extraction workloads.
• Claude Haiku 4.5 ($1/$5) — when you need Claude quality at low cost. Fast, capable, MCP-adjacent.
• Nova Pro ($0.80/$3.20) — general-purpose midtier. Multimodal, 300K context.
• Claude Sonnet 5 or 4.6 ($3/$15) — production workloads needing Claude's reasoning depth.
• Claude Opus 5 or 4.8 ($5/$25) — hardest reasoning, complex agentic loops, safety-critical.
• Mistral Small ($0.20/$0.60) — European data residency, multilingual work at low cost.

A team processing 100M input tokens/month pays roughly $3.50 on Nova Micro vs $500 on Claude Opus — a 143x spread. Model routing is not optional at scale on Bedrock; it's the difference between a $5K bill and a $75K bill.

What moved to Legacy in 2026

• Claude Opus 4, Claude Sonnet 4 (both 20250514) — Legacy as of Q1 2026 when Opus 4.5/4.6/4.7 shipped
• Claude 3.5 Haiku, Claude 3 Haiku — Legacy across all regions
• Nova Premier — Legacy following Nova 2 preview launch

Legacy models still accept inference calls today but are on borrowed time — no new model IDs will appear in Legacy status, no bug fixes, no new region rollouts. Plan migrations off legacy models as part of any code touch to those endpoints. See Legacy model migration.

IAM auth, rate limits & quotas

Bedrock uses AWS IAM for auth — no separate API keys, no bearer tokens. Access is controlled by IAM policies attached to users, roles, or service principals, combined with model-level access grants you enable per region in the Bedrock console. Rate limits are enforced as service quotas per model per region, adjustable via AWS quota-increase requests.

Two-layer access model

Every Bedrock call requires both:

1. IAM permission — the caller (user, role, or service) has an IAM policy allowing the action (bedrock:InvokeModel, bedrock:Converse, etc.) on the target resource
2. Model access — the model has been enabled in your AWS account for the region you're calling

Miss either layer and you get an AccessDeniedException with a message that doesn't always distinguish which layer failed. Debug by first verifying model access in the console (Amazon Bedrock → Model access → Manage model access) and then verifying the IAM policy attached to your role.

Minimum IAM policy for Bedrock inference

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockInvokeAndConverse",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:Converse",
        "bedrock:ConverseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-4-8-v1:0",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6-v1:0",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-lite-v1:0",
        "arn:aws:bedrock:us-east-1:*:inference-profile/us.anthropic.claude-opus-4-8-v1:0"
      ]
    }
  ]
}

Note the inference profile ARN in the resource list — cross-region inference profiles are separate ARNs from the foundation-model ARN. Your policy must allow the profile if you're using cross-region routing. See bedrock:InvokeModel permission denied.

Model access grants (the console step people forget)

Even with perfect IAM, a model that hasn't been enabled in your account will return AccessDeniedException with a message like:

An error occurred (AccessDeniedException) when calling the InvokeModel
operation: You don't have access to the model with the specified model ID.

Fix: go to the Bedrock console → Model access → Manage model access, request access to the specific model, wait for approval (immediate for most models, a few hours for some Anthropic models that require use-case review). See model access not granted.

Rate limits & service quotas

Bedrock rate limits are enforced as AWS service quotas — per model, per region, per account. Two dimensions:

• Requests per minute (RPM) — how many invoke calls you can make
• Tokens per minute (TPM) — total input + output tokens processed

Default quotas vary widely by model. Claude Opus 4.8 typically defaults around 20 RPM / 200K TPM in us-east-1; Sonnet 4.6 around 50 RPM / 400K TPM; Haiku 4.5 around 500 RPM / 2M TPM; Nova Micro much higher. Adjust via the AWS Service Quotas console — request increases for specific model + region combinations. See service quota request.

Common auth & quota errors

• AccessDeniedException — IAM missing OR model access not granted OR wrong resource ARN. See InvokeModel denied, Converse denied
• ValidationException — request shape wrong for the model, or invalid parameters
• ThrottlingException — RPM or TPM quota hit. Implement adaptive retry. See throttling retry strategy
• ServiceQuotaExceededException — hard quota cap. Request quota increase via Service Quotas console
• ServiceUnavailableException — Bedrock-side capacity issue. Retry with backoff. See service unavailable fallback
• ModelNotReadyException — model provisioning still in progress (Provisioned Throughput)
• ModelTimeoutException — model took too long; often happens with very long-context requests on constrained models

STS assume-role for cross-account access

Many enterprise setups use AWS Organizations with Bedrock enabled in a shared services account. Consuming accounts assume a role into the shared account for Bedrock access. Common failure: STS credentials expire mid-workload, boto3 doesn't refresh, ThrottlingException on token refresh masks the actual issue. Use boto3's default credential provider chain and let it handle refresh — don't cache STS credentials manually. See STS credential errors.

Every Bedrock error category

Bedrock errors fall into ten categories, mixing AWS-service errors (IAM, quotas, region availability) with model-side errors (context length, validation, safety). This chapter maps each category and links to the specific error-fix pages that walk through each with tested code.

1. IAM & permission errors

Fires at: AWS auth stage, before model call.
Common causes: Missing bedrock:InvokeModel or bedrock:Converse permission; wrong resource ARN; missing inference profile permission; model access not granted in Bedrock console.

IAM errors have distinct causes with the same AccessDeniedException name. First check: is the model access granted in the console? Second check: does the IAM policy include both the foundation-model ARN and any inference-profile ARN you're using? Third check: are you calling from the region the policy allows?

Related pages: InvokeModel denied · Converse denied · Model access not granted

2. Model availability errors

Fires at: Model routing stage.
Common causes: Model not available in your region; model requires cross-region inference profile; model moved to Legacy; using a preview model without preview access.

Bedrock's 42-region catalog is not evenly distributed. Many newer models are only available in us-east-1, us-west-2, and eu-central-1 initially, expanding to other regions over weeks or months. Some models (all newer Claude releases, for example) require you to call an inference profile instead of the foundation model directly — the profile handles cross-region routing to wherever capacity exists.

Related pages: Model not enabled in region · Legacy migration · Cross-region profile required

3. Request validation errors

Fires at: Request validation, before inference.
Common causes: Wrong body format for provider (InvokeModel), missing required field, invalid parameter for model, exceeded per-model max_tokens ceiling.

On InvokeModel, the body must match the provider's exact expected shape — Anthropic's Messages format for Claude, Meta's format for Llama, Amazon's format for Nova. Each has strict requirements. Wrong field names, missing anthropic_version on Claude, malformed content arrays all throw ValidationException. On Converse, the AWS-normalized shape catches many of these — but Converse itself has schema validation that fires similarly.

Related pages: anthropic_version required · Provider body format

4. Throttling & quota errors

Fires at: Rate limiting layer, before inference.
Common causes: RPM or TPM quota hit for the specific model + region + account; provisioned throughput saturation; bursts without smoothing.

ThrottlingException is the classic Bedrock error. Two fixes: (1) implement exponential backoff with jitter (boto3's adaptive retry mode does this well), (2) request quota increases through the Service Quotas console. For high-volume steady workloads, provisioned throughput removes the RPM/TPM concern in exchange for hourly commit.

Related pages: ThrottlingException retry · Quota increase request

5. Cross-region inference errors

Fires at: Cross-region routing.
Common causes: Inference profile ARN missing from IAM; destination region doesn't have model access; profile type (global/geo/in-region) doesn't match your caller region.

Cross-region profiles come in three flavors: global (routes across continents), geo (routes within a geographic area — us., eu., apac.), and in-region (routes only within your calling region for capacity load-balancing). Each has different ARN patterns and different pricing. Chapter 7 covers the whole model.

Related pages: Profile required · Profile types

6. Provisioned Throughput errors

Fires at: Provisioning API or during invocation of a provisioned model.
Common causes: Insufficient model units quota; wrong commitment period; provisioning still in progress; using a model that doesn't support PT.

Provisioned Throughput requires you to purchase model units for a 1-month or 6-month commit. Model units are a Bedrock-internal capacity metric — 1 unit typically supports some RPM/TPM baseline that varies by model. Getting quota is a two-step process: request PT quota for the model, then create the PT resource. See PT model unit quota.

7. Knowledge Base & Agent errors

Fires at: KB retrieval or Agent orchestration.
Common causes: OpenSearch Serverless not provisioned; embedding model not enabled; agent lambda missing permissions; agent tool spec malformed.

Bedrock Knowledge Bases depend on OpenSearch Serverless (or another supported vector store) — the KB itself is basically a wrapper over your vector store. If OpenSearch Serverless capacity units aren't provisioned, KB queries fail. Bedrock Agents add token amplification (5-10x per user query for tool orchestration overhead) that catches teams by surprise. Chapter 9 covers both.

Related pages: OpenSearch $350 minimum · Agent token amplification · Guardrails blocked

8. Streaming errors

Fires at: Stream serialization, network transport, client-side parsing.
Common causes: InvokeModelWithResponseStream event chunk parsing (provider-specific); ConverseStream event misordering; connection drop; missing usage in final chunk.

Bedrock streams events wrapped in AWS's SDK event stream format (SSE-like but binary framed). boto3 handles the framing; your code processes the parsed events. On Converse, events are normalized (messageStart, contentBlockStart, contentBlockDelta, contentBlockStop, messageStop, metadata). On InvokeModel, events are the provider's native shape wrapped in an AWS chunk envelope.

Related pages: ConverseStream events

9. Guardrails errors

Fires at: Pre-inference or post-inference guardrail evaluation.
Common causes: Input blocked by content policy; output blocked; guardrail configuration missing required fields; incorrect masking behavior.

Guardrails run before and/or after inference. When they block, the response contains stopReason: "guardrail_intervened" and details of what triggered the block. Handle this as a distinct code path — never auto-retry, log for pattern analysis, show the user an appropriate message. Guardrail evaluation itself has a runtime cost billed separately.

Related pages: Guardrails blocked

10. Batch inference errors

Fires at: Batch job creation, S3 input processing, or during background processing.
Common causes: S3 input format wrong; IAM missing S3 permissions for batch role; batch expired at 24h; provider doesn't support batch for this model.

Batch inference uses S3 for input and output — you provide the input JSONL in an S3 bucket, batch role reads it, results write to another S3 bucket. Not every model+provider combination supports batch — check the supported providers list. See batch provider support.

InvokeModel vs Converse API

The most important architecture choice in Bedrock is between the two inference APIs. InvokeModel gives you provider-native access with full feature coverage. Converse gives you AWS-normalized access with cross-provider portability at the cost of some feature gaps. This chapter walks the choice, the code differences, and when to pick each.

InvokeModel — provider-native

With InvokeModel, you send the request body in the model provider's exact expected format:

# InvokeModel for Claude
import json, boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

body = json.dumps({
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello"}],
    "system": "You are a helpful assistant.",
})

response = client.invoke_model(
    modelId="anthropic.claude-opus-4-8-v1:0",
    body=body,
    contentType="application/json",
    accept="application/json",
)

result = json.loads(response["body"].read())
text = result["content"][0]["text"]

Notice anthropic_version — a Bedrock-specific header field required in every Claude InvokeModel body. Miss it and you get ValidationException. See anthropic_version required.

For Llama on Bedrock, the body shape is entirely different:

# InvokeModel for Llama
body = json.dumps({
    "prompt": "<|begin_of_text|><|start_header_id|>user<|end_header_id|>\n\nHello<|eot_id|>",
    "max_gen_len": 512,
    "temperature": 0.7,
})

response = client.invoke_model(
    modelId="meta.llama3-3-70b-v1:0",
    body=body,
)

Every provider on Bedrock has its own body shape. To handle multiple providers in one codebase with InvokeModel, you write a per-provider adapter for each — or you use Converse.

Converse — AWS-normalized

Converse presents one shape across every provider that supports it:

response = client.converse(
    modelId="anthropic.claude-opus-4-8-v1:0",
    messages=[
        {"role": "user", "content": [{"text": "Hello"}]},
    ],
    system=[{"text": "You are a helpful assistant."}],
    inferenceConfig={
        "maxTokens": 1024,
        "temperature": 0.7,
    },
)

text = response["output"]["message"]["content"][0]["text"]

# Same code works for Llama, Nova, Mistral, Cohere...
response = client.converse(
    modelId="meta.llama3-3-70b-v1:0",
    messages=[{"role": "user", "content": [{"text": "Hello"}]}],
    system=[{"text": "You are a helpful assistant."}],
    inferenceConfig={"maxTokens": 1024, "temperature": 0.7},
)

Same request shape, same response shape, different modelId. The AWS SDK does the translation to and from each provider's native format under the hood.

What Converse doesn't expose

Converse normalizes to a common denominator, which means some provider-specific features aren't accessible through Converse. Notable gaps for Claude on Bedrock:

• Anthropic-specific beta headers — new Anthropic beta features (task_budgets, compaction, context_management) often require the anthropic_beta field in the InvokeModel body
• Some newer Claude parameters — Opus 4.7's output_config.effort parameter has landed in Converse (as additionalModelRequestFields.output_config), but there's usually a lag between direct Anthropic API landing and Converse support
• MCP connector — not supported on Bedrock at all, InvokeModel or Converse
• Managed Agents — Anthropic API only

Converse does support: standard messages, system prompts, tool use (function calling), streaming, guardrails wrapping, most inference config. For most workloads, Converse is sufficient. See when to use which.

additionalModelRequestFields — the escape hatch

Converse has an escape hatch: additionalModelRequestFields passes provider-specific parameters through to the underlying model without Converse-side validation:

response = client.converse(
    modelId="anthropic.claude-opus-4-8-v1:0",
    messages=[{"role": "user", "content": [{"text": "Solve this hard problem"}]}],
    inferenceConfig={"maxTokens": 8000},
    additionalModelRequestFields={
        "thinking": {"type": "adaptive"},
        "output_config": {"effort": "xhigh"},
    },
    additionalModelResponseFieldPaths=["/thinking"],   # so it comes back in response
)

Use this pattern to access Claude-specific features from Converse. Same escape hatch works for other providers.

Response shape comparison

InvokeModel returns the provider's native response wrapped in an AWS envelope. You parse it as you would from the direct provider:

result = json.loads(response["body"].read())
# Claude native shape: result["content"] = [{"type": "text", "text": "..."}]
# Llama native shape: result["generation"] = "..."
# Nova native shape: result["output"]["message"]["content"] = [{"text": "..."}]

Converse returns a normalized shape regardless of provider:

text = response["output"]["message"]["content"][0]["text"]
usage = response["usage"]   # {"inputTokens": ..., "outputTokens": ..., "totalTokens": ...}
stop_reason = response["stopReason"]   # "end_turn", "tool_use", "guardrail_intervened", ...

Decision matrix

Cross-region inference profiles

Cross-region inference is Bedrock's mechanism for routing requests across AWS regions when your primary region is at capacity. Three profile types, each with different pricing and different use cases. Understanding which profile you're on is the difference between predictable billing and surprise 10% uplifts on your entire Bedrock spend.

The three profile types

The pricing story is nuanced. AWS documentation historically said "no surcharge, source region pricing applies" — that's still broadly true for Global profiles on many models. But specific model + profile combinations do carry a 10% uplift, especially in the Anthropic Claude line for geo and in-region profiles. Always verify against the Bedrock pricing page for your specific model and profile combination.

When to use a profile at all

Cross-region profiles exist to solve two problems:

1. Regional capacity constraints — your primary region throttles you at burst, another region has headroom
2. New model access — some newer models are only available through profiles (they don't have a direct foundation-model ARN in every region)

If your workload runs steadily in one region without throttling and your model has direct availability there, you don't need a profile. Enabling one adds cost with no benefit. Chapter 10 covers this as a common cost anti-pattern.

Configuring a profile

# Direct foundation model (no cross-region)
response = client.converse(
    modelId="anthropic.claude-opus-4-8-v1:0",
    messages=[...],
)

# US geo profile (routes across US regions)
response = client.converse(
    modelId="us.anthropic.claude-opus-4-8-v1:0",
    messages=[...],
)

# Global profile (routes worldwide)
response = client.converse(
    modelId="global.anthropic.claude-opus-4-8-v1:0",
    messages=[...],
)

Note the prefix — us., eu., apac., global.. That's the entire configuration; there's no separate profile object to create. Your IAM policy must allow the inference-profile ARN (not just the foundation-model ARN).

What models require a profile in 2026

Following the trend that started in 2024, most newer Bedrock models on Anthropic and some Nova/Llama variants require inference profiles rather than direct foundation-model IDs. As of August 2026:

• Claude Opus 5, Sonnet 5, Fable 5 — profile-only in many regions
• Claude Opus 4.8, 4.7 — profile-preferred (direct available in some regions)
• Nova 2 preview — profile-only
• Llama 4 Maverick/Scout — profile-preferred

Trying to call these with the direct foundation-model ARN returns ValidationException with a message pointing you to the correct profile ID. See profile required error.

Cost impact walkthrough

Example: a workload processing 50M input + 50M output tokens/month on Claude Sonnet 4.6:

The delta looks small in percentage terms, huge in absolute dollars at scale. A team paying $22K/month for Claude on Bedrock with cross-region enabled unnecessarily is leaving $2K/month on the table. See the 10% surcharge explained.

Common cross-region mistakes

• Enabling cross-region for testing, then leaving it enabled in production without benefit
• Using geo profile when in-region would suffice — geo is more expensive
• Not including inference-profile ARN in IAM policy → AccessDeniedException
• Not enabling the model in the destination region → profile falls back to primary region only
• Assuming pricing is uniform across profiles — verify per model

Provisioned Throughput & Reserved Tier

On-demand inference is the right pricing model for most workloads. High-volume steady-state workloads and custom-tuned models require different economics: Provisioned Throughput (hourly-billed reserved capacity) or Reserved Tier (upfront commitment discounts). This chapter covers when each makes sense, the commit math, and the specific errors that surface only on provisioned resources.

On-demand vs Provisioned Throughput vs Reserved Tier

Provisioned Throughput math

PT charges by model unit — a Bedrock-internal capacity metric. One model unit for Claude Opus provides roughly a fixed TPM/RPM baseline that varies by model. Hourly rates range from about $21/hr/unit (Meta Llama) to about $50/hr/unit (Claude Opus and equivalents), with 6-month commits discounted vs 1-month.

Break-even example for Claude Sonnet 4.6:

• 1 model unit at $40/hr × 24 × 30 = $28,800/month
• 1 model unit typically supports ~50 RPM sustained, ~5M tokens/hour
• At full utilization: 3.6B tokens/month for $28,800 = $0.008 blended per 1K tokens
• Compare to on-demand: 3.6B tokens at $3/$15 blended average = ~$32K-$54K depending on input/output mix

PT wins only at high sustained utilization. Underutilized PT is a very expensive way to pay for capacity you're not using. Rule of thumb: PT breaks even around 60-70% sustained utilization vs on-demand for the same model.

When PT is the only option

PT is required for:

• Custom-tuned models (fine-tuned on your data)
• Models with hardware-locked capacity in a specific region
• Enterprise contracts requiring guaranteed throughput SLA

If you fine-tune a model on Bedrock, you have no choice but to serve it via PT. Budget for it up front — a fine-tuning experiment "just to see what it does" that ends with a fine-tuned model in production commits you to $28K/month PT minimum for a Sonnet-tier model.

Reserved Tier

Reserved Tier is a newer 2026 offering — commit to a monthly on-demand spend, get a per-token discount. Simpler math than PT: you keep on-demand's flexibility, get 10-30% off list rates in exchange for commit. Available for 1-month and 3-month terms on many popular models. See Reserved Tier savings math.

Creating provisioned throughput

client = boto3.client("bedrock", region_name="us-east-1")

# 1. Request PT quota if needed (via Service Quotas console — not API)

# 2. Create PT resource
pt = client.create_provisioned_model_throughput(
    provisionedModelName="my-claude-sonnet-pt",
    modelId="anthropic.claude-sonnet-4-6-v1:0",
    modelUnits=1,
    commitmentDuration="OneMonth",   # or "SixMonths"
)

# 3. Wait for provisioning
pt_arn = pt["provisionedModelArn"]
# ... poll DescribeProvisionedModelThroughput until status = "InService"

# 4. Invoke against the PT ARN
runtime = boto3.client("bedrock-runtime", region_name="us-east-1")
response = runtime.converse(
    modelId=pt_arn,   # ← use PT ARN, not foundation-model ARN
    messages=[...],
)

Provisioning takes 15 minutes to a few hours depending on model and current AWS capacity. Once provisioned, hourly billing starts immediately. See 1-month vs 6-month commit.

PT errors to watch for

• ServiceQuotaExceededException — model unit quota not high enough. Request via Service Quotas console.
• ModelNotReadyException — PT still provisioning. Wait and retry.
• ThrottlingException on PT — you're exceeding your provisioned capacity. Add model units or accept the throttling.
• Under-utilization billing surprise — you pay hourly regardless of use. Monitor utilization in CloudWatch.

Knowledge Bases, Agents & Guardrails

Beyond inference, Bedrock ships three high-level abstractions: Knowledge Bases for RAG, Agents for multi-step tool orchestration, and Guardrails for content safety. Each is powerful, each has a distinct cost profile, and each catches teams by surprise with hidden costs that don't appear on the Bedrock model pricing page.

Knowledge Bases — Bedrock's RAG layer

A Bedrock Knowledge Base wraps a vector store (OpenSearch Serverless by default, or Aurora, Pinecone, Redis, MongoDB Atlas) with document ingestion, embedding generation, and retrieval APIs. Query with Retrieve (returns chunks) or RetrieveAndGenerate (retrieves + calls a model with the results).

agent_runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

# Retrieve chunks only
result = agent_runtime.retrieve(
    knowledgeBaseId="KB123ABC",
    retrievalQuery={"text": "What is our refund policy?"},
    retrievalConfiguration={
        "vectorSearchConfiguration": {"numberOfResults": 5},
    },
)

for chunk in result["retrievalResults"]:
    print(chunk["content"]["text"], chunk["score"], chunk["location"])

# Retrieve + generate in one call
result = agent_runtime.retrieve_and_generate(
    input={"text": "What is our refund policy?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB123ABC",
            "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6-v1:0",
        },
    },
)

print(result["output"]["text"])

The $350/month OpenSearch minimum

OpenSearch Serverless (the default KB vector store) has a minimum billing baseline of roughly 2 Search OCUs + 2 Indexing OCUs even at zero query volume. Each OCU is billed hourly at about $0.24/hr. Baseline math:

• 4 OCUs × $0.24/hr × 24 × 30 ≈ $691/month baseline per collection
• Bedrock docs sometimes cite a "$350 minimum" — the exact number varies by region and OCU pricing
• This is charged even if your KB has zero queries during the month

If you're evaluating Bedrock KB for a low-volume use case, the OpenSearch baseline dominates cost. Bring-your-own vector store (Pinecone, MongoDB Atlas) can eliminate this if you already have vector infrastructure. See the OpenSearch minimum.

Bedrock Agents — token amplification

Agents orchestrate multi-step tool workflows: user asks a question → agent decides to call one or more tools → tool results flow back → agent synthesizes an answer. AWS handles the orchestration loop, action group Lambda invocation, and multi-turn state.

The catch: token amplification. A single user query typically consumes 5-10x the tokens you'd expect from a straight LLM call. Reasons:

• Agent-generated system prompts describing tool schemas add hundreds of tokens per turn
• Each tool call/result round-trip re-includes conversation history
• Agent's internal "thinking" about tool selection is billed as output
• Response formatting for the user is a separate model call after the tool loop completes

A user query that generates a 200-token final answer might cost 3,000-8,000 tokens end-to-end through the Agent. Budget accordingly. Instrument Agent invocations with CloudWatch to see actual token consumption per query — not per user question. See Agent token amplification.

Guardrails — content safety with runtime cost

Guardrails filter model input and output for policy violations: harmful content, PII, competitor mentions, off-topic queries. Configure a Guardrail policy in the Bedrock console; reference it by ARN on your inference call.

response = client.converse(
    modelId="anthropic.claude-opus-4-8-v1:0",
    messages=[{"role": "user", "content": [{"text": "user query"}]}],
    guardrailConfig={
        "guardrailIdentifier": "abc123def456",
        "guardrailVersion": "1",
    },
)

if response["stopReason"] == "guardrail_intervened":
    # Handle blocked response
    for output in response.get("output", {}).get("message", {}).get("content", []):
        if "guardContent" in output:
            print("Blocked:", output["guardContent"])

Guardrail evaluation is billed separately from inference — roughly $0.15 per 1,000 text units evaluated. For a 5,000-request-per-day workload with input + output evaluation, that adds up. See guardrails blocked handling.

Pricing & the hidden costs of Bedrock

The Bedrock pricing page shows clean per-token numbers. The invoice at the end of the month rarely matches. Teams routinely spend 1.5-2x their initial Bedrock estimate for reasons that aren't hidden fees — they're separately-billed features engineers didn't realize they enabled. This chapter walks the visible pricing, the hidden costs, and the levers that actually move production bills.

The visible pricing layer

Full on-demand rates for us-east-1, verified August 19, 2026:

Prices in USD per million tokens for us-east-1 on-demand. Cross-region inference profiles may add 10% on certain models. Cache read discount varies by provider (Anthropic ~90%, Nova 75%, others N/A). Batch always 50% off.

The hidden cost lines (the real story)

Teams that budget only from the model pricing page consistently overshoot 1.5-2x. The overruns:

The five biggest visible cost levers

1. Model routing — Nova Micro at $0.035 vs Claude Opus at $5 is a 143x spread. Route by task complexity.
2. Prompt caching — 90% off cached input on Claude, 75% off on Nova. Cache stable system prompts, tool definitions, RAG contexts.
3. Batch inference — 50% off both input and output for non-realtime work.
4. Cross-region only when needed — 10% surcharge left on unnecessarily is pure waste.
5. Consider Reserved Tier for predictable production volume — 10-30% off list rates for 1-3 month commit.

Real workload cost examples

1M requests/month at 2000 input + 800 output tokens each:

Cost anti-patterns on Bedrock specifically

• Defaulting every call to Claude Opus when Nova Pro or Sonnet would work — enormous overpay
• Using Llama on Bedrock when Together AI or Fireworks would be 2-3x cheaper for the same model
• Enabling Bedrock Agents when a straight InvokeModel loop would use 5-10x fewer tokens
• Enabling Bedrock KB when your vector store already exists — pay for OpenSearch you don't need
• Cross-region inference profile enabled from initial setup and never disabled
• CloudWatch modelInvocationLoggingConfiguration at 100% capture in production — massive logging bill
• PT commits without utilization measurement — paying hourly for capacity you're not using
• Fine-tuning experiments that end with a fine-tuned model in production — commits you to PT minimum

For cross-provider cost patterns spanning Bedrock and non-Bedrock providers, see the AI API Cost Optimization Playbook 2026.

Bedrock vs direct provider APIs

Every model on Bedrock exists elsewhere — Claude on Anthropic API, Llama on Together AI or Fireworks, Cohere on Cohere's own API. When does Bedrock win? When does going direct win? This chapter is the decision framework, split by model family because the answer differs.

Claude: Bedrock ≈ Anthropic API on price

Claude on Bedrock matches Anthropic direct API pricing in standard regions. AWS does not add a markup for Anthropic models. Non-price factors decide the choice:

Rule of thumb: if your infra runs on AWS and you don't need Anthropic's newest betas, use Bedrock. If you need MCP connector, Managed Agents, or want new Claude versions on day zero, use Anthropic direct.

Llama: Bedrock loses on price by 2-3x

Meta doesn't offer a first-party API, so multiple third-party providers compete on Llama pricing. Bedrock's Llama pricing runs 2-3x higher than dedicated inference providers:

Actual spread depends on model and provider. For Llama specifically, if your workload doesn't need AWS integration, non-Bedrock providers usually win on cost. Claude and Nova are competitive; Llama is not.

Nova: Bedrock is the only path

Amazon Nova models exist only on Bedrock. If you want Nova Micro at $0.035/1M input — the cheapest usable text model from any major cloud — Bedrock is the only place to get it. That exclusivity is Amazon's answer to the "why Bedrock over direct" question: Nova is the reason to be on Bedrock in the first place for cost-sensitive workloads.

Multi-provider deployment patterns

Enterprise deployments frequently run Bedrock alongside direct provider APIs:

• Feature split — MCP-requiring Claude workloads on Anthropic direct, everything else on Bedrock
• Data-residency split — sensitive workflows on Bedrock (specific AWS region), rest on direct
• Failover — Bedrock primary, direct as backup on 5xx
• Price split — Claude on Bedrock, Llama on Together AI, Nova on Bedrock, OpenAI direct
• Compliance split — regulated workloads on Bedrock (FedRAMP/HIPAA), consumer on direct

For multi-provider setups, a routing layer (LiteLLM, custom router) simplifies the abstraction. Avoid provider-specific features in your core code if portability matters — MCP connector, Managed Agents, and Nova-specific parameters are the hardest to abstract.

Production checklist

Twenty items to verify before your Bedrock integration goes to production. Each item corresponds to at least one incident from real 2026 deployments — with special attention to the hidden costs and IAM pitfalls unique to Bedrock.

IAM & access

1. IAM policies include both foundation-model ARN and any inference-profile ARN you use
2. Model access granted in Bedrock console for every model + region combination
3. Separate IAM roles per environment (dev, staging, prod) with least-privilege scoping
4. STS role assumption tested for cross-account access if applicable

Rate limits & retries

5. boto3 client configured with retries={"mode": "adaptive", "max_attempts": 10}
6. Service quotas verified against expected workload; increases requested for tight quotas
7. Circuit breaker for sustained ThrottlingException or ServiceUnavailableException
8. Fallback pattern to alternate model or provider on hard quota exhaustion

Cost controls (the specifically-Bedrock ones)

9. Cross-region inference profiles disabled if not needed for capacity
10. CloudWatch modelInvocationLoggingConfiguration sampled, not 100% at high volume
11. OpenSearch Serverless baseline understood if using Bedrock KB (~$350-$700/mo minimum per collection)
12. Bedrock Agent token consumption measured end-to-end, not per user query
13. Guardrails runtime cost budgeted separately from inference
14. Fine-tuning + PT commit implications understood before starting a fine-tuning experiment

Model routing & performance

15. Default model chosen by task complexity — Nova Micro for classification, Sonnet for most work, Opus for hardest
16. Prompt caching enabled on stable prefixes; cache hit rate measured per workflow
17. Non-realtime workloads submitted to Batch API for 50% discount
18. Long-context workloads verified against per-model context ceilings

Observability & compliance

19. Response IDs and invocation metadata logged for every request (for AWS support cases)
20. Guardrail blocks routed to a distinct code path with pattern-analysis logging

Frequently asked questions

The full library — 36 Bedrock error pages

Every Bedrock error-fix page on AI Error Hub, organized by category. Bookmark this section — when you hit a specific error, jump straight to the page that walks through it with tested code.