Claude Platform on AWS is Anthropic's own service running inside AWS, and it plugs into AWS audit tooling the way native services do: every API request can land in AWS CloudTrail. The catch is that CloudTrail splits activity into two classes with very different defaults, and the split for this service puts the highest-volume, most audit-relevant traffic — model inference — on the side that is off until you pay to turn it on.
Two event classes, two defaults
CloudTrail distinguishes Management events (control-plane operations — creating, configuring, and listing resources) from Data events (high-volume operations on the data inside those resources). Management events are logged by default on a standard trail; Data events must be explicitly enabled per trail and are billed separately by AWS.
For Claude Platform on AWS, the documented split is:
| Event class | Operations | Logging |
|---|---|---|
| Management events | Workspace, vault, and webhook actions | On by default |
| Data events | Inference, batch, model, file, skill, user profile, and remaining Managed Agents actions | Explicit opt-in, extra CloudTrail charges |
The reasoning behind the management-side list is worth noting: vaults and webhooks hold secrets, so the operations that touch them are classed as Management events precisely to get default-on logging. Day-to-day workload traffic — every CreateInference call, every batch submission, every file upload — is a Data event.
Enabling Data events — and budgeting for them
Data event logging is configured on the trail itself (in the CloudTrail console or via advanced event selectors), scoped to the event sources you want. Two things to plan for:
Cost. AWS charges for Data events delivered to a trail, and inference is exactly the kind of high-frequency traffic that makes those charges material. Many teams enable Data events on production workspaces where audit requirements demand it, and leave sandbox workspaces on Management-only logging. Because every request is bound to a workspace and workspaces are the platform's primary IAM resource, that per-environment split is straightforward to reason about.
Region scoping. Each workspace is bound to a single AWS region, and the workspace's region determines where AWS-side resources — IAM evaluation, CloudTrail delivery, billing — are scoped. Make sure the trail you expect to capture events actually covers the region your workspace lives in. Note that the workspace region pins the gateway endpoint and these AWS-side controls, not where model inference physically runs; geography for inference is a separate control (inference_geo).
The exact selector configuration for the aws-external-anthropic service is an AWS-console detail that can evolve — confirm the current steps against the official documentation when you set it up.
Correlating logs: two request IDs on every response
Because the service is Anthropic-operated but AWS-fronted, every API response carries two request identifiers, and they serve different escalation paths:
x-amzn-requestid— the AWS request ID. This is the primary identifier, it is what CloudTrail indexes, and it is what AWS Support will ask for.request-id— Anthropic's request ID. Use this one when you open a ticket with Anthropic support.
The operational habit to build: log both headers in your application whenever you record a Claude call. If an incident starts from a CloudTrail record, you pivot on x-amzn-requestid; if it starts from an application error that needs Anthropic's side of the story, you already have request-id on hand. Capturing only one of the two means half your escalation paths begin with an archaeology exercise.
How this compares to the neighbors
The pattern is not unique — Bedrock's Messages-API surface has its own management/data event split, covered in CloudTrail events for Bedrock and its cross-region logging behavior. What is distinctive here is the dual-vendor request ID and the fact that vault and webhook operations were deliberately kept on the default-logged side. For the wider picture of audit options across all four platforms, see the audit logging overview.
Where to go next
For the full IAM action list that these events correspond to, see the IAM actions reference, or start from the platform comparison if you are still choosing a door.