How to Verify Where Claude Processed Your Request with AWS CloudTrail

Picking an EU inference profile is a promise. The CloudTrail log is how you show you kept it.

Every time your application calls Claude on Amazon Bedrock, CloudTrail writes a record in the Region the call came from. For cross-Region calls, that record also says which Region actually did the work. When a DPO or auditor asks where your prompts went, this is what you hand them.

In this post I’ll show where to find that record, how to check where a profile is allowed to send requests, and how to turn both into evidence you can keep. It builds on Can You Use Claude Without Sending Prompts and Responses Outside the EU?

What CloudTrail records

Bedrock logs every API call in the Region you called from. The Region that processed the request doesn’t get its own copy: CloudTrail, CloudWatch and model invocation logging all stay where the call started (AWS Alps blog).

These are the fields worth looking at in each event:

Here’s the relevant part of an event from AWS’s own example, a call to an EU profile made from Zurich:

"eventSource": "bedrock.amazonaws.com",
"eventName": "ConverseStream",
"awsRegion": "eu-central-2",
"requestParameters": {
    "modelId": "arn:aws:bedrock:eu-central-2:012345678901:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0"
},
"additionalEventData": {
    "inferenceRegion": "eu-south-2"
}

The last field is useful when it is present. AWS uses inferenceRegion to show the Region that processed a cross-Region request (AWS ML blog: Getting started with cross-Region inference; AWS: Cross-Region inference). If inferenceRegion is absent, don’t treat that absence as proof that the request stayed in the source Region. Validate the behaviour of the endpoint you use with your own events before relying on it in an audit report.

Check a single call yourself

You can see the whole chain in about five minutes. Bedrock calls show up in CloudTrail Event History for 90 days when you filter on bedrock.amazonaws.com (AWS Alps blog).

1. Make a test call from an EU Region using an EU profile. Here I’m using Frankfurt and Claude Sonnet 5:

   aws bedrock-runtime converse
   --region eu-central-1
   --model-id eu.anthropic.claude-sonnet-5
   --messages '[{"role":"user","content":[{"text":"Hello"}]}]'

2. Look up the event in the same Region. It can take a few minutes to appear.

   aws cloudtrail lookup-events
   --region eu-central-1
   --lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com
   --max-results 5

3. Open the Converse event and check four things: userIdentity is the role you expected, awsRegion is eu-central-1, requestParameters.modelId is the eu. profile, and inferenceRegion, if it’s there, is an EU Region.

4. Save the event JSON with the date on it. That’s your first piece of evidence.

If you use the newer bedrock-mantle endpoint for single-Region inference, repeat the test there. Anthropic confirms that it logs to CloudTrail (Anthropic: Claude in Amazon Bedrock), but look at a real event in your account rather than assuming it matches the example above.

Know where a profile can send requests

CloudTrail tells you where requests went. The inference profile tells you where they’re allowed to go, and that’s worth saving too. Run this from your source Region. Each model ARN in the output is a possible destination (AWS: Supported inference profiles):

aws bedrock get-inference-profile \
  --region eu-central-1 \
  --inference-profile-identifier eu.anthropic.claude-sonnet-5 \
  --query "models[].modelArn"

One thing caught my attention here: the destination list depends on the Region you call from. In AWS’s own example, the EU profile called from Zurich lists six EU Regions plus Zurich itself (AWS Alps blog). Switzerland isn’t in the EU, so an “EU” profile called from Zurich can process requests outside the EU. If your requirement is EU member states only, call from an EU Region and check the list.

The good news for audits is that a geographic profile’s destination list never changes. If AWS adds Regions, it creates a new profile with a new ID (AWS: Supported inference profiles). So one saved output per profile and source Region stays valid.

Turn it into evidence that lasts

One test proves the setup worked on the day you tested it. An auditor will want to know it kept working. This is how I’d set that up.

1. Keep the records longer than 90 days. Create a CloudTrail trail that writes to an S3 bucket in an EU Region, ideally in a separate logging account (AWS Alps blog).

2. Query them. With the trail in S3 and an Athena table on top, one query lists every Claude call processed outside your approved Regions. The query below assumes AWS’s standard CloudTrail table, where requestparameters and additionaleventdata are stored as JSON text. Adjust the names to your setup, and replace the Region list with the destinations your own profile returned.

3. Alert on anything unexpected. Run the query on a schedule and flag two things: any inferenceRegion outside your list, and any call to a global. profile. Better still, block both with IAM and SCPs so the alert never has anything to report.

   SELECT eventtime, useridentity.arn AS principal, awsregion AS source_region, json_extract_scalar(requestparameters, '$.modelId') AS model_or_profile, json_extract_scalar(additionaleventdata, '$.inferenceRegion') AS inference_region FROM cloudtrail_logs WHERE eventsource = 'bedrock.amazonaws.com' AND eventname IN ('InvokeModel', 'InvokeModelWithResponseStream', 'Converse', 'ConverseStream') AND ( json_extract_scalar(additionaleventdata, '$.inferenceRegion') NOT IN ('eu-central-1', 'eu-north-1', 'eu-south-1', 'eu-south-2', 'eu-west-1', 'eu-west-3') OR json_extract_scalar(requestparameters, '$.modelId') LIKE '%global.%' );

A month of empty results is good evidence. Save the query, the date range and the result together.

What CloudTrail won’t tell you

CloudTrail shows where a request was processed. It doesn’t answer every question a DPO will ask.

• It doesn’t contain prompts or responses. It records metadata only. If you need the content, turn on model invocation logging. It’s off by default and writes to CloudWatch Logs or S3 in the source Region (AWS Alps blog). Keep in mind that this creates another copy of sensitive data.
• It doesn’t show abuse-detection storage. AWS notes that prompts and outputs may be stored in opt-in destination Regions for abuse detection (AWS: Supported inference profiles). You won’t see that in CloudTrail. The profile’s destination list is what limits where it can happen.
• It doesn’t cover the rest of your stack. Knowledge bases, S3 buckets, vector stores and your own application logs have their own Regions. Check them separately.

Need evidence your auditor will accept?

At Wolkn Minds, we set up the trail, the queries and the alerts, and put together the evidence pack for your DPO. Book a consultation.

Sources

• Amazon Bedrock: Route model inference requests across AWS Regions with cross-Region inference
• Amazon Bedrock: Supported Regions and models for inference profiles
• AWS Alps blog: Unlocking AI flexibility in Switzerland, cross-Region inference for EU data processing
• AWS ML blog: Getting started with cross-Region inference in Amazon Bedrock
• Anthropic: Claude in Amazon Bedrock