Amazon Bedrock Cross-Region Inference (CRIS): Geographic vs Global Routing for Production

Amazon Bedrock cross‑Region inference (CRIS): Geographic vs Global routing — secure patterns for production

TL;DR

  • Amazon Bedrock cross‑Region inference (CRIS) boosts inference throughput and resilience by routing requests from a source AWS Region to destination Regions over the AWS Global Network with end‑to‑end encryption.
  • Geographic CRIS confines routing to a defined geography (US, EU, AU, JP) and requires explicit region‑specific IAM allowances; Global CRIS routes across commercial Regions and uses the "aws:RequestedRegion": "unspecified" condition.
  • CRIS does not change where your data is stored — processing may run in other Regions, but storage (logs, knowledge bases, configs) remains in the source Region.
  • Turn CRIS on in staging first: apply least‑privilege IAM, update Service Control Policies (SCPs) centrally (AWS Control Tower where applicable), and validate CloudTrail signals and latency/cost metrics before production rollout.

Why cross‑Region inference matters for business

AI for business is shifting from experimentation to production. For generative AI services, inference at scale can hit single‑Region capacity limits and create brittle availability. CRIS provides two operational levers: increase throughput by distributing inference requests, and improve resilience by failing over to other Regions when local capacity or availability is constrained. That means fewer throttles, higher sustained request rates during spikes, and a better user experience for customer‑facing automation.

Geographic CRIS vs Global CRIS — side‑by‑side

Choose the routing mode based on compliance posture and throughput needs:

  • Geographic CRIS — Routes only within a defined geography (for example, US or EU). Use when you need to keep processing inside a legal boundary. You enumerate destination Regions in the inference profile and grant explicit permissions per Region.
  • Global CRIS — Routes across supported commercial AWS Regions worldwide for maximum capacity and resilience. Useful when you accept processing in any commercial Region that meets your compliance requirements. Global CRIS relies on a dynamic region marker ("aws:RequestedRegion": "unspecified").

Core security facts to anchor decisions

“CRIS does not change where data is stored—none of the customer data is stored in any destination Region when using cross-Region inference.”

“All cross-Region calls are logged in the source Region.”

Those two points are essential: persisted storage stays in the source Region, and auditing occurs at the request origin. However, processing location can still carry regulatory and contractual implications even when storage doesn’t move.

IAM and Service Control Policy (SCP) implications

CRIS requires intentional permissioning. Treat inference permissions like any other powerful lateral capability — scope them tightly.

Geographic CRIS: explicit, least‑privilege permissions

For a geographic inference profile, list each destination Region and grant bedrock:InvokeModel on the foundation model and inference profile ARNs in those Regions. Example guidance:

  • Reference foundation model ARNs that exist in each destination Region.
  • Limit principals (roles/users) to only the inference profiles they need.
  • Audit and rotate roles that can invoke geographic profiles.

Example (conceptual) elements to include in an IAM statement:

  • "Action": "bedrock:InvokeModel"
  • "Resource": ["arn:aws:bedrock:us-east-1::model/...", "arn:aws:bedrock:us-east-2::model/..."]
  • "Condition": { "StringEquals": { "aws:Region": ["us-east-1", "us-east-2"] } } — for clarity and extra guardrails

Global CRIS: support for dynamic routing

Global CRIS requests use the special condition value "aws:RequestedRegion": "unspecified". If your organization denies Regions in SCPs by enumerating allowed or denied Regions, ensure Bedrock actions are not blocked when the requested region is unspecified.

“Ensure that ‘aws:RequestedRegion’: ‘unspecified’ is not included in the deny Regions list because Global CRIS requests use this Region value.”

Practically, this means:

  • Avoid blanket SCP denies that match Bedrock actions with a region condition that will catch the unspecified value.
  • If you must block Global CRIS, apply an explicit SCP deny for Bedrock actions (organization‑level) rather than blocking unspecified region values that could inadvertently break legitimate dynamic routing.

Auditing and observability (CloudTrail and telemetry)

Visibility is non‑negotiable. CloudTrail records cross‑Region Bedrock API calls in the source Region and includes additional metadata that helps you confirm where inference ran.

Key CloudTrail fields to search for when auditing CRIS activity:

  • eventTime — timestamp of the call
  • userIdentity — principal that invoked the inference profile
  • eventName — typically InvokeModel or similar
  • additionalEventData.inferenceRegion — destination Region used (e.g., ap-southeast-4)
  • requestParameters / responseElements — context about the model and profile invoked

Beyond CloudTrail, instrument runtime metrics and traces to measure:

  • p95/p99 inference latency
  • throughput and per‑Region distribution of inferenceRegion
  • error rates and throttling counts
  • cost per inference and sudden cost spikes

Compliance, contracts, and legal considerations

Storage location doesn’t always settle regulatory questions. Regulators or contracts may treat where processing occurs differently than where storage resides. Before enabling Global CRIS:

  • Review regulator guidance and legal contracts for data processing location restrictions.
  • Confirm third‑party model provider terms (Anthropic, etc.) for any restrictions on where inference may run.
  • Document approvals and risk decisions for processing in any commercial Region.

Practical enablement checklist (quick, copyable)

  1. Decide routing mode: Geographic CRIS (region boundaries) or Global CRIS (dynamic routing).
  2. Create the inference profile listing desired destination Regions (for Geographic) or configure for Global routing.
  3. Update IAM roles with minimal bedrock:InvokeModel permissions scoped to model/profile ARNs and regions (Geographic).
  4. If using Global CRIS, ensure SCPs do not deny the "aws:RequestedRegion": "unspecified" value for Bedrock actions.
  5. Update organization SCPs via AWS Control Tower customization (CfCT) where Control Tower manages policies to avoid drift.
  6. Enable CloudTrail (source Region) and validate additionalEventData.inferenceRegion appears in logs.
  7. Run a staging load test: verify p95 latency, error rates, and that CloudTrail shows expected inferenceRegion entries.
  8. Set alerts: unusual Region distribution (>10% outside preferred Regions), latency spikes, or cost anomalies.
  9. Roll out to production with a rollback SCP or policy ready to disable CRIS quickly if needed.

Staging test plan and runbook

Make tests repeatable and measurable:

  1. Enable CRIS for a non‑critical inference profile in staging.
  2. Push a controlled load (example: 10k requests over 10 minutes) and record p50/p95/p99 latency.
  3. Confirm CloudTrail events show additionalEventData.inferenceRegion values and correlate them to latency results.
  4. Simulate capacity strain in the source Region (if possible) and confirm failover behavior to destination Regions.
  5. Test the org‑level deny path: apply an SCP deny for Bedrock and verify CRIS calls are blocked and logged.
  6. Rollback: restore original SCP and IAM policies, verify normal operation, and document timelines and evidences.

Top risks and mitigations

  • Regulatory ambiguity: If regulators consider processing location important, keep routing geographic‑constrained or obtain legal sign‑off. Mitigation: use Geographic CRIS and audit evidence.
  • Unexpected region routing: Dynamic routing may place processing in a Region you didn’t expect. Mitigation: monitor CloudTrail inferenceRegion and alert on non‑preferred Regions.
  • Cost or latency spikes: Cross‑Region routing can increase per‑request cost and round‑trip latency if destinations are far. Mitigation: define latency thresholds and cost alarms; prefer geographically proximate destination Regions.

FAQs — key operational questions

  • What practical benefits does CRIS deliver?

    It increases inference throughput and resilience by routing requests across Regions over the AWS Global Network with encryption in transit, reducing single‑Region bottlenecks and improving availability for production AI automation.

  • Does CRIS move my stored data to other Regions?

    No. Customer‑managed logs, knowledge bases, and stored configurations remain in the source Region; CRIS does not change storage location.

  • How should IAM and SCPs be configured for Geographic vs Global CRIS?

    Geographic CRIS needs explicit destination Regions and bedrock:InvokeModel permissions on region‑specific ARNs. Global CRIS uses "aws:RequestedRegion": "unspecified", so SCPs that deny Regions must not include that unspecified value for Bedrock actions unless you intend to block Global CRIS.

  • How do I audit cross‑Region inference?

    CloudTrail logs show cross‑Region invocations in the source Region and include additionalEventData.inferenceRegion, enabling source‑side auditing. Complement CloudTrail with latency and cost telemetry.

  • Can I block CRIS across my organization?

    Yes. Apply SCP deny statements at the organization level to block Bedrock CRIS functionality. If you use AWS Control Tower, apply SCP changes through Control Tower customization (CfCT) to avoid policy drift.

Decision framework for executives and platform owners

  • Enable CRIS when: your application needs higher sustained throughput, you accept that processing may occur in multiple commercial Regions, and you have compliance approval and telemetry readiness.
  • Avoid or limit CRIS when: contracts or regulators require strict processing location controls, or when latency/cost constraints make cross‑Region routing impractical.
  • Safe rollout pattern: pilot in staging (Geographic CRIS if compliance‑sensitive), validate metrics and logs, then expand to production with automated detection and a fast rollback path (SCP deny ready).

What remains worth watching

  • Operational SLAs for CRIS routing and failover behavior as usage scales.
  • Model provider contract language that addresses where inference can run.
  • How sovereign or edge Regions with strict residency requirements will be handled in future CRIS updates.

Guidance authored by AWS Bedrock and security specialists: Zohreh Norouzi, Satveer Khurpa, Melanie Li, Saurabh Trikande, Jan Catarata, and Harlan Verthein.

Recommended next steps

  1. Classify workloads by compliance sensitivity and choose Geographic or Global CRIS accordingly.
  2. Prepare IAM and SCP changes in a staging account and validate CloudTrail inferenceRegion visibility.
  3. Run a controlled load test, confirm latency and cost expectations, then deploy with monitoring and an SCP‑based rollback plan.
0