Model invocation logging is Amazon Bedrock's opt-in feature (disabled by default) that collects invocation logs, model input data, and model output data for supported calls in an account and Region. Enable it once — via the console (Settings → Model invocation logging) or the PutModelInvocationLoggingConfiguration API — and every covered call is written to CloudWatch Logs, Amazon S3, or both. The destination must live in the same AWS account and Region as the logging configuration, and once enabled, logs are stored until you delete the configuration.
bedrock-runtime endpoint — Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream. Calls on the current bedrock-mantle endpoint (Anthropic's Messages API via AnthropicBedrockMantle) are not captured. If your traffic runs on the current surface, this schema applies only to your legacy workloads; audit coverage there comes from CloudTrail data events instead.The record, field by field
Each log entry carries schemaType: "ModelInvocationLog" and the following fields, all populated by Bedrock except one:
| Field | What it contains |
|---|---|
timestamp | When the invocation occurred. |
accountId / region | The AWS account and Region that served the call. |
requestId | The request ID — your join key to CloudTrail entries and support tickets. |
operation | Which API was called (e.g. Converse, InvokeModel). |
modelId | The invoked model (e.g. an anthropic.-prefixed Claude ID). |
identity.arn | The IAM or STS principal that made the call — captured automatically, which makes per-principal usage queries possible with no client changes. |
requestMetadata | Optional caller-supplied key-value tags. This is the only caller-supplied field in the record; see the requestMetadata guide. |
input.inputBodyJson / input.inputTokenCount | The full request body (your prompt, system prompt, tool definitions) and its token count. |
output.outputBodyJson / output.outputTokenCount | The full response body (Claude's completion) and its token count. |
The 100 KB cap and S3 overflow
Each log record embeds request and response JSON bodies up to 100 KB. Bodies larger than that — and binary data such as images, regardless of size — are not embedded in the record. Instead, Bedrock writes them as separate objects to your S3 destination under a data prefix, and the log entry carries a reference pointing at those objects. The exact reference shape is best confirmed against a live record in your own account, but the operational consequences are the same either way:
- CloudWatch-only logging is incomplete for large payloads. Long Claude conversations, big tool results, and any image input exceed the embed path. If you configure only a CloudWatch Logs destination, plan for the fact that large/binary data delivery is a separate S3 concern — AWS even publishes a distinct delivery-health metric pair for it (
ModelInvocationLargeDataS3DeliverySuccess/Failure; see the delivery-health guide). - Queries must follow the reference. A CloudWatch Logs Insights query that reads
input.inputBodyJsondirectly will come back empty for oversized calls. Compliance reviews that "grep the logs for the prompt" will systematically miss exactly the biggest, most interesting requests unless the tooling dereferences the S3 objects. - Retention must cover both stores. Your log-group retention policy and your S3 lifecycle rules need to agree, or the embedded record will outlive (or predecease) the overflow object it points to.
Destinations and query paths
The S3 destination delivers gzipped JSON batch files, queryable with S3 Select or Athena and cataloguable with AWS Glue — the natural home for retrospective analysis and long-term retention. The CloudWatch Logs destination (log stream aws/bedrock/modelinvocations) is queryable with Logs Insights and streamable in real time — the natural home for dashboards and alerting. Plumbing differs per destination: S3 needs a bucket policy allowing bedrock.amazonaws.com to s3:PutObject (with SourceAccount/SourceArn conditions); CloudWatch needs an IAM role trusted by bedrock.amazonaws.com with logs:CreateLogStream and logs:PutLogEvents.
Finally, remember what these records are: full prompts and completions, i.e. potentially sensitive business data. Anthropic recommends retaining activity logs on at least a 30-day rolling basis to investigate potential misuse, and notes that turning the feature on does not give AWS or Anthropic access to your content — but it does give everyone with read access to that log group or bucket access to it. Scope readers deliberately, and consider CloudWatch Logs data-protection masking policies for sensitive fields.
Where to go next
The invocation logging setup guide walks through enablement step by step; prompt log management covers the governance side.