SCPs and Cross-Region Inference: the aws:RequestedRegion Trap

A service control policy (SCP) is an AWS Organizations guardrail: a policy applied to whole accounts or organizational units that caps what identities in those accounts can ever do, regardless of their own IAM permissions. A very common enterprise SCP pattern is region pinning — deny everything unless aws:RequestedRegion is in an approved list, so that no workload can touch, say, ap-southeast-2 by accident.

Bedrock's cross-region inference sits awkwardly with that pattern, because its whole point is routing requests to other regions. Inference profiles come in two flavors: geographic profiles keep processing within a geography (US, EU, APAC), while global profiles may route to any supported commercial region for maximum throughput — with roughly 10% cost savings versus geographic routing. Both interact with region-pinning SCPs, differently.

Trap one: geographic profiles need every destination region allowed

AWS documents the requirement plainly: for geographic cross-region profiles, all destination regions the profile can route to must be allowed in your SCPs. If your region allowlist contains us-east-1 only, a US geographic profile that can route to other US regions will fail whenever routing selects a region outside your list.

Two extra wrinkles make this worse than it sounds:

Cross-region inference can route to regions not manually enabled in your account — so "we never opted into that region" is not protection, and your SCP may be the only thing that fires.
The destination set belongs to the system-defined profile, not to you, so the fix is to look up the profile's current destination regions and mirror them into the SCP allowlist — then keep that list maintained.

The data-path worry behind region pinning is at least partially addressed by AWS's own statements: all cross-region traffic stays on the AWS network (never the public internet) and is encrypted in transit between regions, and pricing follows the region you call the profile from, with no extra routing charge. Whether that satisfies a data-residency requirement is a question for your compliance team — you inherit your cloud provider's posture, so confirm specifics with AWS.

Trap two: global profiles don't send a region at all

Here is the counterintuitive part. When a request goes through a global inference profile, the region evaluation doesn't resolve to some long list of regions — AWS documents that global profiles require "aws:RequestedRegion": "unspecified" to be allowed in your SCPs. The literal string unspecified stands in for "routing will be decided dynamically."

For a region-pinned organization this cuts both ways:

If your SCP denies everything outside an explicit region list, global-profile calls fail — because unspecified is not on the list. To permit global routing, add unspecified as an allowed value.
Conversely, if someone adds unspecified to make a workload function, they have effectively exempted global Bedrock inference from region pinning for every account under that SCP. Treat that value as a deliberate governance decision, not a quick fix.

Blocking global routing outright

If your policy is "geographic routing is fine, global is not," AWS documents the explicit-deny pattern: deny the inference actions whenever the requested region is unspecified. An explicit Deny wins over any Allow anywhere in the evaluation, so this is robust even if some team later adds a permissive allow:

{
  "Effect": "Deny",
  "Action": "bedrock:InvokeModel*",
  "Resource": "*",
  "Condition": {
    "StringEquals": { "aws:RequestedRegion": "unspecified" }
  }
}

Note the wildcard bedrock:InvokeModel*, which covers both InvokeModel and InvokeModelWithResponseStream; denying InvokeModel also automatically blocks Converse and StartAsyncInvoke per AWS's policy-examples documentation.

Rule of thumb: geographic profile → allowlist every destination region in the geography. Global profile → allowlist the literal value unspecified, knowingly. Want to forbid global routing → explicit Deny on bedrock:InvokeModel* with aws:RequestedRegion = "unspecified".

Trust, but verify where it ran

SCPs shape where requests may go; CloudTrail tells you where they did go. Every cross-region request is logged in the source region with an additionalEventData.inferenceRegion field naming the actual processing region — the subject of the companion auditing article. The identity-policy side of the same routing model (the dual-ARN requirement) is covered in the inference-profile IAM article.

Where to go next

See regions and availability for how Claude's regional footprint differs across platforms, and the least-privilege guide for layering SCPs with identity policies.

Sources

← All articles