Amazon Bedrock has two inference surfaces for Claude. The legacy surface — the InvokeModel and Converse APIs on the bedrock-runtime endpoint — and the current "Claude in Amazon Bedrock" surface, which serves Anthropic's native Messages API from the bedrock-mantle endpoint (the one the AnthropicBedrockMantle Python client talks to). CloudWatch, AWS's monitoring service, treats them as two different products: bedrock-runtime publishes metrics under the AWS/Bedrock namespace, while bedrock-mantle publishes to a separate AWS/BedrockMantle namespace. Any dashboard, alarm, or anomaly detector built on AWS/Bedrock simply does not see bedrock-mantle traffic.
For a team migrating gradually — some workloads still on Converse, new ones on the Messages API — this is the classic "dashboards look fine, but half the fleet is unmonitored" failure. Invocation counts appear to drop as traffic migrates, error alarms never fire for the new surface, and monthly token reports silently undercount.
What each namespace contains
The two namespaces do not just differ in name; they carry different metric sets.
| Concern | AWS/Bedrock (bedrock-runtime) | AWS/BedrockMantle (bedrock-mantle) |
|---|---|---|
| Request count | Invocations | Inferences |
| Errors | InvocationClientErrors, InvocationServerErrors, InvocationThrottles | InferenceClientErrors |
| Tokens | InputTokenCount, OutputTokenCount, plus cache metrics (CacheReadInputTokens, CacheWriteInputTokens) | TotalInputTokens, TotalOutputTokens (aggregates) plus per-inference InputTokens/OutputTokens |
| Latency | InvocationLatency (ms, request to last token), TimeToFirstToken (streaming) | Not yet published — AWS documents that InvocationLatency and TimeToFirstToken equivalents are not yet available |
| Dimensions | ModelId | Four granularity levels: Account, Project, Model, and Project+Model |
Two mantle-side details are worth calling out. First, the Project dimension has no equivalent on bedrock-runtime: mantle metrics emit at Account, Project, Model, and Project+Model granularity, which makes per-project cost attribution and internal chargeback possible directly from CloudWatch. Second, the per-inference InputTokens and OutputTokens metrics publish one data point per request (at Project+Model level only), so you can compute p50/p90/p99 request-size distributions — something the aggregate-only token counts on the legacy surface cannot give you.
bedrock-runtime provides for cross-region inference traffic. If latency SLIs matter to you, measure them client-side for bedrock-mantle workloads until AWS publishes equivalents.Building a dashboard that covers both surfaces
A unified view is straightforward once you know both namespaces exist:
Pair the equivalents. Put AWS/Bedrock Invocations and AWS/BedrockMantle Inferences on the same widget (or sum them with metric math) for total Claude request volume. Do the same for token counts: InputTokenCount + TotalInputTokens, and OutputTokenCount + TotalOutputTokens.
Duplicate your alarms. An error-rate alarm on InvocationClientErrors needs a sibling on InferenceClientErrors. Note the asymmetry: the legacy namespace separates client errors, server errors, and throttles, while the documented mantle metric set centers on client errors — so don't assume a one-to-one mapping for every alarm.
Exploit the Project dimension. If you route different teams or applications through different Bedrock projects on the mantle surface, per-project token widgets replace the tagging gymnastics the legacy surface required. For request-level attribution on the legacy surface, see requestMetadata tags.
Check every region you serve. Because mantle metrics don't aggregate across regions, a multi-region deployment needs the mantle widgets repeated (or a cross-region CloudWatch dashboard) per region.
The same split applies beyond metrics
The namespace split is one instance of a broader pattern: observability features attach to a specific endpoint, not to "Bedrock" as a whole. Model invocation logging — the feature that captures prompts and completions — only covers the bedrock-runtime endpoint, and CloudTrail records mantle inference under a different event source and as a different event class. If you are auditing coverage, read the CloudTrail data-events guide and the invocation log schema walkthrough alongside this one. For the quota-side consequences of the two surfaces, see mantle vs runtime quotas.
Where to go next
Start with the CloudWatch metrics overview for Bedrock if you're new to the metric set, or the platform comparison for the bigger picture.