Auditing Where Cross-Region Bedrock Inference Actually Ran

When you invoke Claude on Amazon Bedrock through a cross-region inference profile, the region that serves the request is chosen dynamically — within a geography for geographic profiles, or across any supported commercial region for global profiles. That flexibility is the feature. But it creates an evidence question for security and compliance teams: after the fact, how do you know where a given request was actually processed?

The answer lives in AWS CloudTrail, the service that records API activity in your account — who called what, when, and from where.

Logs land in the source region, always

The first thing to internalize: AWS documents that all cross-region requests are logged in CloudTrail in the source region — the region from which you called the inference profile. Nothing appears in the destination region's trail, even though the model ran there.

This is good news operationally. You don't need to aggregate trails from every region a profile might route to, and you don't need CloudTrail enabled in regions you never deliberately use (remember, cross-region inference can route to regions not manually enabled in your account). Your existing trail in the calling region sees everything. The flip side: anyone hunting for evidence in the destination region's logs will find nothing and may wrongly conclude the routing never happened.

The field that answers the question: additionalEventData.inferenceRegion

Inside the CloudTrail record for a cross-region invocation, the additionalEventData.inferenceRegion field identifies the region where the request was actually processed. The record's normal region attribute reflects the source region (where you called from); inferenceRegion reflects where routing sent it. Comparing the two tells you whether a request stayed local or was routed away.

A trimmed sketch of what to look for in an event record:

{
  "eventName": "InvokeModel",
  "awsRegion": "us-east-1",
  "additionalEventData": {
    "inferenceRegion": "us-west-2"
  }
}

To turn that into routine audit evidence, query your trail (for example via your log-analytics tooling of choice) for inference events, group by additionalEventData.inferenceRegion, and you have a distribution of where your Claude traffic actually executed over any period — useful both for residency reviews and for spotting surprises, such as a geographic profile routing more heavily to a region your team didn't expect.

What CloudTrail does and doesn't capture here

Some scoping details from AWS's CloudTrail documentation for Bedrock are worth knowing before you promise auditors anything:

• Inference calls are management events. InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream are logged as CloudTrail management events, which are logged by default — no advanced event selectors needed for this use case.
• No prompt or completion content. AWS's example InvokeModel entry shows requestParameters containing only the modelId, with responseElements: null. CloudTrail proves who invoked which model and where it ran — it is not a record of what was said. For content capture, that's Bedrock's separate model invocation logging feature (see the invocation logging article).
• Identity and origin are included. Records carry the caller identity, source IP, and timing, which is usually exactly what an access review needs alongside the region evidence.
• Surface matters. That documentation covers the bedrock-runtime.{region}.amazonaws.com endpoint; calls to the newer bedrock-mantle.{region}.api.aws Messages-API surface have their own separate CloudTrail documentation page. If you use both surfaces, audit both — see the mantle CloudTrail article.

How this pairs with preventive controls

CloudTrail is detective — it tells you what happened. The preventive twin is your SCP layer, which determines which destination regions are even permitted, including the special unspecified value global profiles use; that's covered in the SCP article. A sound setup uses both: SCPs constrain routing in advance, and a periodic CloudTrail query over inferenceRegion confirms the constraint held in practice. As extra context for reviewers: AWS states cross-region traffic stays on the AWS network and is encrypted in transit between regions.

Where to go next

For the full observability picture on Bedrock — invocation logs, CloudWatch metrics, and log schemas — start with the audit logging overview.

Sources

• Amazon Bedrock — Cross-region inference
• Amazon Bedrock — Logging with AWS CloudTrail