Streaming, Errors & Resilience

Bedrock Invocation Logging Gap: Why Mantle Calls Are Missing From Your S3 Logs

You enabled model invocation logging, the delivery metrics look healthy — and your newest Claude traffic isn't in the bucket. The logging feature and your traffic are on different endpoints.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Amazon Bedrock's model invocation logging is the feature compliance teams love: full request and response bodies, token counts, and caller identity delivered to CloudWatch Logs and/or S3. Many organizations enabled it years ago and consider the box checked. Then they migrate Claude workloads to the current "Claude in Amazon Bedrock" Messages API — the bedrock-mantle endpoint that the AnthropicBedrockMantle SDK client targets — and the new traffic silently vanishes from the logs.

The gap, precisely

AWS's documentation is explicit about which operations invocation logging covers: Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream — all calls through the bedrock-runtime endpoint. Calls made through other endpoints, including the bedrock-mantle endpoint that serves the Anthropic Messages API, are not currently captured by invocation logging. There is no error and no misconfiguration to find: the feature simply does not apply to that endpoint today.

This is easy to miss because Anthropic's own page notes that Claude in Amazon Bedrock emits logs to both CloudWatch and CloudTrail — which is true for CloudWatch metrics and CloudTrail events, but neither of those captures prompt and completion bodies the way invocation logging does on the legacy surface.

What you actually get on the Mantle endpoint

Observability on the current surface is real, but it is a different toolset, in different places:

SignalLegacy (bedrock-runtime)Current (bedrock-mantle)
Prompt/completion captureInvocation logging to CloudWatch/S3Not available
CloudWatch metrics namespaceAWS/BedrockAWS/BedrockMantle
CloudTrail inference eventsManagement events (on by default)Data events (must be enabled, billed)
Event source in CloudTrailbedrock.amazonaws.com / runtimebedrock-mantle.amazonaws.com

Each row hides a migration trap. Dashboards and alarms built on AWS/Bedrock metrics see nothing from Mantle traffic — the new namespace AWS/BedrockMantle carries its own metrics (Inferences, TotalInputTokens, TotalOutputTokens, and per-inference token distributions), including a Project dimension useful for chargeback, but no time-to-first-token equivalent yet. On the audit side, Mantle inference is a CloudTrail data event (CreateInference covering /anthropic/v1/messages, and CountTokens for token counting): if you require an audit trail of inference calls, you must explicitly enable data event capture with advanced event selectors, and pay CloudTrail data-event charges. Filters written against the old event sources will miss the traffic entirely.

Warning: AWS documents that customer-supplied metadata on CreateInference calls is logged verbatim in CloudTrail when data events are enabled. Never put secrets, credentials, or sensitive values in request metadata.

What to do about the content-logging requirement

If your governance program requires prompt/completion retention — Anthropic recommends retaining activity logs on at least a 30-day rolling basis — you have three realistic paths on the current surface. First, log at the application layer: your gateway or client wrapper writes requests and responses to your own store before and after each call, giving you full control over redaction and retention. Second, keep compliance-critical workloads on the legacy bedrock-runtime surface where invocation logging works — at the cost of the newer surface's API parity, and noting some current models (Fable 5, Opus 4.8, Sonnet 5) are not on the legacy surface. Third, accept metrics-plus-CloudTrail as your evidence trail where content capture isn't strictly required: identity, model, timing, and token counts without bodies.

Whichever you choose, write it down. The most expensive version of this gap is the one discovered during an audit, when six months of Mantle traffic was assumed to be in the S3 bucket and wasn't.

Where to go next

For setting up the legacy-surface logging correctly, see Bedrock invocation logging setup. For the audit-event side, read Bedrock CloudTrail API events, and for cross-platform logging strategy, audit logging across platforms.

Sources