Amazon Bedrock AgentCore Gateway Adds Model Fallback

The one launch risk you can't put on the schedule is a model provider answering 429 Too Many Requests at 9 a.m. on go-live day. On October 22, 2026, AWS added AgentCore Gateway model fallback: you list backup destinations in a gateway rule, and the gateway reroutes calls when the primary fails.

What AWS shipped

The announcement lists two additions:

• InvokeModel support. The gateway's inference endpoint now accepts the Amazon Bedrock InvokeModel and InvokeModelWithResponseStream APIs, so an app that already uses the Bedrock SDK only changes its endpoint.
• Ordered fallback. A gateway rule defines an ordered chain of alternative destinations. The client sends one request and gets one response, with no retry logic of its own.

It is available in every Region where AgentCore Gateway is offered, except China. The announcement does not mention pricing.

How AgentCore Gateway model fallback works

The fallback documentation fills in the details a plan needs:

• Chain length. One to two alternatives after the primary, so three destinations at most.
• Triggers. You choose them: HTTP status codes such as 429 or 5XX, plus CONNECTION_ERROR, FIRST_BYTE_TIMEOUT and UNROUTABLE. Each destination gets one attempt, and if all fail the caller receives the last error.
• Streaming limit. Once a streaming response has started, the gateway can no longer fall back. The caller gets the partial response and an error, and must retry.
• Circuit breaker. On by default. It skips failing destinations and probes recovered ones with a small share of requests. Set it to DISABLED if you'd rather keep a cheaper primary than fail fast to a costlier secondary.

Create a fallback rule on the gateway

This is the docs' own example, with a placeholder gateway ID. Target and model names are illustrative, so use targets configured on your gateway.

aws bedrock-agentcore-control create-gateway-rule \
    --gateway-identifier <gateway-id> \
    --priority 100 \
    --description "Prefer gpt-5.5 on bedrock-mantle, fall back to OpenAI, then gpt-5.4" \
    --conditions '[
        {"matchModels": {"anyOf": [{"value": "gpt-5.5"}]}}
    ]' \
    --actions '[
        {
            "routeToTarget": {
                "staticRoute": {
                    "targetName": "bedrock-mantle",
                    "model": "gpt-5.5",
                    "fallback": {
                        "circuitBreaker": {"mode": "ENABLED"},
                        "triggerOn": {
                            "statusCodes": ["5XX", "429"],
                            "errors": ["CONNECTION_ERROR", "FIRST_BYTE_TIMEOUT", "UNROUTABLE"]
                        },
                        "firstByteTimeoutMilliseconds": 5000,
                        "targetFallback": [
                            {"targetName": "openai"},
                            {"targetName": "bedrock-mantle", "model": "gpt-5.4"}
                        ]
                    }
                }
            }
        }
    ]'

The rule tries gpt-5.5 on bedrock-mantle, then on openai, then degrades to gpt-5.4. The primary is abandoned on 429, 5XX, connection errors, first-byte timeouts or an unroutable target, and gets 5 seconds to send a first byte.

On the app side, the InvokeModel guide says the only change is the endpoint:

import json
import boto3

client = boto3.client(
    "bedrock-runtime",
    region_name="<region>",
    endpoint_url="https://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/inference",
)

response = client.invoke_model(
    modelId="us.anthropic.claude-sonnet-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 1024,
        "messages": [{"role": "user", "content": "Write a haiku."}],
    }),
    contentType="application/json",
)
print(json.loads(response["body"].read()))

Callers authenticate to the gateway, not to Bedrock, and need bedrock-agentcore:InvokeGateway. Swap in a model your gateway serves.

What it changes about availability risk

Before, failover was each application team's problem. Now it is one reviewed rule on the gateway. It does not remove the risk, though:

• Mid-stream failures still reach users. Fallback ends once a stream has started.
• The backup is a different thing. It may be another provider or an older model, so quality can shift. The gateway re-frames streams but does not rewrite a request body into another schema, so the backup must accept the payload your client already sends.
• Failover is silent. The client gets no indicator of which destination answered. The gateway's routing logs record it.

What to put in the plan

1. Name the backups and get sign-off. Who picks the second and third destination, who approves the quality, and does the data-handling review cover them? Targets such as openai and anthropic call those providers directly with a stored API key.
2. Test every leg, not just the primary. Use the same request body, and set contentType="application/json" on translated routes. Per the docs, a Bedrock guardrail on a translated request is rejected with a 400, and AWS recommends AgentCore Policy for guardrails that span providers.
3. Rehearse the failure. Add a staging drill that forces throttling and confirms the request lands on the next destination, streaming case included.
4. Budget for extra attempts. Per the docs, each outbound attempt counts as a gateway invocation, and the model provider bills usage separately. The announcement gives no pricing and I couldn't find an inference rate on AWS's pricing page, so ask your AWS account team before you forecast.
5. Alert when the backup carries traffic. Otherwise you can run on the second choice for days without anyone noticing.

On Monday, ask your engineering lead for the three destinations with their approvals, a staging failure drill result, and the owner of the routing logs. If cost is still "unknown," write that into the risk register.

For anyone running AI in production, the useful change is that failover becomes a reviewed, testable gateway rule instead of retry code scattered across applications.