Your AWS Bedrock environment is already generating the best free AI operational data available — request and response payloads, token counts, latency, model identifiers, and more, straight from AWS infrastructure. Model Invocation Logging simply records and delivers it. Most teams just have not enabled the layer that captures it — and many who do send it to the wrong destination. This free, no-account-required guide sets it up correctly from the first invocation.
Your AWS Bedrock environment already produces primary-source AI operational data. Model Invocation Logging is simply the layer that records and delivers it.
AWS Bedrock Model Invocation Logging records every model invocation made through your Amazon Bedrock environment — including request and response payloads, token counts, latency, model identifiers, account information, regions, error states, and inference parameters.
It is primary-source operational data generated directly by AWS infrastructure. It is free. Your Bedrock environment already produces it. Model Invocation Logging simply records and delivers it.
Most teams just have not enabled the logging layer that captures it.
Unlike benchmark datasets, synthetic evaluations, or application logs, Model Invocation Logging records actual production AI activity. Every prompt, every response, every token, every model decision, and every operational outcome comes directly from the workloads your organization is already running.
That makes it the evidence layer the entire Model Optimizer methodology depends on — and it is generated automatically by AWS infrastructure your organization already owns.
This is where evidence begins. Everything else follows.
AWS Bedrock Model Invocation Logging is not enabled by default. It requires deliberate configuration — and the setup process has a critical decision point that trips up most teams who do find it.
The AWS documentation explains how to configure logging — but not necessarily which destination is best for AI operations.
The most common setup mistake is configuring Model Invocation Logging to deliver to CloudWatch Logs instead of Amazon S3.
CloudWatch applies a 100 KB event size limit to logged request and response bodies. When payloads exceed that threshold, portions of the data are truncated or stored separately. For AI operations work — where prompt and response payloads routinely exceed that limit — CloudWatch alone produces an incomplete record.
Amazon S3 preserves the full invocation record. Every payload, every response, every token count, every error state — stored intact, queryable via Athena, S3 Select, or any downstream pipeline.
This guide isn’t valuable because it shows you where to click. It’s valuable because it helps you avoid collecting incomplete AI operational data from the first invocation.
This is the complete manual setup, using only the AWS Console — no scripts, no code, and no account required. Plan on about 10 minutes.
Prefer to automate it? Skip to the automated setup → It configures everything below in about two minutes.
Before enabling or changing anything, check whether Model Invocation Logging is already configured:
Model Optimizer requires these specific settings:
| Setting | Required value | Why it matters |
|---|---|---|
| Model invocation logging | On | Logging must be enabled |
| S3 bucket | Configured | Model Optimizer reads logs from S3, not CloudWatch |
| Log text / Text data delivery | Enabled | Captures prompts and responses for optimization analysis |
Important: CloudWatch logging alone is not sufficient. Model Optimizer requires logs in S3 with text data delivery enabled.
If logging is already on and both the S3 destination and text data delivery are configured, note your S3 bucket name — you’re done. If not, continue below.
yourcompany-bedrock-logs (must be globally unique)us-east-1)YOUR-BUCKET-NAME and YOUR-ACCOUNT-ID:{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AmazonBedrockLogsWrite",
"Effect": "Allow",
"Principal": {"Service": "bedrock.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::YOUR-BUCKET-NAME/AWSLogs/YOUR-ACCOUNT-ID/BedrockModelInvocationLogs/*",
"arn:aws:s3:::YOUR-BUCKET-NAME/large/AWSLogs/YOUR-ACCOUNT-ID/BedrockModelInvocationLogs/*"
],
"Condition": {
"StringEquals": {"aws:SourceAccount": "YOUR-ACCOUNT-ID"}
}
}
]
}
Then click Save changes.
| Setting | Value | Notes |
|---|---|---|
| S3 bucket | Your bucket name | Required for Model Optimizer |
| Log text | Enabled | Critical — captures prompts and responses |
| Log images | Enabled (optional) | For multimodal models |
| Log embeddings | Enabled (optional) | For embedding models |
Then click Save.
Critical: Make sure Log text (or Text data delivery) is enabled. Without it, Model Optimizer cannot analyze your prompts and responses.
After saving, confirm that:
Then make a Bedrock API call to generate activity and wait 5–10 minutes for logs to appear under AWSLogs/{account-id}/BedrockModelInvocationLogs/{region}/.
Model Invocation Logging is configured per region. Repeat Step 4 in each region where you run Bedrock, pointing them all at the same S3 bucket.
AWS reference: Model Invocation Logging documentation →
Everything above can be done automatically. When you create a free Model Optimizer account, you get:
Already have an account? Sign in →
If you’d rather work through the configuration with a Model Optimizer team member, Assisted Setup is available at no additional cost.
Once configured correctly, your invocation data becomes the evidence layer for:
Every capability in Model Optimizer begins with a complete invocation record.
AWS Bedrock Model Invocation Logging is a native AWS capability that records detailed information about every model invocation executed through Amazon Bedrock — including request and response payloads, token counts, latency, model identifiers, account information, regions, error states, and inference parameters. It is generated automatically by AWS infrastructure at no additional charge.
CloudWatch Logs applies a 100 KB event size limit to logged request and response bodies. For AI operations work — where prompt and response payloads routinely exceed that limit — CloudWatch alone produces an incomplete record. Amazon S3 preserves the full invocation record regardless of payload size, and makes it available for analysis through Athena, S3 Select, or any downstream pipeline.
CloudWatch Logs limits individual log events to 100 KB. When AI invocation payloads exceed that threshold, portions of the request or response data may be truncated or stored separately. S3 has no equivalent size restriction — every payload is stored intact as an individual object.
Enabling Model Invocation Logging in AWS Bedrock is free. Standard AWS storage costs apply to the S3 bucket receiving the logs. The invocation records themselves are generated at no additional charge by AWS.
No. The manual setup above uses only the AWS Console and requires no account. A free account simply gives you the automated setup script and the CloudFormation template needed to connect your logs to Model Optimizer.
Each invocation record can include request and response payloads, input and output token counts, latency metrics, model identifiers, IAM identity details, account information, operation types, AWS regions, error states, and inference parameters. The exact fields available depend on the model type and data modalities enabled during setup.
No. AWS Bedrock Model Invocation Logging is configured at the AWS account and region level through the Bedrock console. No changes to application code, API calls, or model invocation logic are required.
Yes. Organizations that connect in Privacy Mode — where prompts and responses remain in your AWS account and are never accessed by Model Optimizer — can switch to Full Analytics Mode at any time. Full Analytics Mode requires a formal signed data handling agreement prior to data access. Prompts and responses are analyzed but never stored.
The manual guide is free and takes about ten minutes. A free Model Optimizer account automates the whole thing in about two — and turns your invocation logs into monitoring, model fitness, prompt optimization, and cost decisions. No code changes. Read-only access via IAM role.
Get Started Free