Skip to content

Bedrock Mantle Endpoint Activity Missing from CloudWatch Model Invocation Logs

0

Title: Bedrock Mantle Endpoint Activity Missing from CloudWatch Model Invocation Logs

Issue Summary We are using the Bedrock Mantle OpenAI-compatible endpoints, but no activity is being logged to CloudWatch, despite having Bedrock Model Invocation Logging explicitly enabled in our account. We can see the usage hitting our billing, but our CloudWatch log groups remain completely empty for these specific calls, and usage for the Mantle endpoints does not show in Cloudwatch metrics.

When we test against standard endpoints (like the Bedrock Runtime /converse API) using the exact same environment and models, the invocation payloads log to CloudWatch as expected.

Is this expected behavior or not? If it is expected, is there any way we can properly log and monitor usage with Cloudwatch for Mantle endpoints, short of surprise bills? We are really just looking to get alerts on usage spikes.

Steps to Reproduce You can reproduce this using the following two cURL commands. (Note: The API keys have been removed for security).

1. Mantle Test (Fails to log to CloudWatch)

curl --request POST \
  --url [https://bedrock-mantle.us-west-2.api.aws/v1/chat/completions](https://bedrock-mantle.us-west-2.api.aws/v1/chat/completions) \
  --header 'authorization: Bearer {apikey}' \
  --header 'content-type: application/json' \
  --data '{
  "model": "openai.gpt-oss-120b",
  "messages": [
    {
      "role": "user",
      "content": "Test logging"
    }
  ],
  "max_tokens": 100
}'

2. Bedrock Converse Test (Logs successfully to CloudWatch)

curl --request POST \
  --url [https://bedrock-runtime.us-west-2.amazonaws.com/model/openai.gpt-oss-120b-1:0/converse](https://bedrock-runtime.us-west-2.amazonaws.com/model/openai.gpt-oss-120b-1:0/converse) \
  --header 'authorization: Bearer {apikey}' \
  --header 'content-type: application/json' \
  --data '{
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "text": "Test Logging"
        }
      ]
    }
  ],
  "inferenceConfig": {
    "maxTokens": 500,
    "temperature": 0.5
  }
}'
1 Answer
1
Accepted Answer

This is expected behavior. The Bedrock Mantle (OpenAI-compatible) endpoints currently do not support Model Invocation Logging to CloudWatch. This is a known limitation of the Mantle endpoints.

Model Invocation Logging is only supported for calls made through the native Bedrock Runtime APIs (InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream). The Mantle endpoints provide OpenAI API compatibility but bypass the standard Bedrock invocation logging pipeline.

Workarounds for monitoring Mantle endpoint usage:

AWS CloudTrail: Mantle API calls should still appear in CloudTrail as API events. You can create CloudWatch alarms based on CloudTrail event patterns to detect usage spikes.

AWS Cost Explorer / Billing Alerts: Set up AWS Budgets with alerts to get notified when Bedrock spending exceeds a threshold. This won't give you per-request visibility but will catch unexpected cost spikes.

Application-level logging: Add logging in your application layer before/after Mantle API calls to capture request metadata, token counts (from the response usage field), and latency.

Switch to native Bedrock APIs: If invocation logging is a hard requirement, consider using the native Bedrock Converse API instead of the Mantle endpoint. The Converse API supports the same models and provides full CloudWatch logging.

I'd recommend opening an AWS Support case or submitting a feature request to have Model Invocation Logging extended to Mantle endpoints, as this is a common ask.

AWS
answered 2 months ago
AWS
EXPERT
reviewed 2 months ago
  • I was afraid that was the case, but thanks for the info and workarounds for now! Unfortunately, we're currently using Semantic Kernel with .NET, which has limited provider support in its native libraries, so we're stuck looking at other options or continuing to use Mantle with limited monitoring.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.