AWS Claude Code London Requires Bedrock Profiles and IAM Deny

The August 6 AWS Machine Learning Blog post separates Claude Code on Bedrock into two paths. The newer

endpoint can use native single-Region routing in seven Regions. London is excluded, so AWS directs

users to the older

Invoke API, an application inference profile, and Claude Opus 4.6 or Claude Sonnet 4.6. AWS’s current model cards corroborate the key limitation: Opus 4.6 and Sonnet 4.6 are available for in-Region inference in London, while newer Claude families have different regional routing options.

That is useful guidance for platform teams. But two implementation details in the post need stronger treatment before anyone describes the resulting deployment as an enforced, audit-ready residency boundary: an IAM Allow condition does not automatically block permissions granted elsewhere, and classic Bedrock invocation logs are already CloudTrail management events.

London forces the older Bedrock route​

AWS’s distinction between geographical and single-Region residency is real and important. An EU cross-Region inference profile may satisfy a policy that permits processing anywhere within an approved European geography. It does not satisfy a policy requiring processing specifically in

, because the EU profile can route a request to other eligible European Regions.

For the London case, AWS says Mantle offers EU and Global choices rather than an in-Region endpoint. The published solution is therefore to set

, point

to

, create one application inference profile for Claude Opus 4.6 and another for Claude Sonnet 4.6, then use those profile ARNs as Claude Code’s model aliases.

The mechanism is sound. AWS documents that an application inference profile can be created from a specific foundation-model ARN in one Region, and that profile ARN can then be supplied in an

or

request. In the London deployment, the profile is tied to the London ARN for

or

; it is not based on AWS’s

or

system-defined cross-Region profile.

The practical consequence is a trade-off that AWS’s post acknowledges but should be treated as a product constraint, not deployment trivia. A company requiring London-only Claude Code does not get to select the newest available Claude model merely because it is available somewhere on Bedrock. It is anchored to the models that have both the required model capability and in-Region availability there. As of August 7, 2026, AWS’s model cards show London in-Region support for the 4.6 models used in the post, while Claude Sonnet 5’s regional table does not list London as an in-Region option.

That is the governance cost of exact regional residency: model upgrades become a compliance review item. A team that changes

from a London application profile to an EU or Global profile has changed where requests may be processed, even if the developer’s local

setting remains London.

Mantle simplifies routing, but only where AWS offers it​

For Ireland, Stockholm, Tokyo, Melbourne, US East (N. Virginia), US East (Ohio), and US West (Oregon), AWS presents Mantle as the cleaner route. Claude Code version 2.1.94 or later can be configured with

, an

value, and native Anthropic-style model IDs such as

.

Unlike the classic Bedrock route, Mantle does not require an application inference profile for its single-Region routing. AWS’s separate Mantle CloudTrail documentation confirms that the service uses different APIs and logging semantics from

: inference is recorded as

under

, rather than as

under

.

The endpoint split has a less obvious management implication. Application inference profiles are model-specific Bedrock Runtime resources, so a classic deployment can grant access to named profiles and their backing foundation models. Mantle’s authorization model is organized around projects rather than individual model ARNs. AWS’s post correctly notes that a Mantle IAM policy can constrain the Region but does not, by itself, produce the same model-by-model allow list.

For teams using Mantle, model approval therefore cannot be reduced to a developer shell variable. The model alias variables still need centralized configuration, and the approved-model control needs to live in a higher-order guardrail where required, such as an AWS Organizations service control policy. Otherwise, developers may remain free to change a local model selection even though their inference request is kept in the correct Region.

An IAM Region condition is an allow-list, not necessarily a guardrail​

AWS’s example policies permit only the relevant Bedrock or Mantle actions when

equals the designated Region. The post says this condition “rejects” calls made against another endpoint. That statement is only true if the shown policy is the principal’s complete effective permission set for those actions.

IAM does not evaluate one policy in isolation. AWS’s IAM documentation is explicit: permissions from applicable identity- and resource-based policies are combined, and an explicit deny overrides an allow. A conditional Allow for

creates an implicit deny outside that Region only when no other attached policy, permission set, session policy, or resource-based permission allows the same action elsewhere.

This is not an academic edge case in an enterprise rollout. Developers commonly assume broad roles through IAM Identity Center, inherit permissions from group-managed policies, or receive temporary entitlements for testing. If one of those policies grants

on a broader resource set, the narrow London Allow in AWS’s sample does not cancel it. The principal can still have an effective allow outside London.

A deployment can still use the AWS sample as its least-privilege permission grant, but it should pair it with a genuine restriction appropriate to the organization’s control plane:

• A scoped explicit Deny for the Claude Code Bedrock actions whenever aws:RequestedRegion is not the approved Region prevents a separate allow policy from reopening another Region.
• A permissions boundary can cap what developer roles are capable of receiving, even if teams later attach broader policies.
• An AWS Organizations SCP is the stronger central option where the requirement applies across accounts and role designs.

The deny must be carefully scoped. An organization should not indiscriminately deny every AWS service outside London simply to constrain Claude Code, because several AWS services use global endpoints and a broad Region deny can break routine IAM, Organizations, support, or deployment workflows. The target should be the specific Bedrock Runtime and/or Mantle actions used by Claude Code, unless the organization is intentionally applying a wider regional control program.

There is another reason to preserve the profile ARN restriction in the classic route. AWS’s own inference-profile permission guidance recommends allowing the profile and the associated foundation model, and using the

condition when the objective is to require use of a particular inference profile. That condition prevents a future direct invocation path from bypassing the profile configuration if AWS changes model throughput or invocation behavior.

A Region-scoped Allow policy is useful least privilege; an explicit Deny, boundary, or SCP is what turns it into a durable residency control.

CloudTrail verification needs two different runbooks​

AWS is correct that evidence must come from CloudTrail, and that Mantle and classic Bedrock should not be searched the same way. The post’s classic-path troubleshooting advice, however, conflicts with AWS’s CloudTrail documentation.

The blog says that if

events do not appear in CloudTrail Event history, an administrator may need to enable Amazon Bedrock data events. AWS’s CloudTrail documentation says

,

,

, and

on

are management events. CloudTrail records management events by default, and AWS specifically distinguishes them from operations that require optional data-event logging.

For a classic London deployment, an absent

event is therefore not normally evidence that Bedrock data-event capture is disabled. Administrators should first check the CloudTrail Event history time window, the Region selected in the console or CLI, the identity that made the call, the API actually used, and whether Claude Code was routed to Mantle instead of the classic Runtime endpoint. Enabling data events may add cost without solving the missing-event problem.

Mantle is different. AWS’s Mantle CloudTrail guide confirms that

is a data event, that data events are not recorded by default, and that they incur CloudTrail charges. A Mantle rollout requiring auditable residency needs an explicit advanced event selector for the relevant

resource types, plus retention and query access designed into the logging architecture.

CloudTrail’s

field is necessary evidence, but it should not be the entire proof package. AWS’s IAM documentation warns that

controls the endpoint invoked rather than every possible operational impact of an API call. In this Bedrock design, the stronger evidence is the combination of the CloudTrail Region, the profile or model identifier in the recorded request, the current model-card availability table, and the effective IAM or SCP policy that prevents an alternate route.

The deployment standard should be “deny, invoke, inspect”​

The AWS post gives teams a credible starting architecture: Mantle for its seven named in-Region locations, or Bedrock Runtime application inference profiles for London. It also exposes a limitation that many “regional” AI deployments obscure: regional endpoint selection and actual inference routing are separate decisions.

Before approving Claude Code for regulated repositories, administrators should run a controlled negative test. Attempt an invocation from an unauthorized Region using the same assumed developer role, confirm an explicit

result, then inspect CloudTrail to verify that valid calls contain the expected Region and expected application profile or model ID. Repeat that test after changes to IAM Identity Center permission sets, role policies, SCPs, Claude Code settings, or model aliases.

For London, the immediate operational consequence is straightforward: build the two application inference profiles around Claude Opus 4.6 and Sonnet 4.6, enforce the

boundary with a control that cannot be overridden by an additional allow, and validate

management events before enabling optional CloudTrail data-event logging.

References​

1. Primary source: Amazon Web Services (AWS)
   Published: August 6, 2026 at 4:21 PM UTC
   
   

   Enforcing data residency with single-Region Claude Code on Amazon Bedrock | Artificial Intelligence

   A regulated customer needed all Claude Code inference processed in a single AWS Region (London), not just in-geography. This post shows two ways to pin Claude Code on Amazon Bedrock to one Region: an application inference profile or the Mantle endpoint, paired with an IAM Region condition, plus...

   aws.amazon.com
2. Related coverage: docs.aws.amazon.com
   
   

   Application inference profiles - Amazon Bedrock

   Learn how to use application inference profiles to attribute Amazon Bedrock costs by application, team, or workload.

   docs.aws.amazon.com
3. Related coverage: docs.aws.amazon.com
   
   

   Create an application inference profile - Amazon Bedrock

   Learn how to create an application inference profile.

   docs.aws.amazon.com