Amazon Bedrock in Practice

Auditing Bedrock API Calls with AWS CloudTrail

"Who called Claude, when, and with which identity?" is a question your security team will ask — during an access review at best, an incident at worst. CloudTrail answers it, if you know which events land there by default and which don't.

Claude 3P 101 · Updated July 2026 · Unofficial guide

AWS CloudTrail is the account-wide audit log that records API activity across AWS services. For Amazon Bedrock, CloudTrail captures all API calls as events — whether they came from the console, the CLI, or application code — recording the caller's identity, source IP address, and timing for each. That makes it the backbone of access auditing for a Claude deployment on Bedrock: not what was said to the model, but who was allowed to talk to it and when.

Management events: invocations are logged by default

CloudTrail distinguishes management events (logged by default on every trail) from data events (high-volume operations you must opt into). Bedrock's placement of model invocation is the detail most teams get wrong in their assumptions: InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream are logged as CloudTrail management events. In other words, every synchronous Claude invocation on the bedrock-runtime endpoint produces an audit record out of the box, with no extra configuration.

Control-plane activity — the calls that change your Bedrock configuration, such as managing model access or logging settings — is likewise captured as management events. For a security review, that means default CloudTrail already answers "which principal enabled this model?" and "who changed invocation logging?" alongside "which role invoked Claude at 02:00?".

Data events: the ones you must opt into

Some Bedrock operations are classified as data events and are not recorded unless you configure advanced event selectors on your trail. Documented examples include InvokeModelWithBidirectionalStream, the asynchronous invocation operations (StartAsyncInvoke, GetAsyncInvoke), and Bedrock Agents runtime calls. Advanced event selectors reference resource types such as AWS::Bedrock::Model, AWS::Bedrock::AgentAlias, and AWS::Bedrock::KnowledgeBase. If your architecture uses any of these paths, an auditor reading only default management events will have a blind spot — enable the selectors before you need the history, since CloudTrail cannot backfill events it never recorded.

One more scoping note: the coverage described here is for the bedrock-runtime endpoint. Calls to the newer bedrock-mantle endpoint — the current "Claude in Amazon Bedrock" surface, which also emits to CloudWatch and CloudTrail — are documented on a separate CloudTrail page; if you run both surfaces, verify each one's event coverage independently.

What a CloudTrail record does and doesn't contain

CloudTrail is an access log, not a content log. AWS's example InvokeModel entry shows requestParameters containing only the modelId, and responseElements as null — the prompt and the completion are not in the record. This is usually what compliance wants from an audit trail (no sensitive content sprayed into a widely readable log), but it means CloudTrail alone cannot support debugging or content review. For full request/response capture you need model invocation logging, a separate, deliberately enabled feature.

Rule of thumb: CloudTrail tells you who called which model, from where, when. Invocation logging tells you what was asked and answered. Audits usually need the first; debugging and content compliance need the second.

Querying for an audit

The queries that come up in practice map to fields present in every record. Filter on event name (InvokeModel, Converse) to isolate model usage; group by the caller identity to see which IAM roles and users are actually consuming Claude; check source IPs against expected networks; and review control-plane event names for configuration changes. For cross-region inference traffic, records land in the source region's trail, and the additionalEventData.inferenceRegion field records where the request was actually processed — useful when a data-residency review asks whether traffic stayed inside a geography.

Two force multipliers: centralize trails from all accounts into your organization's audit account like any other CloudTrail source, and note that Amazon GuardDuty analyzes Bedrock CloudTrail activity for suspicious behavior — such as guardrail removal — giving you managed detection on top of the raw log.

Where to go next

Pair this with enabling model invocation logging for content-level records, and see the cross-platform audit logging overview for how the other clouds handle the same question.

Sources