← Agent Frameworks 🕐 20 min read

Agent Frameworks

Bedrock Cross-Region Inference — Cost Premium, Latency, and Governance (2026)

Overview · March 2026

Amazon Bedrock Cross-Region Inference (CRIS) enables automatic routing of inference requests across multiple AWS Regions within defined geographic boundaries or globally.

Amazon Bedrock Cross-Region Inference (CRIS) enables automatic routing of inference requests across multiple AWS Regions within defined geographic boundaries or globally. It solves two distinct problems: capacity bursting past per-region on-demand quotas, and compliance-safe throughput scaling for regulated industries. Understanding the pricing structure, CUR attribution mechanics, and quota pooling behavior is prerequisite to sizing and governing CRIS in production.

This synthesis covers the full cost surface: CUR line-item mechanics, model support matrix, inference profile types, LiteLLM integration, latency tradeoffs, data residency controls, quota behavior, and the break-even threshold between CRIS on-demand and the Reserved tier.

1. CRIS Pricing: How the Cost Signal Appears in CUR

1.1 The Canonical Misconception

CRIS does not add a routing surcharge on top of standard token pricing. The “20–30% premium” framing that circulates in FinOps communities conflates two separate effects:

Unit price parity at the source region: Geographic cross-region profiles charge at the standard on-demand rate for the source region where the API call originates. No additional fee.
Global profiles carry a ~10% discount: As of 2025–2026, Global cross-Region inference for Anthropic Claude Sonnet 4.5 is priced approximately 10% below geographic profiles on both input and output tokens. This makes Global CRIS the cheaper option against geographic CRIS, not more expensive than single-region.
The perceived premium originates elsewhere: Prompt cache invalidation (caches are per-region and do not replicate) causes more cache-write charges when CRIS routes consecutive requests to different regions. On cache-heavy workloads, this cache miss tax can compound to 20–30% of effective token spend — which is what practitioners observe and mislabel as a “CRIS premium.”

1.2 CUR 2.0 Line-Item Format

line_item_usage_type encodes the full cost vector: region, model, token type, service tier, and routing mode. The format for cross-region requests is:

{region}-{model}-{token-type}-cross-region-global

Examples from the AWS CUR documentation (June 2026):

`line_item_usage_type`	Model	Tier	Token Type	Routing
`USE1-Claude4.6Sonnet-input-tokens`	Claude Sonnet 4.6	Standard	Input	In-region
`USE1-Claude4.6Sonnet-output-tokens-cross-region-global`	Claude Sonnet 4.6	Standard	Output	Cross-region (Global)
`USE1-Nova2.0Lite-input-tokens-flex`	Amazon Nova 2 Lite	Flex	Input	In-region
`USE1-Claude4.6Sonnet-cache-read-input-token-count`	Claude Sonnet 4.6	Standard	Cache Read	In-region

The -cross-region-global suffix is the authoritative signal in CUR that a request was routed through a global inference profile. Geographic CRIS requests (US, EU, APAC profiles) appear under the source region with standard usage type format — no geographic suffix is appended in the current CUR schema.

Attribution note: CUR aggregates by usage type over an hour or day; it does not carry a per-requestId grain. To trace a specific request to its actual destination region, join CUR data with model invocation logs. CUR alone tells you that CRIS was used and what it cost; CloudTrail tells you where the request actually ran.

1.3 Key CUR Query Patterns

Identify all CRIS spend (Athena / CUR 2.0):

SELECT
  line_item_usage_type,
  SUM(line_item_unblended_cost) AS cris_cost,
  SUM(line_item_usage_amount) AS token_volume
FROM cur_data
WHERE line_item_product_code = 'AmazonBedrock'
  AND line_item_usage_type LIKE '%-cross-region-global'
GROUP BY line_item_usage_type
ORDER BY cris_cost DESC;

Split in-region vs CRIS spend by model:

SELECT
  CASE
    WHEN line_item_usage_type LIKE '%-cross-region-global' THEN 'CRIS'
    ELSE 'In-Region'
  END AS routing_type,
  REGEXP_EXTRACT(line_item_usage_type, '[A-Z0-9]+-([^-]+(?:-[^-]+)*)-(?:input|output|cache)', 1) AS model,
  SUM(line_item_unblended_cost) AS cost_usd
FROM cur_data
WHERE line_item_product_code = 'AmazonBedrock'
  AND usage_start_date >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY 1, 2
ORDER BY 3 DESC;

Surface the cache miss tax (CRIS prompt cache write inflation):

SELECT
  line_item_usage_type,
  SUM(line_item_unblended_cost) AS cost_usd
FROM cur_data
WHERE line_item_product_code = 'AmazonBedrock'
  AND line_item_usage_type LIKE '%-cache-write-input-token-count'
GROUP BY line_item_usage_type
-- Compare against a prior period when CRIS was disabled to isolate the cache-miss delta

2. Model Support Matrix: Which Models Support CRIS Profiles (June 2026)

CRIS support is model-specific and differs between geographic and global profiles. Global inference profiles currently have narrower model coverage than geographic profiles.

2.1 Anthropic Claude Family

Model	Geographic CRIS (US/EU/APAC)	Global CRIS	Notes
Claude Opus 4.x	Yes (US, EU, APAC)	Yes	5x output token burndown rate applies
Claude Sonnet 4.5	Yes (US, EU, APAC)	Yes — canonical launch model for Global CRIS	5x output burndown
Claude Sonnet 4.6	Yes (US, EU, APAC)	Yes	5x output burndown
Claude Haiku 4.5	Yes (US, EU, APAC)	Yes (expanded to SEA, MENA in 2026)	1:1 burndown
Claude Sonnet 3.7	Yes (US, EU, APAC)	Yes	5x output burndown
Claude 3.5 Haiku	Yes (US, EU, APAC)	Limited — check model detail page	1:1 burndown
Claude 3 Opus	Geographic only	Not supported	Legacy path; prefer 4.x

5x burndown rule: For Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, and Claude Sonnet 3.7, the quota consumption formula is: Input tokens + Cache write tokens + (Output tokens × 5). This materially changes quota sizing when output-heavy workloads use CRIS.

2.2 Amazon Nova Family

Model	Geographic CRIS	Global CRIS	Notes
Amazon Nova Pro	Yes — US, EU, APAC available as of Feb 2025	No (as of June 2026)	Multimodal; good accuracy/cost tradeoff
Amazon Nova Lite	Yes — US, EU, APAC	No	Fast, cheap; 1:1 burndown
Amazon Nova Micro	Yes — US, EU, APAC	No	Text-only, lowest latency floor
Amazon Nova 2.0 Lite	Yes	No	Added Flex tier support
Amazon Nova Canvas / Reel	Not supported	Not supported	Generation models excluded from CRIS

2.3 Meta Llama 3.x Family

Model	Geographic CRIS	Global CRIS	Notes
Llama 3.1 8B Instruct	US only	No	Limited CRIS coverage
Llama 3.1 70B Instruct	US, EU	No
Llama 3.1 405B Instruct	US only	No
Llama 3.3 70B Instruct	US, EU	No
Llama 4 Scout / Maverick	US, EU (emerging)	No	Check model detail pages; coverage expanding

2.4 Models That Do Not Support CRIS

Embedding models (Titan Embeddings, Cohere Embed) — excluded from all inference profiles
Image/video generation models (Stability AI, Nova Canvas, Nova Reel)
Amazon Titan Text — no inference profile support; use Nova equivalents
Custom fine-tuned models — CRIS not available; Provisioned Throughput required

3. Inference Profile Types: System-Defined vs Application-Defined

CRIS is delivered through system-defined inference profiles. Application inference profiles are a separate, orthogonal construct for cost tagging. Understanding which does what prevents architecture confusion.

3.1 System-Defined (Cross-Region) Inference Profiles

AWS creates and manages these. They define the routing topology: which source regions can call the profile and which destination regions requests can be dispatched to.

Profile ID patterns:

Geographic US: us.anthropic.claude-sonnet-4-5-20250929-v1:0
Geographic EU: eu.anthropic.claude-sonnet-4-5-20250929-v1:0
Geographic APAC: apac.anthropic.claude-sonnet-4-5-20250929-v1:0
Global: global.anthropic.claude-sonnet-4-5-20250929-v1:0

Routing behavior: AWS selects the optimal destination region at request time based on current capacity utilization. The caller has no direct control over which destination region receives a specific request. Consecutive requests from the same session may route to different regions.

Cost model: Billed at source region rates. No routing surcharge. Global profiles carry ~10% discount versus geographic profiles.

Quota model: Quota is tracked per source region, per inference profile. CRIS profiles have separate quota lines from single-region quotas in the Service Quotas console:

Geographic: Cross-region model inference tokens per minute for {Model}
Global: Global Cross-region model inference tokens per minute for {Model}

Control: You cannot restrict which destination region receives a request within a geographic profile. If compliance requires pinning to a specific single region, use that region’s model ARN directly — not the CRIS profile.

3.2 Application-Defined Inference Profiles

User-created resources that wrap a foundation model (or system-defined profile) with cost allocation tags. They do not change routing behavior — they change billing attribution.

Primary use case: FinOps tag propagation to CUR for team/application/workload chargeback.

# Create an application inference profile
response = bedrock_client.create_inference_profile(
    inferenceProfileName="team-payments-prod-sonnet46",
    description="Payments team production workload",
    modelSource={
        "copyFrom": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6-20260101-v1:0"
    },
    tags=[
        {"key": "team", "value": "payments"},
        {"key": "env", "value": "prod"},
        {"key": "costcenter", "value": "CC-2041"}
    ]
)
# Returns ARN: arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/abcdef123456

Key constraint: Each application inference profile is model-specific. You need separate profiles for every unique (model, team, tag-set) combination. For organizations with many teams and models, use AWS Bedrock Projects (bedrock-mantle endpoint) to avoid profile proliferation.

3.3 Combining Both Profile Types

You can wrap a system-defined CRIS profile inside an application inference profile to get both cross-region routing and cost attribution:

# Wrap the US geographic CRIS profile with cost tags
response = bedrock_client.create_inference_profile(
    inferenceProfileName="team-payments-prod-cris-sonnet46",
    modelSource={
        "copyFrom": "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-6-..."
    },
    tags=[{"key": "team", "value": "payments"}]
)

The resulting ARN used as modelId routes through CRIS while tagging spend to the payments team in CUR.

3.4 Control and Cost Tradeoff Summary

Dimension	System-Defined (CRIS)	Application-Defined	CRIS + AIP Combined
Routing	AWS-managed, multi-region	Single model, single region	AWS-managed, multi-region
Quota pool	CRIS quota (larger)	Standard on-demand quota	CRIS quota
CUR attribution	By usage type	By AIP tags (team/app/env)	Both
Cache hit rate	Reduced (multi-region cache isolation)	Full (single-region cache)	Reduced
Management overhead	Low	Medium (one profile per model×team×tagset)	Medium-High
Data residency	Geographic boundary enforced	Single region (most restrictive)	Geographic boundary enforced

4. LiteLLM Integration with CRIS

LiteLLM supports Bedrock CRIS via two path patterns. The choice affects whether you get geographic vs global routing behavior and how cost tags flow.

4.1 Using System-Defined Profile IDs Directly

Pass the geographic or global profile ID as the model string:

import litellm

# Geographic US CRIS profile (system-defined)
response = litellm.completion(
    model="bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{"role": "user", "content": "Summarize this document"}]
)

# Global CRIS profile (system-defined, ~10% cheaper, no geo constraint)
response = litellm.completion(
    model="bedrock/global.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{"role": "user", "content": "Summarize this document"}]
)

LiteLLM resolves the model string directly to the Bedrock API; the CRIS routing happens server-side.

4.2 Using Application Inference Profile ARNs

When you need cost attribution tags to flow through CUR, pass the application inference profile ARN:

# Via model_id parameter (base model ID still required for LiteLLM metadata)
response = litellm.completion(
    model="bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    model_id="arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/abcdef123456",
    messages=[{"role": "user", "content": "Hello"}]
)

# Via the bedrock/converse/ route with ARN directly
response = litellm.completion(
    model="bedrock/converse/arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/abcdef123456",
    messages=[{"role": "user", "content": "Hello"}]
)

4.3 LiteLLM Proxy Config (YAML)

For multi-tenant proxy deployments with per-team CRIS profiles:

model_list:
  - model_name: claude-sonnet-prod
    litellm_params:
      model: bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0
      aws_region_name: us-east-1

  - model_name: claude-sonnet-prod-tagged
    litellm_params:
      model: bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0
      model_id: "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/payments-profile"
      aws_region_name: us-east-1

  - model_name: claude-sonnet-global
    litellm_params:
      model: bedrock/global.anthropic.claude-sonnet-4-5-20250929-v1:0
      aws_region_name: us-east-1

4.4 Known LiteLLM Limitations with CRIS

Application inference profiles for image generation models have a known bug (GitHub issue #14373 — ARN routing fails for non-text models).
LiteLLM does not expose CRIS destination region in its response metadata. To observe actual routing, read CloudTrail additionalEventData.inferenceRegion.
Session affinity is not supported: LiteLLM cannot pin a session to a specific destination region within a CRIS profile. Implement session-pinned routing at the application layer by calling the specific regional model ARN when cache locality matters.

5. Cost Optimization: When CRIS Saves Money Despite Cache Miss Tax

The economic case for CRIS versus single-region depends on workload shape.

5.1 Scenarios Where CRIS Wins

Quota bursting at scale (primary case)

Single-region on-demand quotas are finite. When demand exceeds quota, requests throttle (HTTP 429). The cost of a throttled request includes:

Retry delay (latency-sensitive workloads: business cost)
Engineer time implementing retry/backoff logic
Fallback to Provisioned Throughput over-provisioning

CRIS pools quota across regions within a geography. A US geographic profile spans us-east-1, us-east-2, and us-west-2. The effective throughput ceiling is the sum of available capacity across all three, not a single region’s limit. AWS documents that customers on CRIS “can get up to 2x their allocated in-region quotas” as an effective throughput ceiling.

Batch and async workloads

For non-latency-sensitive batch processing (document extraction, summarization pipelines, evals), the cache miss penalty is irrelevant — prompts typically don’t repeat across requests. CRIS provides the highest throughput at standard pricing, making it strictly better than single-region for batch.

New region deployments

When launching a new application region where Bedrock model access is limited or new, CRIS provides immediate model access from the source region without waiting for the model to become natively available in that region. CRIS can route to opt-in regions without requiring account-level opt-in.

5.2 Scenarios Where Single-Region Wins

Cache-heavy agentic workloads

Multi-turn agents with large system prompts rely heavily on prompt cache hits. Cache is per-region and not replicated. CRIS can route consecutive requests in the same session to different regions, forcing cache re-writes at the higher cache-write token price. For workloads where >40% of tokens are cache reads, the cache miss inflation from CRIS can exceed any throughput benefit.

Rule of thumb: If your CacheReadInputTokenCount / InputTokenCount ratio is above 0.4 in a stable steady-state, single-region or session-pinned routing is likely cheaper than broad CRIS.

Reserved tier holders

If you have a Reserved tier capacity reservation on a specific model in a specific region, that reservation only applies to requests sent directly to that region’s model ARN. CRIS bypasses Reserved tier routing (CRIS uses on-demand quota, not Reserved capacity). Routing through CRIS wastes the Reserved investment and charges on-demand rates instead.

5.3 Cost Formula: Effective Token Cost with CRIS Cache Miss Tax

Define:

r_cache = fraction of input tokens served from cache in single-region baseline
P_in = input token price per 1M
P_out = output token price per 1M
P_cache_read = cache read price per 1M (typically ~10% of P_in)
P_cache_write = cache write price per 1M (typically ~125% of P_in)
miss_rate_delta = incremental cache miss rate introduced by CRIS routing (empirically 10–30% of previously cached tokens now miss)

Single-region effective cost per 1M input tokens (with caching):

C_single = (1 - r_cache) × P_in + r_cache × P_cache_read

CRIS effective cost per 1M input tokens (with cache miss inflation):

r_cache_cris = r_cache × (1 - miss_rate_delta)
C_cris = (1 - r_cache_cris) × P_in + r_cache_cris × P_cache_read
       + (r_cache × miss_rate_delta) × P_cache_write  # re-write cost

The miss_rate_delta × P_cache_write term is the CRIS cache miss tax. For Claude Sonnet 4.6 at current rates (illustrative):

P_in = $3.00/1M, P_cache_read = $0.30/1M, P_cache_write = $3.75/1M
With r_cache = 0.5 and miss_rate_delta = 0.2: effective CRIS overhead = 0.5 × 0.2 × $3.75 = $0.375/1M additional vs single-region

At 0.5 cache hit rate and 20% miss delta, CRIS adds ~12–15% to effective input token cost on cache-heavy workloads.

6. Latency Implications

6.1 The Latency Stack for On-Demand CRIS

A CRIS request on bedrock-runtime has a latency floor composed of stacked components:

Component	Typical Range	Notes
Network round-trip (client to source region)	5–50ms	Depends on client geography
CRIS routing decision + inter-region hop	10–50ms	Within-geo: single-digit to low double-digit ms. Cross-continent (Global): 30–80ms
On-demand GPU scheduling / queue	50–200ms	Dominant variable; spikes during peak demand
Model TTFT (first token generation)	100–500ms	Model-dependent
Total TTFT floor	~200–400ms	Observed in community benchmarks

AWS documents that cross-region routing within Europe adds “single to double-digit milliseconds.” The inter-region hop for US geographic profiles (e.g., us-east-1 → us-west-2) adds approximately 30–50ms. For Global profiles routing across continents, the inter-region component can reach 80–150ms.

6.2 CRIS Latency vs Single-Region: When It Inverts

CRIS can produce lower observed latency than single-region even with the inter-region hop overhead, because it routes away from congested regions. When a single source region is under heavy demand, the on-demand GPU scheduling component (50–200ms) inflates. CRIS routing to an underloaded region eliminates the scheduling queue penalty, which typically exceeds the routing overhead.

Empirical pattern from community benchmarks (AWS Builder Center, April 2026):

Under low load: single-region p50 TTFT ≈ CRIS p50 TTFT (within 10–30ms)
Under moderate load (>60% quota utilization): CRIS p50 TTFT often 50–150ms better than single-region
Under high load (>85% quota utilization): CRIS advantage can reach 200–500ms p50

6.3 p99 Latency Behavior

p99 latency diverges more dramatically. Single-region p99 during peak includes throttle retries and scheduling queue outliers. CRIS p99 remains bounded because overflow capacity absorbs the tail. For latency SLA-governed workloads (e.g., customer-facing chatbots), CRIS is generally favorable on p99 despite the slight p50 overhead.

6.4 Streaming vs Non-Streaming

For streaming responses (InvokeModelWithResponseStream / ConverseStream), the inter-region hop adds to TTFT but does not affect tokens-per-second generation speed after the first token. The generation phase is compute-bound at the destination, not network-bound. For streaming latency-sensitive applications, the p50 TTFT penalty from inter-region routing is the only material concern.

6.5 Latency-Optimized Inference + CRIS

AWS’s latency-optimized inference (available for select models) reduces TTFT through speculative decoding and hardware optimizations. It is compatible with geographic CRIS profiles. In AWS benchmarks:

Claude 3.5 Haiku with latency-optimized inference: up to 42% p50 TTFT reduction, up to 52% p90 reduction
Llama 3.1 70B with latency-optimized inference: up to 52% p50 TTFT reduction, up to 97% p90 reduction

Combining latency-optimized inference with geographic CRIS is the recommended architecture for latency-sensitive production workloads — the TTFT improvements from hardware optimization significantly exceed the CRIS routing overhead.

7. Data Residency and Compliance

7.1 Profile Types and Data Residency Guarantees

Profile Type	Data Residency Guarantee	Compliance Posture
Single-region model ARN	Requests processed in exactly one specified region	Strongest guarantee; use for highest-sensitivity data
Geographic CRIS (US)	Stays within us-east-1, us-east-2, us-west-2	Suitable for US data residency requirements
Geographic CRIS (EU)	Stays within EU regions (eu-central-1, eu-west-1, eu-west-2, eu-west-3, eu-south-2, eu-central-2, eu-north-1)	Suitable for GDPR Article 46 adequacy requirements; EU data stays in EU
Geographic CRIS (APAC)	Stays within APAC regions	Suitable for APAC data localization laws
Geographic CRIS (Japan)	Stays within ap-northeast-1 + ap-northeast-3	Separate profile for Japan data residency
Geographic CRIS (Australia)	Stays within ap-southeast-2 + ap-southeast-4	Australian Privacy Act coverage
Global CRIS	Any supported commercial AWS region worldwide	Not suitable for any data residency requirement

Important: Even within geographic profiles, input prompts and output results may be stored in the destination region for abuse detection purposes on certain models (check model-specific documentation). The core processing guarantee is within-geography; the storage guarantee for abuse detection data is separate.

7.2 EU Data Processing Considerations

The EU geographic CRIS profile is the recommended path for GDPR-compliant Bedrock deployments. Key attributes:

All compute stays within the EU AWS regional boundary
Data transmitted between EU regions uses AWS private backbone (does not traverse public internet)
CloudTrail logs in source region (EU) show additionalEventData.inferenceRegion as another EU region
No requirement to add data processing agreements for the destination EU regions — they remain within the EU

An explicit SCP enforcement pattern for EU-only CRIS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyEUBedrockInference",
      "Effect": "Deny",
      "Action": "bedrock:InvokeModel*",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/eu.*"
        }
      }
    }
  ]
}

This denies all Bedrock invocations not using an EU geographic CRIS profile, preventing accidental in-region calls to non-EU regions.

7.3 Financial Services: SR 26-2 and CRIS

The Federal Reserve’s SR 26-2 guidance on AI/ML model risk management does not have a specific carve-out for CRIS routing. Financial services firms should treat CRIS destination regions as part of their model inventory location documentation. The operational risk consideration: CRIS destination region for a given request is non-deterministic at the application layer. Audit trails require CloudTrail inferenceRegion queries to reconstruct which region processed regulated inference workloads.

8. CUR Attribution for CRIS: Destination Region Identification

8.1 What CUR Shows vs What CloudTrail Shows

CUR attributes CRIS spend to the source region (where the API call originated). The destination region (where inference actually ran) does not appear in CUR. This creates a gap: CUR tells you the cost; it does not tell you the geographic distribution of compute.

For pure FinOps purposes (chargeback, budget alerts), CUR is sufficient. For compliance audits requiring proof that data was processed only within a specific geography, CloudTrail is the authoritative source.

8.2 CloudTrail `inferenceRegion` Field

All CRIS requests are logged in CloudTrail in the source region. The additionalEventData.inferenceRegion field records the actual destination region:

{
  "eventName": "InvokeModel",
  "awsRegion": "eu-central-1",
  "requestParameters": {
    "modelId": "eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
  },
  "additionalEventData": {
    "inferenceRegion": "eu-south-2"
  }
}

In this example: source region = eu-central-1 (billed here), destination region = eu-south-2 (where inference ran). Both are in the EU geographic zone.

8.3 Reconstructing Full Attribution (CUR + CloudTrail Join)

CUR does not carry a per-requestId. The join pattern uses time-range and model-grain reconciliation:

For each hour H in period:
  CUR.sum(cost | model=M, usage_type=*cross-region*) →  total CRIS cost for model M
  CloudTrail.groupby(inferenceRegion | model=M, time ∈ H) → request distribution by destination
  
Attribution: cost per destination region ≈ (requests_to_region / total_requests) × CUR_hour_cost

This attribution is approximate (CUR is at token grain, CloudTrail at request grain). For precise per-destination cost attribution, use model invocation logs (which carry both token counts and region metadata) joined to CloudTrail.

9. Quota Management for CRIS

9.1 Quota Architecture

On-demand throughput quotas in Bedrock are regional — each region has its own TPM and RPM limits per model. CRIS does not create a shared pool; instead it accesses separate quotas in each destination region.

The effective throughput gain from CRIS comes from the ability to burst into destination regions’ available capacity, not from a formally pooled quota. When your source region’s quota is exhausted, CRIS routes to destination regions that have available capacity under their own quotas.

The practical effect: a US geographic CRIS profile has access to capacity across up to three US regions simultaneously. Under normal demand distribution, effective throughput can approach 2–3× a single-region quota ceiling before throttling occurs.

9.2 Quota Lines in Service Quotas Console

CRIS introduces new quota identifiers distinct from in-region model quotas:

Quota Name	Description
`Cross-region model inference requests per minute for {Model}`	RPM limit for geographic CRIS profile, managed in source region
`Cross-region model inference tokens per minute for {Model}`	TPM limit for geographic CRIS profile
`Global Cross-region model inference tokens per minute for {Model}`	TPM limit for global CRIS profile
`Global Cross-region model inference requests per minute for {Model}`	RPM limit for global CRIS profile

Quota increase requests for CRIS must be filed from the source region in the Service Quotas console. A quota increase request from eu-central-1 covers the EU geographic CRIS profile when called from eu-central-1 — it does not affect the same profile called from eu-west-1 (that requires a separate increase request from eu-west-1).

9.3 Output Token Burndown Rate Impact on Quota Sizing

For the 5x-burndown models (Claude Opus 4, Sonnet 4.5, Sonnet 4.6, Sonnet 3.7), the effective token consumption against quota is:

quota_tokens_consumed = input_tokens + cache_write_tokens + (output_tokens × 5)

A request with 1,000 input tokens and 500 output tokens consumes 3,500 quota tokens, not 1,500. This means a 1M TPM quota for Claude Sonnet 4.6 supports far fewer actual conversational exchanges than the raw number implies. When sizing CRIS quota requests, calculate from actual response length distributions, not raw token counts.

9.4 Monitoring Quota Consumption with CloudWatch

AWS added CloudWatch metrics for estimated quota consumption (launched May 2025):

EstimatedInputTokenCount — tracks input token rate against TPM quota
EstimatedOutputTokenCount — tracks output token rate
InvocationThrottles — CRIS-specific throttle events visible under the inference profile dimension

Alarm pattern for CRIS quota headroom:

cloudwatch.put_metric_alarm(
    AlarmName='bedrock-cris-quota-80pct',
    MetricName='EstimatedInputTokenCount',
    Namespace='AWS/Bedrock',
    Dimensions=[
        {'Name': 'ModelId', 'Value': 'us.anthropic.claude-sonnet-4-5-20250929-v1:0'},
        {'Name': 'Region', 'Value': 'us-east-1'}
    ],
    Threshold=800000,  # 80% of 1M TPM quota
    ComparisonOperator='GreaterThanThreshold',
    Period=60,
    EvaluationPeriods=5,
    Statistic='Sum',
    AlarmActions=[SNS_TOPIC_ARN]
)

10. Cost Modeling: Break-Even Between CRIS On-Demand and Reserved Tier

10.1 Service Tier Overview

Amazon Bedrock offers four service tiers that interact with CRIS:

Tier	Price Multiplier	Latency Priority	Use Case
Reserved	~60–80% of on-demand (varies by model)	Highest; 99.5% uptime target	Mission-critical, predictable volume
Priority	~130–150% of on-demand	Second highest	Customer-facing, no 24/7 reservation needed
Standard (Default)	1.0× (baseline)	Third	Most workloads
Flex	~50–70% of on-demand	Lowest	Batch, eval, async

Critical: CRIS profiles operate exclusively in Standard tier on bedrock-runtime. Flex tier inference uses CRIS-style routing internally but is not configurable to geographic/global inference profiles. Reserved tier capacity is region-specific and does not interact with CRIS routing.

10.2 Break-Even Formula: CRIS On-Demand vs Reserved Tier

Define:

V_tokens = monthly token volume (input + effective output after burndown)
P_od = on-demand price per 1M tokens
P_res = reserved tier price per 1M tokens (typically 20–40% below on-demand for 1-month commitment; 30–45% for 3-month)
C_fixed = monthly reserved capacity commitment cost (minimum: 100K input TPM + 10K output TPM reserved)
U = utilization rate (fraction of reserved capacity actually consumed)

Monthly cost comparison:

Cost_CRIS_ondemand  = V_tokens × P_od / 1M
Cost_reserved       = C_fixed + max(0, (V_tokens - reserved_capacity) × P_od / 1M)
                                     ↑ overflow spills to on-demand at standard rate

Break-even utilization threshold:

Break-even at U = P_res / P_od

If reserved pricing is 70% of on-demand (P_res / P_od = 0.70), Reserved tier breaks even at 70% utilization. Below 70%, CRIS on-demand is cheaper. Above 70%, Reserved tier saves money.

Empirical ranges (2025–2026 community data):

1-month commitment discount: 15–25% below on-demand → break-even at 75–85% utilization
3-month commitment discount: 30–40% below on-demand → break-even at 60–70% utilization
On-demand CRIS with Global profile (~10% discount): effectively lowers the on-demand baseline, shifting break-even for Reserved to slightly higher utilization

10.3 Break-Even Calculator (Python)

def cris_vs_reserved_breakeven(
    monthly_tokens_M: float,         # tokens in millions
    od_price_per_M: float,           # on-demand price per 1M tokens
    reserved_discount: float,        # e.g., 0.25 for 25% discount
    reserved_min_cost_monthly: float # minimum monthly reserved commitment
) -> dict:
    """
    Returns break-even utilization and cost comparison at given volume.
    """
    res_price = od_price_per_M * (1 - reserved_discount)
    
    cost_cris_od = monthly_tokens_M * od_price_per_M
    cost_global_cris = monthly_tokens_M * od_price_per_M * 0.90  # ~10% global discount
    
    # Reserved: fixed commitment + overflow at OD rate
    reserved_capacity_M = reserved_min_cost_monthly / res_price
    overflow_M = max(0, monthly_tokens_M - reserved_capacity_M)
    cost_reserved = reserved_min_cost_monthly + overflow_M * od_price_per_M
    
    breakeven_util = 1 - reserved_discount
    
    return {
        "cost_cris_ondemand": round(cost_cris_od, 2),
        "cost_global_cris": round(cost_global_cris, 2),
        "cost_reserved": round(cost_reserved, 2),
        "breakeven_utilization_pct": round(breakeven_util * 100, 1),
        "monthly_savings_reserved_vs_od": round(cost_cris_od - cost_reserved, 2),
        "recommendation": "Reserved" if cost_reserved < cost_global_cris else "Global CRIS"
    }

# Example: Claude Sonnet 4.6, 500M tokens/month, 25% 1-month discount
result = cris_vs_reserved_breakeven(
    monthly_tokens_M=500,
    od_price_per_M=3.00,         # illustrative; check aws.amazon.com/bedrock/pricing/
    reserved_discount=0.25,
    reserved_min_cost_monthly=270  # minimum 100K input TPM × hourly rate × 730 hours
)

10.4 Decision Matrix

Workload Profile	Recommendation
Variable load, unpredictable peaks	CRIS on-demand (geographic or global)
Sustained high volume, >75% utilization, low latency requirements	Reserved tier (single-region)
Batch / async / eval	Flex tier (50% discount; CRIS not applicable)
Latency-critical customer-facing, no reservation	Priority tier + geographic CRIS
Mixed predictable base + spiky peaks	Reserved tier for base load + CRIS overflow (Standard tier; configure overflow in service tier parameter)

11. Multi-Region Active-Active Architecture Using CRIS

11.1 Architecture Pattern: CRIS as the Active-Active Fabric

Geographic CRIS is not a true active-active architecture at the application layer — routing decisions are made by AWS, not by the application. The correct mental model is: CRIS provides capacity-aware routing within a geographic pool, with the application anchored to a single source region.

A genuine multi-region active-active Bedrock architecture combines:

Application-layer region selection: Route API calls to the closest/least-loaded source region based on client geography or health checks
CRIS within each source region: Each source region uses a geographic CRIS profile to burst capacity locally
Cross-region failover: Application-layer failover if one source region is degraded (HTTP 503)

Client (EU)
    │
    ▼
Route 53 Latency Policy
    ├── eu-central-1 (healthy) → CRIS EU profile → eu-central-1 | eu-west-1 | eu-west-2
    └── eu-west-1 (failover)   → CRIS EU profile → eu-west-1 | eu-central-1 | eu-west-2

11.2 Cost Implications of Application-Layer Multi-Region

Each source region in the active-active setup maintains separate:

CRIS quota limits (must be increased separately per source region)
Prompt caches (cache is not shared across source regions)
CloudTrail logs (consolidated in each source region)

For a two-source-region active-active deployment, double the CRIS quota increase request at each source region. Cache cold-start cost is unavoidable when traffic shifts between source regions.

11.3 SCP Configuration for Multi-Account Active-Active

In multi-account Organizations deployments, SCP configuration requires explicit allowance for all destination regions in each geographic profile:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowBedrockEUCRIS",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "eu-central-1", "eu-west-1", "eu-west-2", "eu-west-3",
            "eu-south-2", "eu-central-2", "eu-north-1"
          ]
        }
      }
    }
  ]
}

If any destination region in the EU profile is blocked by SCP, all CRIS requests fail — even if the source region is allowed. This is a common misconfiguration in Control Tower environments. The bedrock:InferenceProfileArn condition key can scope the allowance to specific profiles rather than all Bedrock calls to EU regions.

11.4 Observability for Multi-Region CRIS

CloudWatch metrics are emitted in the source region only. For multi-region active-active, aggregate CloudWatch data across all source regions using CloudWatch cross-account cross-region metric math or Amazon Managed Grafana with multiple data sources.

Key metrics to aggregate per CRIS profile:

InvocationLatency (p50, p99 by ModelId + Region)
InvocationThrottles (count; alarm if non-zero in sustained period)
EstimatedInputTokenCount (for quota headroom monitoring)
OutputTokenCount with burndown multiplier applied

CloudTrail Insights across all source regions will surface unusual CRIS routing patterns (e.g., sudden concentration in one destination region, indicating capacity issues elsewhere in the geographic pool).

Key Takeaways

No CRIS routing surcharge exists. Geographic profiles bill at source-region on-demand rates. Global profiles are ~10% cheaper than geographic. The perceived “CRIS premium” is cache miss inflation from regional cache isolation.
The -cross-region-global suffix in line_item_usage_type is the authoritative CUR signal for global CRIS charges. Geographic CRIS charges appear under standard usage type patterns with no suffix. CloudTrail additionalEventData.inferenceRegion reveals the actual destination.
Global CRIS is currently scoped to Claude Sonnet 4.5/4.6 and Opus 4/4.x. Nova and Llama families are geographic-only. Embedding models and generation models are excluded entirely from inference profiles.
The 5× output token burndown for Claude Sonnet/Opus 4.x models means effective quota consumption is 2–4× the raw token count for typical conversational workloads. Quota sizing must use the burndown formula, not raw token estimates.
CRIS and Reserved tier are incompatible. CRIS routes on-demand; Reserved tier capacity is region-pinned. Organizations with both must explicitly configure source tier on API calls to direct predictable base load to Reserved and route peaks through CRIS Standard tier.
EU geographic CRIS is the GDPR-safe path. All processing stays within the EU regional boundary. Global profiles are inappropriate for EU data residency requirements.
Break-even for Reserved tier vs CRIS on-demand is ~70–85% utilization for 1-month commitments and ~60–70% for 3-month commitments. Below those thresholds, CRIS on-demand (or Global CRIS with 10% discount) is the cost-optimal choice.

1. CRIS Pricing: How the Cost Signal Appears in CUR

1.1 The Canonical Misconception

1.2 CUR 2.0 Line-Item Format

1.3 Key CUR Query Patterns

2. Model Support Matrix: Which Models Support CRIS Profiles (June 2026)

2.1 Anthropic Claude Family

2.2 Amazon Nova Family

2.3 Meta Llama 3.x Family

2.4 Models That Do Not Support CRIS

3. Inference Profile Types: System-Defined vs Application-Defined

3.1 System-Defined (Cross-Region) Inference Profiles

3.2 Application-Defined Inference Profiles

3.3 Combining Both Profile Types

3.4 Control and Cost Tradeoff Summary

4. LiteLLM Integration with CRIS

4.1 Using System-Defined Profile IDs Directly

4.2 Using Application Inference Profile ARNs

4.3 LiteLLM Proxy Config (YAML)

4.4 Known LiteLLM Limitations with CRIS

5. Cost Optimization: When CRIS Saves Money Despite Cache Miss Tax

5.1 Scenarios Where CRIS Wins

5.2 Scenarios Where Single-Region Wins

5.3 Cost Formula: Effective Token Cost with CRIS Cache Miss Tax

6. Latency Implications

6.1 The Latency Stack for On-Demand CRIS

6.2 CRIS Latency vs Single-Region: When It Inverts

6.3 p99 Latency Behavior

6.4 Streaming vs Non-Streaming

6.5 Latency-Optimized Inference + CRIS

7. Data Residency and Compliance

7.1 Profile Types and Data Residency Guarantees

7.2 EU Data Processing Considerations

7.3 Financial Services: SR 26-2 and CRIS

8. CUR Attribution for CRIS: Destination Region Identification

8.1 What CUR Shows vs What CloudTrail Shows

8.2 CloudTrail inferenceRegion Field

8.3 Reconstructing Full Attribution (CUR + CloudTrail Join)

9. Quota Management for CRIS

9.1 Quota Architecture

9.2 Quota Lines in Service Quotas Console

9.3 Output Token Burndown Rate Impact on Quota Sizing

9.4 Monitoring Quota Consumption with CloudWatch

10. Cost Modeling: Break-Even Between CRIS On-Demand and Reserved Tier

10.1 Service Tier Overview

10.2 Break-Even Formula: CRIS On-Demand vs Reserved Tier

10.3 Break-Even Calculator (Python)

10.4 Decision Matrix

11. Multi-Region Active-Active Architecture Using CRIS

11.1 Architecture Pattern: CRIS as the Active-Active Fabric

11.2 Cost Implications of Application-Layer Multi-Region

11.3 SCP Configuration for Multi-Account Active-Active

11.4 Observability for Multi-Region CRIS

Key Takeaways

Source References

8.2 CloudTrail `inferenceRegion` Field