Free Setup Guide

Free Bedrock Model Invocation Logging Setup Guide

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.

The best free AI operational data you already own

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.

Why this data is different

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.

Why most teams miss it

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 CloudWatch problem

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.

Set it up: enable Model Invocation Logging to S3

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.

Step 1 — Check your current MIL settings

Before enabling or changing anything, check whether Model Invocation Logging is already configured:

  1. Go to the Bedrock Console
  2. In the left sidebar, click Settings
  3. Look at the Model invocation logging section

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.

Step 2 — Create an S3 bucket

  1. Go to the S3 Console
  2. Click Create bucket
  3. Configure:
    • Bucket name: yourcompany-bedrock-logs (must be globally unique)
    • Region: the same region as your primary Bedrock usage (e.g., us-east-1)
    • Block all public access: keep enabled (default)
  4. Click Create bucket

Step 3 — Add a bucket policy for Bedrock

  1. Open your new bucket and go to the Permissions tab
  2. Scroll to Bucket policy and click Edit
  3. Paste the policy below, replacing 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.

Step 4 — Enable Model Invocation Logging

  1. Go to the Bedrock Console and confirm you’re in the correct region (top-right corner)
  2. In the left sidebar, click Settings
  3. Find the Model invocation logging section and toggle it On
  4. Configure:
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.

Step 5 — Verify

After saving, confirm that:

  • Status shows On
  • Your S3 bucket is listed
  • Text logging is enabled

Then make a Bedrock API call to generate activity and wait 5–10 minutes for logs to appear under AWSLogs/{account-id}/BedrockModelInvocationLogs/{region}/.

Running Bedrock in multiple regions?

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 →

Prefer to automate it?

Everything above can be done automatically. When you create a free Model Optimizer account, you get:

  • A one-command setup script that provisions the S3 bucket, applies the correct bucket policy, and enables Model Invocation Logging with the right settings — in about two minutes.
  • The CloudFormation template that grants Model Optimizer secure, read-only access to your logs (required to connect your data, and not part of the manual steps above).
  • For Privacy Mode, the Bedrock Log Sanitizer, which strips prompt and response bodies inside your own AWS account before Model Optimizer ever reads them.

Already have an account? Sign in →

Prefer a guided setup?

If you’d rather work through the configuration with a Model Optimizer team member, Assisted Setup is available at no additional cost.

What becomes possible

Once configured correctly, your invocation data becomes the evidence layer for:

  • AI Monitoring — cost, token usage, errors, and trends across your environment
  • AI Cost Optimization — identifying the operational decisions responsible for spend
  • Model Fitness — evaluating models against your actual prompt patterns and workloads
  • Prompt Optimization — reducing token consumption and improving output quality

Every capability in Model Optimizer begins with a complete invocation record.

Frequently Asked Questions

What is AWS Bedrock Model Invocation Logging?

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.

Why is S3 the recommended logging destination?

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.

What is the CloudWatch 100 KB limitation?

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.

Is Model Invocation Logging free?

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.

Do I need a Model Optimizer account to follow this guide?

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.

What data does Model Invocation Logging capture?

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.

Do I need to change my code to enable logging?

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.

Can I start with Privacy Mode and switch to Full Analytics Mode later?

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.

Set it up once. Collect complete evidence from every invocation.

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