Audience: Platform engineers and FinOps leads managing multi-region Amazon Bedrock deployments.
TL;DR for FinOps: Cross-region inference adds no cost surcharge and is priced at the source region’s rate. Flex tier cuts on-demand spend by ~50% for batch-tolerant workloads. PrivateLink is a compliance spend, not a cost-saving spend — $7–22/month per AZ per endpoint adds up fast on multi-endpoint Bedrock stacks. Model availability, not cost, is the primary driver of routing decisions in 2026.
How It Works
Cross-region inference (CRIS), generally available since August 2024, lets a single API call automatically route to a different AWS region when the caller’s home region is capacity-constrained. The caller does not pick the destination region; Bedrock’s control plane selects from a pre-defined set of eligible regions.
The abstraction is an inference profile ARN rather than a direct model ARN. Instead of invoking:
arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6
you invoke a system-defined cross-region inference profile:
arn:aws:bedrock:us-east-1::inference-profile/us.anthropic.claude-sonnet-4-6-20260630-v1:0
The us. prefix signals the US geographic pool. Bedrock then routes to us-east-1, us-east-2, or us-west-2 depending on available capacity. Geographic pools also exist for EU (eu.) and APAC (ap.). A global profile (global.) routes across all pools — currently limited to select Claude Sonnet 4.x versions.
Throughput uplift: On-demand callers using cross-region profiles can access up to 2× their single-region quota, because Bedrock aggregates quota across pool members. This is the primary production use case: not cost reduction but headroom during traffic spikes.
Which Models Support It
As of mid-2026, cross-region inference profiles are available for:
- Anthropic Claude family (Haiku, Sonnet, Opus — all recent versions)
- Meta Llama 3.x and 4.x
- Amazon Titan Text and Embeddings
- Mistral Large and Mistral Nemo
Not all models support all pool types. Global profiles are currently limited to Claude Sonnet 4 and a small set of Llama 4 variants. Check aws bedrock list-inference-profiles --type-equals SYSTEM_DEFINED in your source region for the live list.
Pricing and the CUR Subtlety
No cross-region surcharge. Pricing is calculated at the source region’s rate — the region you called, not the region that served the request. If us-east-1 and us-west-2 have different per-token prices for a given model, you always pay the us-east-1 rate when calling from us-east-1, regardless of where Bedrock actually routed the request.
CUR reporting trap. In the Cost and Usage Report (CUR 2.0), line_item_region reflects the source region (where you made the API call), not the actual serving region. If you are using line_item_region to verify data residency compliance, CUR is the wrong source — it will show your caller’s region even when inference ran in another region. The correct audit source is CloudTrail. Cross-region inference events appear in CloudTrail in the source region and include a field identifying the actual inference region. Wire this into your SIEM if data residency is a hard constraint.
Cost attribution with Application Inference Profiles: To allocate cross-region inference cost by team, product, or tenant, create an Application Inference Profile on top of the system-defined cross-region profile. This lets you tag requests for Cost Explorer and AWS Budgets without any change to your pricing treatment.
When to Use Cross-Region Inference
| Scenario | Use CRIS? |
|---|---|
| Production workload hitting quota limits | Yes — primary use case |
| Real-time latency-sensitive (<200ms p99 target) | Careful — adds variable latency |
| Compliance requires data stay in a single region | No — disable CRIS for that workload |
| Dev/test without quota concerns | Optional — simpler to skip |
| Batch/async pipeline needing throughput | Yes — combine with Flex tier |
What CRIS Does Not Do
CRIS does not balance load across regions for cost optimization (pricing is source-region-fixed anyway). It does not implement active-active multi-region failover for your application — that requires a different architecture pattern (see Section 3). CRIS is purely a capacity-overflow mechanism within Bedrock’s control plane.
2. Cross-Region Data Transfer Costs
Bedrock API Calls: No Cross-Region Egress Charge
API calls to the Bedrock endpoint (bedrock-runtime.us-east-1.amazonaws.com) are routed over AWS’s internal backbone, not the public internet. AWS does not apply inter-region data transfer charges to Bedrock inference API traffic. You are billed only for token consumption, not for the bytes of the request and response moving between your compute and the Bedrock service endpoint.
This is consistent with how other AWS managed service endpoints work (SageMaker, Rekognition, etc.) — the service endpoint is considered same-region from a data-transfer billing perspective.
Exception — image and video generation. Response payloads for image (Stability, Amazon Titan Image) and video (Amazon Nova Reel) generation can be multi-MB. If you are pulling these responses through NAT Gateway, you will see NAT Gateway data processing charges ($0.045/GB). Route large-payload workloads through a VPC endpoint to avoid NAT Gateway processing costs.
VPC Interface Endpoints (PrivateLink) Cost Model
Bedrock requires interface endpoints (PrivateLink), not Gateway endpoints. Gateway endpoints (S3, DynamoDB) are free; everything else is not.
Per-endpoint costs (US regions, 2026):
| Charge | Rate |
|---|---|
| Hourly per AZ | $0.01/hr → $7.30/month per AZ |
| Data processing | $0.01/GB (first PB), then tiered down |
A minimal Bedrock setup requires these service names:
com.amazonaws.{region}.bedrock— control planecom.amazonaws.{region}.bedrock-runtime— inference APIcom.amazonaws.{region}.bedrock-agent— Agents (if used)com.amazonaws.{region}.bedrock-agent-runtime— Agent invocations
That is 4 endpoints. In a 3-AZ VPC with all endpoints deployed across all AZs:
4 endpoints × 3 AZs × $7.30/month = $87.60/month in endpoint hourly fees alone
Add kms and s3 (Gateway — free) if you have encrypted prompts or Knowledge Bases with S3 sources. A full Knowledge Bases stack with 6 interface endpoints across 3 AZs is approximately $131/month before data processing charges, consistent with AWS’s own example cost tables.
Inter-AZ data transfer within the same region for PrivateLink traffic has been free since April 2022 — that is not a concern.
PrivateLink vs. Internet Endpoint Decision
PrivateLink is a compliance and security spend, not a cost optimization. The math:
- Monthly PrivateLink cost for 4 endpoints, 3 AZs: ~$88/month
- Monthly data processing on 100GB response traffic: $1
- Total: ~$89/month for the private path
Unless your security posture, audit requirements, or data classification mandate private connectivity, the internet endpoint is functionally equivalent for Bedrock. Bedrock traffic is TLS-encrypted regardless of path. The internet path saves ~$89/month per VPC.
When PrivateLink is worth the spend:
- PCI-DSS, HIPAA, or FedRAMP compliance requiring no internet egress
- Prompts containing PII and a security policy prohibiting internet-routed data
- Regulatory requirement for documented network path (audit artifact)
- GovCloud deployments (internet endpoints unavailable in some partitions)
When PrivateLink is not worth the spend:
- Internal tooling, dev/test, or low-classification data
- Cost-sensitive multi-account architectures where per-account endpoint costs compound
- Workloads already protected by SCPs preventing internet egress from other paths
Hub-Account Endpoint Architecture
For multi-account Bedrock deployments, the two patterns are:
Per-account endpoints: Each account gets its own VPC endpoints. Simple to manage, maximum isolation, but cost multiplies by account count. At $88/month per account, a 10-account org pays $880/month before any inference spend.
Hub-account shared endpoint via Transit Gateway: One account (a network/egress hub) holds the VPC endpoints. Spoke accounts route Bedrock traffic via TGW attachments to the hub VPC. This reduces endpoint cost to one set but adds TGW attachment cost ($0.05/hr/attachment = $36.50/month per spoke attachment) and TGW data processing ($0.02/GB). The break-even point is roughly 3–4 accounts; beyond that the hub model is cheaper. This is the recommended pattern for organizations with 5+ Bedrock-using accounts.
3. Multi-Region Active-Active Patterns
Why Model Availability Drives Routing More Than Cost
In 2026, the dominant reason to implement multi-region Bedrock routing is model availability, not cost. Newer Claude and Llama model versions ship to us-east-1 and us-west-2 weeks before eu-west-1, ap-southeast-1, or ap-northeast-1. Teams that want the latest model in all regions without cross-region inference profiles must implement application-layer routing.
Bedrock does not publish a global model-availability API — you must check aws bedrock list-foundation-models per region and maintain your own availability matrix, or rely on LiteLLM’s router, which discovers availability lazily on first call.
LiteLLM Multi-Region Routing
LiteLLM’s Router supports Bedrock as a provider and can spread calls across multiple regional deployments with pluggable routing strategies.
Minimal multi-region config:
model_list:
- model_name: claude-sonnet
litellm_params:
model: bedrock/anthropic.claude-sonnet-4-6
aws_region_name: us-east-1
aws_access_key_id: os.environ/AWS_ACCESS_KEY_ID_USE1
aws_secret_access_key: os.environ/AWS_SECRET_ACCESS_KEY_USE1
- model_name: claude-sonnet
litellm_params:
model: bedrock/anthropic.claude-sonnet-4-6
aws_region_name: eu-west-1
aws_access_key_id: os.environ/AWS_ACCESS_KEY_ID_EUW1
aws_secret_access_key: os.environ/AWS_SECRET_ACCESS_KEY_EUW1
router_settings:
routing_strategy: latency-based-routing
num_retries: 2
timeout: 30
allowed_fails: 3
cooldown_time: 60
latency-based-routing caches observed p50 response times per deployment and routes new requests to the fastest-responding deployment. The latency cache is updated on every response. This is suitable for interactive workloads where you want the fastest available region.
least-busy routes based on concurrent in-flight requests — better for batch workloads where you want to distribute load rather than optimize for latency.
Failover pattern: Set allowed_fails and cooldown_time to handle regional throttling. LiteLLM will automatically demote a deployment that returns consecutive throttle errors, retry in the fallback region, and re-enable the primary after cooldown_time seconds.
Route 53 Latency Routing for Bedrock
If you are not using LiteLLM and want infrastructure-layer routing, Route 53 latency routing can front multiple Bedrock-calling services (e.g., Lambda functions or ECS tasks per region) and route clients to the nearest healthy endpoint.
Health check cost: Route 53 health checks are $0.50/month per endpoint (HTTP/HTTPS, non-alias). For a 3-region active-active setup: $1.50/month. Negligible. Add $1.00/month for each health check with string matching.
This approach routes your application traffic, not Bedrock traffic directly. The client calls your Route 53 CNAME; that resolves to a region-local service; that service calls the local Bedrock endpoint. Model availability mismatches still require application logic to handle.
Cost of Warm Multi-Region Endpoints
Bedrock on-demand has no warm endpoint cost — you pay per token, nothing for idle capacity. However:
- VPC endpoints in each region are always-on costs (see Section 2): ~$88/month per region for a 4-endpoint, 3-AZ stack
- Provisioned throughput (reserved capacity) has an hourly commitment — do not provision in regions you are using only as fallbacks; use on-demand there
- LiteLLM proxy running as ECS Fargate in multiple regions adds ~$15–30/month per region (0.25 vCPU, 0.5 GB) for the proxy layer itself
A 3-region active-active with PrivateLink and a LiteLLM proxy layer costs approximately $300–350/month in fixed infrastructure before inference token spend.
4. Cross-Account Bedrock Access Patterns
What Bedrock Supports (and Does Not)
Bedrock uses identity-based policies only — it does not support resource-based policies. You cannot attach a policy to a Bedrock model ARN the way you attach a bucket policy to an S3 bucket. Cross-account access must be mediated through IAM role assumption.
Cross-Account IAM Role Assumption
The standard pattern:
-
In the Bedrock account (Account B), create an IAM role
bedrock-cross-account-rolewith a trust policy allowing Account A’s principal to assume it, and an inline policy grantingbedrock:InvokeModelandbedrock:InvokeModelWithResponseStream. -
In Account A, your application code (Lambda, ECS task, EC2 instance role) calls
sts:AssumeRoletargeting Account B’s role ARN. STS returns temporary credentials scoped tous-east-1(or wherever Bedrock lives). -
Use those credentials to sign Bedrock API calls.
STS cost: AssumeRole calls are free. STS has no per-call charge.
LiteLLM cross-account config:
model_list:
- model_name: claude-sonnet-xaccount
litellm_params:
model: bedrock/anthropic.claude-sonnet-4-6
aws_region_name: us-east-1
aws_role_name: arn:aws:iam::123456789012:role/bedrock-cross-account-role
aws_session_name: litellm-session
LiteLLM will refresh the assumed-role credentials before expiry (default 1-hour sessions). Set DurationSeconds on the AssumeRole call if you need longer sessions for batch workloads — max is 12 hours with an appropriate role trust policy.
VPC Endpoint Cross-Account Access
VPC interface endpoints can be accessed cross-account via endpoint policies. You can create the Bedrock VPC endpoint in a hub account and grant access to spoke accounts. The endpoint policy on the hub side must explicitly allow the spoke account’s IAM principals:
{
"Statement": [{
"Principal": {
"AWS": "arn:aws:iam::SPOKE_ACCOUNT_ID:root"
},
"Action": "bedrock:*",
"Effect": "Allow",
"Resource": "*"
}]
}
Combine this with the hub-account TGW architecture described in Section 2 to reduce both endpoint costs and the number of IAM role assumptions required.
Application Inference Profile Cross-Account Sharing
Application Inference Profiles (created by a user to tag and track usage) are account-scoped resources. They cannot currently be directly shared cross-account. If you need cost attribution across accounts, each account must create its own Application Inference Profile targeting the same system-defined cross-region profile. Consolidate cost data through CUR at the AWS Organizations management account level.
For tenant-level attribution in multi-tenant architectures, tag cross-account assume-role sessions with aws:RequestTag/tenant-id and match those tags to Cost Explorer custom cost allocation tags.
Cross-Account CUR Consolidation
AWS Organizations management accounts receive a consolidated CUR covering all member accounts. The line_item_usage_account_id column identifies which account generated each Bedrock line item. Use AWS Cost Explorer with the “Linked Account” dimension to break down Bedrock spend by account, or query CUR directly in Athena.
Reference: see the companion notes on CUR cost attribution patterns for Bedrock multi-account deployments.
5. Regional Pricing Differences
Anthropic Claude Models: Unified Pricing
A significant change in 2025–2026: Anthropic models on Bedrock moved to consistent pricing across regions for on-demand inference. Claude Sonnet 4.x, Haiku 3.x, and Opus 3.x carry the same per-token rate in us-east-1, us-west-2, eu-west-1, ap-southeast-1, and ap-northeast-1.
This matters for FinOps: routing to a cheaper region to save on per-token cost is not a viable optimization for Claude workloads. The routing optimization for Claude is throughput (CRIS) and tier (Flex vs Standard), not geography.
Non-Anthropic Models: Regional Variation Persists
Models from other providers — Amazon Titan, Meta Llama, Mistral, Cohere — continue to show regional pricing variation. Typical differentials:
| Model Family | US (cheapest) | EU (typical delta) | APAC (typical delta) |
|---|---|---|---|
| Amazon Titan Text Lite | baseline | +0–5% | +10–15% |
| Meta Llama 3.x 70B | baseline | +5–10% | +10–20% |
| Mistral Large | baseline | parity in eu-west-1 | +10–15% |
For non-Claude workloads at scale, routing to us-east-1 or us-west-2 (whichever has the model and the capacity) is the correct FinOps default. Apply CRIS profiles first; only implement application-layer geo-routing if CRIS pools are insufficient.
Data Residency Overrides Cost
Legal constraints take precedence over all cost considerations. EU AI Act (August 2026 deadline), German BSI guidance, and several APAC data localization laws require that inference for certain data categories remain within a defined geographic boundary. AWS supports this through:
- Geographic cross-region inference profiles (e.g.,
eu.prefix stays within EU pool:eu-west-1,eu-west-3,eu-central-1) - SCP-level region restrictions: deny
bedrock:*unlessaws:RequestedRegionis in an allowed set - IAM condition keys:
bedrock:RequestedRegion(where supported) can constrain at the policy level
A correct EU-compliant setup uses the eu. geographic inference profile, an SCP that blocks non-EU Bedrock calls for the relevant OUs, and CloudTrail log validation that inferenceRegion in events is always within the approved set.
6. Bedrock Flex Inference Tier
GA and Pricing
Amazon Bedrock introduced Priority and Flex inference service tiers in November 2025. Flex is generally available across all regions where supported models are available.
Flex pricing: approximately 50% discount versus Standard (on-demand) tier. This is comparable to the existing Batch inference discount, but Flex requests flow through the synchronous InvokeModel and Converse APIs rather than the asynchronous batch job API. For workloads that previously needed batch for cost but required synchronous API semantics, Flex fills that gap.
SLA: Flex is best-effort. During periods of high demand, Flex requests receive lower priority than Standard requests. AWS does not publish a latency SLA for Flex — treat it as “minutes, not seconds” for worst-case sizing. In practice, Flex latency is often comparable to Standard during off-peak hours.
When Flex Is Appropriate
| Workload | Flex? |
|---|---|
| Model evaluations and evals pipelines | Yes |
| Document summarization (async OK) | Yes |
| Labeling and annotation at scale | Yes |
| Multi-step agentic pipelines (non-interactive) | Yes |
| Background RAG indexing | Yes |
| Real-time chat or copilot | No — use Standard |
| SLA-bound customer-facing API | No — use Standard or Priority |
| Latency-sensitive agentic loops | No |
How to Invoke Flex
Flex is selected by setting performanceConfig on the API call:
response = bedrock_runtime.converse(
modelId="anthropic.claude-sonnet-4-6-20260630-v1:0",
messages=[{"role": "user", "content": [{"text": "Summarize this document."}]}],
performanceConfig={"latency": "optimized"} # Standard
# For Flex: performanceConfig={"latency": "standard"} ← AWS's confusing naming
)
Note the naming inversion: AWS named the Flex (slower, cheaper) tier "standard" latency and the fast tier "optimized" in the performanceConfig parameter. This is a known footgun.
CUR Appearance for Flex vs Standard
In CUR 2.0, service tier is encoded in the line_item_usage_type column. Flex line items include a Flex token in the usage type string. Example:
USE1-Flex:anthropic.claude-sonnet-4-6:InputTokens
USE1-Flex:anthropic.claude-sonnet-4-6:OutputTokens
versus Standard:
USE1-anthropic.claude-sonnet-4-6:InputTokens
USE1-anthropic.claude-sonnet-4-6:OutputTokens
This makes it straightforward to build Athena queries or Cost Explorer filters that compare Standard vs Flex spend by model and region, and to validate that batch-tolerant workloads are correctly hitting the Flex tier.
Flex and Cross-Region Inference
Flex and CRIS are orthogonal and composable. You can invoke a CRIS profile (e.g., us.anthropic.claude-sonnet-4-6...) with Flex performance config. Bedrock applies Flex prioritization after selecting the serving region. The pricing for Flex CRIS calls is: Flex discount applied to the source-region Standard rate.
7. PrivateLink and VPC Endpoint Cost Model — Full Breakdown
Interface vs Gateway Endpoints
| Type | Examples | Hourly charge | Data processing |
|---|---|---|---|
| Gateway | S3, DynamoDB | Free | Free |
| Interface (PrivateLink) | Bedrock, STS, KMS, ECR, CloudWatch | $0.01/hr/AZ | $0.01/GB |
All Bedrock API surface area uses Interface endpoints. There are no Gateway endpoints for Bedrock.
Full Bedrock Stack Endpoint Inventory
For a complete Bedrock deployment with Agents, Knowledge Bases, and encrypted prompts:
| Endpoint | Required for |
|---|---|
bedrock |
ListModels, GetModel, control plane |
bedrock-runtime |
InvokeModel, Converse, streaming |
bedrock-agent |
Create/manage agents |
bedrock-agent-runtime |
InvokeAgent |
bedrock-agentcore |
AgentCore (new in 2026) |
kms |
CMK-encrypted model invocations |
s3 (Gateway) |
Knowledge Base source buckets — free |
Five interface endpoints across 3 AZs:
5 × 3 × $0.01/hr × 730hr/month = $109.50/month
Plus data processing: at typical Bedrock response sizes (1–5KB for text), 100,000 requests/day × 5KB avg = 500MB/day = 15GB/month → $0.15/month. Negligible for text workloads.
Hub-Account Cost Comparison
10-account org, all accounts have Bedrock workloads:
| Architecture | Monthly fixed cost |
|---|---|
| Per-account endpoints (5 endpoints, 3 AZ each) | 10 × $109.50 = $1,095/month |
| Hub-account (1 endpoint set) + TGW (9 spokes) | $109.50 + (9 × $36.50 TGW attachment) + TGW processing |
The hub model saves approximately $650/month for a 10-account org — roughly 60% reduction in fixed network costs. The crossover point is at 4 accounts.
When to Skip PrivateLink Entirely
If compliance does not mandate private connectivity, skip PrivateLink and use the public Bedrock endpoint over the internet (TLS is mandatory regardless). For typical SaaS or internal tooling:
- No endpoint hourly cost
- No data processing charge
- Traffic is still encrypted
- Standard AWS Shield and WAF rules still apply to your application layer
The only security delta is that your API calls traverse the public internet rather than staying on AWS backbone. For non-regulated workloads, this is an acceptable trade-off for ~$110/month/region in savings.
Key Decision Tree
Is data residency a hard constraint?
├── YES → Use geographic CRIS profile (eu. / ap.) + SCP region lock
│ Skip cross-region cost optimization
└── NO → Is the workload latency-sensitive?
├── YES → Enable CRIS (us. or global.) for throughput headroom
│ Use Standard tier
│ LiteLLM latency-based-routing if multi-region
└── NO → Enable Flex tier for ~50% savings
Enable CRIS for throughput
Consider Batch API for pure async jobs (same ~50% discount, async semantics)
Is this a multi-account org (5+ accounts using Bedrock)?
├── YES → Hub-account TGW endpoint architecture
│ Cross-account IAM role assumption + LiteLLM role config
└── NO → Per-account endpoints if compliance requires PrivateLink
Otherwise: public internet endpoint
Is PrivateLink required?
├── YES → Budget ~$88–$130/month per region per VPC for endpoint costs
└── NO → Skip PrivateLink; save $88–$130/month/region
Summary Reference Table
| Feature | Detail |
|---|---|
| CRIS pricing | Source region rate, no surcharge |
| CRIS CUR field | line_item_region = caller region, not serving region |
| CRIS audit source | CloudTrail inferenceRegion field |
| Flex discount | ~50% vs Standard on-demand |
| Flex SLA | Best-effort; no published latency SLA |
| Flex CUR token | Flex: in line_item_usage_type |
| Interface endpoint cost | $0.01/hr/AZ = $7.30/month/AZ |
| Data processing (PrivateLink) | $0.01/GB, tiered down at PB scale |
| Cross-account IAM | Role assumption only; no resource-based policies |
| STS cost | Free |
| Claude regional pricing | Unified across regions (as of 2025–2026) |
| Non-Claude regional delta | 10–20% higher in APAC vs US |
Sources
- Amazon Bedrock cross-region inference GA (AWS, Aug 2024)
- Cross-Region Inference docs — Increase throughput
- Global cross-Region inference docs
- Geographic cross-Region inference docs
- Amazon Bedrock Priority and Flex inference tiers GA (Nov 2025)
- Service tiers docs (Flex / Standard / Priority)
- Bedrock CUR data understanding
- Bedrock IAM cost allocation by IAM role (Apr 2026)
- Bedrock cross-account access — AWS re:Post
- Inference profile prerequisites
- Supported regions and models for inference profiles
- Bedrock regional model availability
- Bedrock VPC interface endpoints — AgentCore docs
- AWS PrivateLink pricing — pump.co analysis
- VPC endpoints pricing guide
- LiteLLM routing docs
- LiteLLM proxy load balancing docs
- LiteLLM + Bedrock routing (AWS Samples)
- Cross-Region inference architecture deep dive (AWS Builder Center)
- Implementing CRIS with Landing Zone (AWS re:Post)
- Multi-tenant cost tracking with Application Inference Profiles (AWS Builder Center)
- Amazon Bedrock pricing page
- Amazon Bedrock consistent Anthropic pricing across regions (dev.to)
- Global CRIS for Claude Sonnet 4.5 (AWS, Sep 2025)