A Service Control Policy (SCP) is an AWS Organizations feature: a policy attached to accounts or organizational units that sets the outer boundary of permissions. No identity inside a member account can exceed it, regardless of how generous its own IAM policies are. For Bedrock governance, that makes SCPs the right place for rules like "only approved Claude models," "only these regions," and "no model access in sandbox accounts" — rules that must hold even if a team's own administrator writes themselves bedrock:*.
Deny the right action: invocation, not subscription
The most common SCP mistake with Bedrock is blocking the wrong thing. Because Bedrock auto-initiates the AWS Marketplace subscription on first model use, AWS documents explicitly that denying aws-marketplace:Subscribe alone does not block a first invocation, and that deleting a model agreement doesn't stick either — invoking the model re-creates it. The reliable control is denying the inference actions themselves: bedrock:InvokeModel at the SCP or IAM level.
When writing the deny, cover the whole action surface. AWS notes that Converse and StartAsyncInvoke are blocked automatically when InvokeModel is denied, but recommends the bedrock:InvokeModel* wildcard — or explicitly adding bedrock:Converse and bedrock:ConverseStream — when the intent is "no inference at all." And since the newer "Claude in Amazon Bedrock" surface uses a separate action namespace (bedrock-mantle:CreateInference), an organization that wants to gate both Bedrock surfaces must address both namespaces in its SCPs.
Pinning approved models
To allow only vetted Claude versions, deny invocation on everything except an approved list, using the foundation-model ARN pattern arn:aws:bedrock:*::foundation-model/{model-id}. A sketch:
{
"Effect": "Deny",
"Action": ["bedrock:InvokeModel*"],
"NotResource": [
"arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-5",
"arn:aws:bedrock:*::foundation-model/anthropic.claude-opus-4-8",
"arn:aws:bedrock:*:*:inference-profile/*"
]
}
The inference-profile line is easy to forget: invocation through cross-region inference profiles is authorized against profile ARNs as well as foundation-model ARNs, so an SCP that only lists model ARNs will break profile-based traffic. You can additionally constrain which models accounts may enable in the first place by restricting aws-marketplace:Subscribe with the aws-marketplace:ProductId condition key — a useful belt-and-suspenders control, just not a substitute for the invocation deny.
Region restrictions and the cross-region trap
Many organizations already run a region-pinning SCP using aws:RequestedRegion. Bedrock's routing features interact with it in documented ways: geographic inference profiles need all destination regions of the geography allowed, and global profiles require "aws:RequestedRegion": "unspecified" to be permitted. If your SCP allows only us-east-1 and eu-west-1, US-geography routing and global endpoints will fail in ways that look like capacity errors. Decide deliberately: residency-driven organizations typically allow a geography's full region set and forbid global routing; throughput-driven ones allow "unspecified."
Also plan for change: Claude model versions turn over, and an SCP allow-list written around today's IDs will need an update when your organization approves a successor model. Treat the SCP as versioned configuration — reviewed alongside model-upgrade decisions — rather than a set-and-forget artifact, and keep the approved-model list documented where application teams can see it.
What SCPs can't do
SCPs are guardrails, not monitoring, and they only bind accounts in your organization. Pair them with CloudTrail (Bedrock invocations are logged as management events by default, and cross-region calls record the serving region in additionalEventData.inferenceRegion) so you can verify the rules are holding. Content-level controls — what prompts and outputs are acceptable — are a different layer entirely; that's Amazon Bedrock Guardrails, not IAM.
Where to go next
See multi-account Bedrock setup for where SCPs sit in the overall design, and Bedrock IAM condition keys for the finer-grained controls inside each account.