Skip to main content

Bedrock Mantle

Early Access

This feature is currently in early access.

The Bedrock Mantle middleware promotes any route to an Anthropic Messages API endpoint backed by Amazon Bedrock's Anthropic integration. It builds on the Messages API middleware: requests use the same Anthropic Messages API payload format, and the middleware applies the same model and parameter governance, GenAI metrics, prompt caching, and system prompt controls. On top of that, it adds AWS authentication so you can govern Claude models served through Amazon Bedrock.

Key Features and Benefits​

  • AWS authentication: authenticate to Bedrock with either a Bedrock API key (bearer token) or AWS Signature Version 4 (SigV4) request signing.
  • Credential flexibility: for SigV4, provide static credentials or rely on the default AWS credential chain (for example, an IAM role for a Kubernetes service account).
  • Messages API governance: lock or allow client overrides for model, temperature, topP, topK, system prompts, and more, exactly as with the Messages API middleware.
  • Metrics: emits OpenTelemetry GenAI spans and counters, tagged with the aws.bedrock provider.
  • Transparent to clients: works with the standard Anthropic SDKs and the dedicated Bedrock client, so coding agents such as Claude Code can target Bedrock through the gateway.

Requirements​

  • You must have AI Gateway enabled:

    helm upgrade traefik traefik/traefik -n traefik --wait \
      --reset-then-reuse-values \
      --set hub.aigateway.enabled=true

  • Define a Kubernetes ExternalName service pointing at the Bedrock Mantle host for your region (bedrock-mantle.<region>.api.aws). The Kubernetes CRD provider must allow ExternalName services (providers.kubernetesCRD.allowExternalNameServices=true).

  • AWS credentials that are authorized to invoke the Anthropic models on Bedrock, either as a Bedrock API key or as SigV4 credentials.

How It Works​

  1. Intercepts the request and validates it against the Anthropic Messages API schema.
  2. Authenticates to Bedrock using one of the configured methods:
    • A Bedrock API key, sent as an Authorization: Bearer header.
    • AWS SigV4 signing, which signs the request for the bedrock-mantle service scope in the configured region.
  3. Applies governance by rewriting model or parameter fields when overrides are denied, identical to the Messages API middleware.
  4. Forwards the request to the upstream Bedrock host and records usage metrics from the response, tagged with the aws.bedrock provider.

When SigV4 signing is used, the signature is computed in the transport layer, after the gateway selects the upstream service. This is required because the signature depends on the upstream Host header and region. Traefik-injected forwarding headers (X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto) are excluded from the signature and restored afterwards, so the backend still receives them.

Region must match the upstream host

The region used for SigV4 signing must match the region in the ExternalName host (bedrock-mantle.<region>.api.aws). A mismatch produces a signature verification error from AWS.

Authentication​

Bedrock Mantle supports three authentication modes. SigV4 credentials and an apiKey are mutually exclusive.

Omit static credentials and set only the region. The middleware resolves credentials from the default AWS credential chain (environment variables, an EKS Pod Identity association, an IAM role for a service account (IRSA), or the instance profile). This avoids storing long-lived keys in the cluster.

spec:
  plugin:
    bedrock-mantle:
      region: us-east-1
      anthropic:
        model: anthropic.claude-haiku-4-5

SigV4 with static credentials​

Provide accessKeyId and secretAccessKey (and optionally sessionToken) together with the region.

spec:
  plugin:
    bedrock-mantle:
      accessKeyId: urn:k8s:secret:aws-creds:access-key-id
      secretAccessKey: urn:k8s:secret:aws-creds:secret-access-key
      region: us-east-1
      anthropic:
        model: anthropic.claude-haiku-4-5

Bedrock API key (bearer token)​

Provide a Bedrock API key. The middleware sends it as an Authorization: Bearer header.

spec:
  plugin:
    bedrock-mantle:
      apiKey: urn:k8s:secret:aws-creds:bedrock-api-key
      anthropic:
        model: anthropic.claude-haiku-4-5

Configuration Example​

The example below governs a route with SigV4 static credentials and forwards requests to Bedrock in us-east-1.

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: bedrock-mantle
spec:
  plugin:
    bedrock-mantle:
      accessKeyId: urn:k8s:secret:aws-creds:access-key-id
      secretAccessKey: urn:k8s:secret:aws-creds:secret-access-key
      region: us-east-1
      anthropic:
        model: anthropic.claude-haiku-4-5
        allowModelOverride: false
        allowParamsOverride: true
        params:
          temperature: 1
          maxTokens: 1024
Client base URL

Point your Anthropic client at the gateway using any base path your IngressRoute matches. For example https://ai.example.com/anthropic (so requests reach /anthropic/v1/messages). The bedrock-mantle middleware doesn't inspect the request path, so the route can match any path you configure. The gateway forwards the request to bedrock-mantle.<region>.api.aws with the upstream Host header set (passHostHeader: false).

For example, to expose the route at /llm instead while forwarding a clean path upstream, add a stripPrefix middleware ahead of bedrock-mantle in the chain:

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: strip-llm-prefix
spec:
  stripPrefix:
    prefixes:
      - /llm
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: bedrock-anthropic
spec:
  routes:
    - kind: Rule
      match: Host(`ai.example.com`) && PathPrefix(`/llm`)
      middlewares:
        - name: strip-llm-prefix
        - name: bedrock-mantle
      services:
        - name: bedrock
          port: 443
          passHostHeader: false

Configuration Options​

FieldDescriptionRequiredDefault
apiKeyBedrock API key, sent as an Authorization: Bearer header. Mutually exclusive with SigV4 credentials. Reference a Kubernetes Secret with the URN format (for example, urn:k8s:secret:<secretname>:<key>)No
accessKeyIdAWS access key ID for SigV4 signing. Requires secretAccessKeyNo
secretAccessKeyAWS secret access key for SigV4 signing. Requires accessKeyIdNo
sessionTokenAWS session token for temporary SigV4 credentialsNo
regionAWS region used for SigV4 signing. Required for SigV4 authentication and must match the region in the upstream hostConditional
anthropicEmbedded Messages API configuration (model, parameters, governance, system prompts, prompt caching, and metrics) applied to requests forwarded to BedrockNo

When no apiKey and no static SigV4 credentials are set, the middleware uses the default AWS credential chain and still requires region.

Anthropic configuration​

Nest governance fields under anthropic

Model and parameter governance fields belong inside the anthropic block. AWS authentication fields (apiKey, accessKeyId, secretAccessKey, sessionToken, region) stay at the top level. Fields such as model or params placed at the top level are ignored, so governance is not applied.

The anthropic block accepts the same fields as the Messages API middleware, including model, allowModelOverride, allowParamsOverride, params, systemPrompt, and allowInlineSystemMessages. See the Messages API Configuration Options for the full list and behavior, including Parameter Override Behavior, Model Override Behavior, and System Prompt Governance.

Bedrock model identifiers

On Bedrock, models are identified with the anthropic. prefix (for example, anthropic.claude-haiku-4-5). Available models depend on the region, and requesting a model that is not available returns a 404 not_found_error. See the Anthropic on Amazon Bedrock documentation for the current catalog.

Metrics​

The middleware emits OpenTelemetry GenAI metrics when metrics are enabled. Spans and counters are tagged with gen_ai.provider.name = aws.bedrock. In addition to standard input/output token counts, Anthropic-specific usage fields cache_creation_input_tokens and cache_read_input_tokens are recorded when prompt caching is active.

Prompt Caching, Streaming, and Body Size​

Bedrock Mantle inherits the prompt caching, streaming, and request body size behavior of the Messages API middleware. Configure prompt caching through anthropic.params.cacheControl.

Working with Other AI Middlewares​

When bedrock-mantle is in the middleware chain, the AI Gateway propagates the Anthropic Messages API format to the other AI middlewares in the chain. Content Guard, LLM Guard, Semantic Cache, and Token Rate Limit detect the format and adapt their behavior without additional configuration.

Middleware Order Matters

Place the bedrock-mantle middleware first in the chain among the AI kind. It sets the request format in the context, which the other AI middlewares rely on to detect the Anthropic format. Guards placed before it cannot detect the format.

If you can't guarantee bedrock-mantle runs first in the chain, set clientRequestFormat: messagesAPI explicitly on Content Guard, LLM Guard, or Token Rate Limit instead of relying on auto-detection.

For detailed examples of combining these middlewares, see the Using AI Middlewares with Messages API guide.

Troubleshooting​

Signature verification errors

Problem: Bedrock rejects requests with a signature mismatch.

Solution: Ensure the region matches the region in the ExternalName host (bedrock-mantle.<region>.api.aws), and that the route sets passHostHeader: false so the upstream Host header is used for signing.

bedrock: apiKey and SigV4 credentials are mutually exclusive

Problem: The middleware fails to start with bedrock: apiKey and SigV4 credentials are mutually exclusive.

Solution: Configure either apiKey for bearer-token authentication or SigV4 credentials (accessKeyId/secretAccessKey), but not both.

accessKeyId and secretAccessKey must be set

Problem: The middleware fails to start with bedrock: accessKeyId and secretAccessKey must be set.

Solution: Provide both accessKeyId and secretAccessKey together, or omit both to use the default AWS credential chain.

region is required for SigV4 authentication

Problem: The middleware fails to start with bedrock: region is required for SigV4 authentication.

Solution: Set the region field whenever you authenticate with SigV4, including when using the default AWS credential chain.

sessionToken requires accessKeyId and secretAccessKey

Problem: The middleware fails to start with bedrock: sessionToken requires accessKeyId and secretAccessKey.

Solution: sessionToken is only valid alongside static SigV4 credentials. Provide accessKeyId and secretAccessKey together with sessionToken, or omit all three to use the default AWS credential chain.

Model does not exist

Problem: Bedrock responds with 404 and "The model '<model>' does not exist".

Solution: The requested model is not available on Bedrock in this region. Use a model identifier that is available there (for example, anthropic.claude-haiku-4-5). To prevent clients from requesting unavailable models, set anthropic.model and anthropic.allowModelOverride: false.

401 error when reusing the same Bedrock token in LLM Guard

Problem: The same Bedrock API key works for bedrock-mantle's apiKey field, but produces a confusing 401 when referenced from an llm-guard custom header pointed at Bedrock.

Solution: The two middlewares handle the Authorization header differently. bedrock-mantle's apiKey expects the raw token and adds Bearer for you. llm-guard's clientConfig.headers sends values verbatim so its secret must already include Bearer if the endpoint expects it. See Custom Headers. Store the token in two secret values: raw for bedrock-mantle, Bearer <token> for llm-guard.

Related Content​