What's New

Amazon Bedrock now publishes CloudWatch metrics for the bedrock-mantle endpoint — the OpenAI- and Anthropic-compatible inference endpoint — under the new AWS/BedrockMantle namespace. Customers can monitor inference counts, token consumption (input and output), and client error rates at multiple granularity levels including account, project, model, and project-and-model combinations. This brings bedrock-mantle to operational parity with bedrock-runtime for observability, enabling production-grade monitoring, alerting, and capacity planning for workloads migrated from OpenAI or Anthropic SDKs.

How It Works

• Namespace: Metrics are published to the AWS/BedrockMantle CloudWatch namespace, separate from the existing AWS/Bedrock namespace used by bedrock-runtime.
• Inference metrics: Inferences (total completed requests) and InferenceClientErrors (4xx failures) are published at all four granularity levels: Account, Project, Model, and Project+Model.
• Aggregate token metrics: TotalInputTokens and TotalOutputTokens represent billable tokens summed over the publish interval and are available at Account, Project, and Model levels — suited for sum and rate calculations.
• Per-request token metrics: InputTokens and OutputTokens emit one data point per completed inference and are published only at the Project+Model level, enabling percentile statistics (p50/p90/p99) on individual request sizes.
• Dimensions: The Project dimension carries the project ID; the Model dimension carries the model identifier (e.g., anthropic.claude-opus-4-7); account-level metrics carry no additional dimensions.
• Fan-out behavior: Each inference contributes independently to all applicable granularity levels simultaneously, so a single request increments account, project, model, and project+model counters in one publish cycle.
• Access: Metrics are viewable immediately in the CloudWatch console by navigating to Metrics → AWS/BedrockMantle, and can be used to create alarms, dashboards, and anomaly detection rules like any other CloudWatch metric.

Why It's Important

• Production readiness for migrated workloads: Teams migrating OpenAI or Anthropic SDK codebases to Bedrock can now operate bedrock-mantle with the same observability rigor they apply to other production AWS services, closing a critical gap for enterprise adoption.
• Cost attribution and chargeback: Multi-granularity metrics (project, model, project+model) allow platform teams to attribute token consumption and inference volume to specific teams or workloads, enabling accurate internal chargeback and budget governance.
• Proactive capacity management: Alarm-based alerting on error rates and token throughput lets operators detect quota exhaustion or traffic spikes before they impact end users, supporting SLA commitments.
• Unified observability: Organizations already using CloudWatch for bedrock-runtime and other AWS services can consolidate bedrock-mantle monitoring into existing dashboards and on-call runbooks without adopting new tooling.
• Percentile-level token visibility: The per-request InputTokens/OutputTokens metrics at the Project+Model level expose tail latency and token distribution (p99), which is essential for optimizing prompt engineering and controlling costs at scale.

How It's Different

• Separate namespace from bedrock-runtime: AWS/BedrockMantle is distinct from the AWS/Bedrock namespace, reflecting the architectural and API-surface differences between the two endpoints and preventing metric confusion.
• Project-based attribution vs. IAM tagging: bedrock-runtime uses IAM and per-request metadata tagging for usage attribution, while bedrock-mantle uses the Projects/Workspaces model as a first-class dimension, making team-level attribution more structured.
• Per-request percentile metrics: bedrock-mantle introduces InputTokens/OutputTokens as per-inference data points (Project+Model only), a capability not present in the same form for bedrock-runtime, enabling statistical distribution analysis of token usage.
• Covers only mantle-native APIs: These metrics exclusively cover inference through the Responses API, Chat Completions API, and Anthropic Messages API on the bedrock-mantle endpoint; InvokeModel and Converse traffic on bedrock-runtime is not included and remains under the existing runtime metrics.
• Endpoint-level throughput model: Unlike bedrock-runtime's fixed per-account RPM/TPM quotas, bedrock-mantle uses advanced scheduling and work-queuing for fair-share distribution, and the new metrics reflect this by surfacing aggregate and per-request views suited to that dynamic model.

When to Prefer It

• Migrating from OpenAI or Anthropic SDKs: Use bedrock-mantle (and these metrics) when your application was built against the OpenAI Responses/Chat Completions API or the Anthropic Messages API and you want to switch to Bedrock by changing only the base URL and API key.
• Multi-team platform engineering: Use the Project+Model granularity metrics when you operate a shared Bedrock platform and need to enforce per-team token budgets, generate usage reports, or implement internal showback/chargeback.
• Stateful conversation or server-side tool use: Choose bedrock-mantle when your application relies on stateful conversation management or server-side tool use, features not available on bedrock-runtime, and monitor those workloads with these metrics.
• New application development: AWS now recommends bedrock-mantle for new applications; pair it with these CloudWatch metrics from day one to establish observability baselines before scaling to production.
• Tail-latency and token distribution analysis: Use the per-request InputTokens/OutputTokens metrics at the Project+Model level when you need to understand p90/p99 token distributions to optimize prompts, set rate limits, or size capacity.
• Avoid for InvokeModel/Converse workloads: If your application uses Bedrock-native InvokeModel or Converse APIs on bedrock-runtime, continue using the existing AWS/Bedrock metrics; AWS/BedrockMantle will not capture that traffic.

Availability

• GA status: Generally available as of June 1, 2026; no preview or opt-in required.
• Supported regions: US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Jakarta, Mumbai, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Milan, Stockholm), and South America (São Paulo) — all regions where the bedrock-mantle endpoint is offered.
• Pricing: CloudWatch metrics are billed at standard Amazon CloudWatch rates for custom metrics and API calls; no additional Bedrock-specific charge is associated with metric publication.
• Scope limitation: Metrics cover only inference routed through the bedrock-mantle endpoint (Responses API, Chat Completions API, Anthropic Messages API); bedrock-runtime traffic is not included.
• Token metric granularity limitation: TotalInputTokens and TotalOutputTokens (aggregate) are not published at the Project+Model level; per-request InputTokens/OutputTokens are published only at the Project+Model level and not at Account or Model levels.
• Getting started: Navigate to the CloudWatch console → Metrics → select AWS/BedrockMantle namespace to begin viewing metrics immediately.

Related Resources

• https://docs.aws.amazon.com/bedrock/latest/userguide/endpoints.html
• https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-mantle-metrics.html