AWSAWS Certified Generative AI Developer - Professional2026-101.2 Select and configure FMs
Choose inference routes within processing boundaries
Completed by the knowledge check
Learning objective
Compare Bedrock cross-Region inference with regional model deployment for availability, residency, and processing-location constraints. Choose the routing envelope before treating more available capacity as a benefit.
Core idea
Building on the deployment choices in 1.1.3, distinguish the Region receiving an API request from the Region processing model inference. Amazon Bedrock cross-Region inference uses an inference profile to route requests for a specified model across supported Regions. It expands the capacity pool, but the source Region alone does not establish the processing boundary.
Compare three envelopes: an in-Region path, a geographic profile constrained to a geography, and a global profile using supported commercial Regions worldwide. Start with the locations your workload permits. Then choose the capacity and availability mechanism that fits inside that set.
How it works
Identify source and destination separately
For supported Bedrock runtime operations, pass an inference profile ID or ARN as modelId instead of the individual foundation-model identifier. The profile defines the model and destination Regions. Bedrock performs the cross-Region routing; the application does not need to select a destination for each call.
Use GetInferenceProfile to inspect the profile’s model resources, including their model ARNs, and record the result with the source Region. Consult the supported-profile documentation for that source because the usable path depends on both the model and where the call originates. Do not infer the profile’s scope from an abbreviated name alone.
An in-Region model invocation or a model you deploy on a regional SageMaker AI endpoint gives you a different control boundary. You select the regional resource rather than asking a Bedrock profile to choose compute elsewhere. Confirm the selected model’s documented inference path; a model listed in a Region might still require a cross-Region profile for the mode you intend to use.
Choose geographic or global scope
A geographic cross-Region profile keeps inference processing within a specified geography such as the US, EU, or APAC. That is broader than a single Region. If a policy permits processing in an approved geography, it can be compatible with this path. If the policy names one specific Region, a geographic profile does not satisfy that requirement merely because its API endpoint is there.
A global profile routes to supported commercial AWS Regions worldwide. Use it only when the permitted processing set allows that scope. A global profile’s capacity or price advantage cannot relax the workload’s location rule. Treat this as a hard eligibility gate, as in 1.2.1.
Storage and processing also require separate review. The geographic-inference documentation says prompts and outputs can move beyond the source Region and notes destination-Region storage for models whose abuse-detection behavior requires it. Therefore, do not generalize a source-Region storage statement into a promise that every copy of every model input remains there. Read the selected model’s applicable data-handling terms; see 2.3.8 for verifying actual processing and storage locations.
Authorize the complete route
Geographic cross-Region inference requires authorization for the inference profile, the foundation model in the source Region, and the foundation model in candidate destination Regions. An IAM grant limited to the local model resource is not a complete grant for that path.
Service control policies (SCPs) can also restrict the route. AWS documents two geographic approaches: permit all destination Regions, or use an inference-profile exception. The bedrock:InferenceProfileArn condition key can narrow a Region-deny exception for destination model-resource evaluations. It does not bypass the source-Region restriction on the originating profile call, where that condition key is not populated.
Global cross-Region inference has its own authorization pattern, including the documented aws:RequestedRegion value unspecified for the global routing evaluation. Review that policy explicitly rather than copying a geographic policy and replacing the profile ID. A broader routing scope deserves a correspondingly explicit authorization review.
Measure the chosen envelope
Cross-Region inference is a capacity-routing mechanism for the chosen model, not application fallback to a different model. It can help absorb regional capacity pressure without changing model identity. It does not restore an unavailable application API, replicate your retrieval data, or approve another provider; those are separate recovery concerns.
Use the source Region’s applicable cross-Region quota. AWS distinguishes geographic and global cross-Region request and token quotas from other inference quotas. Check the appropriate Service Quotas entries before interpreting a load test. Cross-Region profiles do not support Provisioned Throughput, so purchasing Provisioned Throughput is a separate capacity decision.
For audit evidence, Bedrock documents CloudTrail’s additionalEventData.inferenceRegion field to identify the processing Region of a cross-Region request. Compare observed processing locations with the approved profile scope. Observation is useful evidence of execution, while the profile and authorization policy define which routes are permitted.
The following comparison captures the architectural boundary:
| Path | Location control | Capacity responsibility |
|---|---|---|
| In-Region inference resource | Selected regional resource | Plan capacity for that regional path |
| Geographic inference profile | Supported destinations inside its geography | Bedrock routes across the profile’s capacity pool |
| Global inference profile | Supported commercial Regions worldwide | Bedrock routes across a broader pool |
Key distinctions and trade-offs
API location versus processing location: The source endpoint identifies where the application sends the call. An inference profile can process it elsewhere.
Geographic residency versus single-Region residency: A geographic boundary is a set of locations. It cannot satisfy a narrower requirement without evidence that every possible destination is allowed.
Cross-Region inference versus disaster recovery: Model capacity routing is one dependency’s mechanism. Recovering the application and its assets requires other controls; see 1.2.10 and 1.2.11.
An in-Region design gives narrower location control but fewer capacity options. Geographic routing can offer more headroom inside an approved boundary. Global routing offers the broadest location envelope and requires accepting that envelope in the workload policy.
Architecture / decision scenario
A document assistant runs in an EU Region. Its owner proposes a global inference profile to reduce throttling. Legal review permits processing within an approved EU geography but prohibits worldwide processing.
You reject the global route and inspect a supported EU geographic profile with GetInferenceProfile. The security team authorizes the profile and destination model resources, with a scoped SCP exception where necessary. The load test uses the geographic cross-Region quotas rather than assuming regional capacity carries over.
CloudTrail evidence records the actual inference Regions. A second workflow with a strict single-Region condition stays on an eligible regional deployment. The two workflows share application code but deliberately use different approved routing envelopes.
Common exam traps
- Assuming the source API Region is always the processing Region.
- Treating geographic routing as a single-Region guarantee.
- Selecting a global profile under a geography-limited processing policy.
- Granting access only to the source foundation-model resource.
- Assuming an SCP destination exception overrides source restrictions.
- Combining an inference profile with Provisioned Throughput as one capacity mode.
What to remember
- Inspect the profile’s destinations and record the source Region.
- Choose location eligibility before capacity or price optimization.
- Authorize the profile and required model resources across its route.
- Use the appropriate cross-Region quotas and CloudTrail processing evidence.
- Keep model routing separate from application and data recovery.
Knowledge check
An application calls Amazon Bedrock from an EU Region under a policy that permits processing anywhere in an approved EU geography but nowhere else. The owner proposes a global inference profile to reduce throttling. Which route respects the policy?
A role can invoke a geographic inference profile and the foundation model in the source Region, yet routed requests are denied. What does the IAM policy still need?
An SCP denies every Region except the source Region. Requests through an EU geographic profile fail whenever Bedrock routes them elsewhere. Which change lets the profile work while other services stay restricted?
bedrock:InferenceProfileArnCross-Region inference gives the model more capacity headroom. Later, the regional application API and its retrieval store fail. Which recovery claim is valid?
Compliance asks for evidence of where cross-Region requests were actually processed. Which evidence supplies it?
inferenceRegion values checked against the profile scopeadditionalEventData.inferenceRegion records the processing Region, which can differ from the source Region under a profile. A profile’s scope is confirmed from its definition, not inferred from an abbreviated name.