AWS adds InvokeModel APIs and fallback to AgentCore Gateway

AWS announced on October 22, 2026, that Amazon Bedrock AgentCore Gateway now supports Bedrock’s InvokeModel and InvokeModelWithResponseStream APIs on its inference endpoint, alongside model fallback routing. The update brings both API compatibility and failure handling into the gateway’s inference path. AWS announcement

An endpoint for existing Bedrock clients

According to AWS, developers can point an existing Bedrock SDK integration at the gateway to access model providers through a single governed endpoint, without rewriting client code for each provider. The API additions cover both standard invocation and streaming responses. SDK compatibility details

The practical appeal is separating client integration from destination selection. Teams should still validate each destination’s input requirements and output quality rather than assume API compatibility makes different models interchangeable.

Ordered fallback with a circuit breaker

Fallback routing uses an ordered chain of alternative destinations configured in a gateway rule. Teams also specify switching conditions, such as throttling, server errors or response timeouts. AWS says the gateway automatically routes to an alternative model or provider when the primary destination is throttled, out of capacity or unreachable.

According to AWS, a built-in circuit breaker skips destinations that are currently failing. Fallback attempts remain behind the gateway interface: the client sends one request and receives one response despite the internal attempts. Fallback routing details

Availability and deployment checks

AWS says both additions are available in every AWS Region where Amazon Bedrock AgentCore Gateway is available, except Regions in China. Regional availability

Before adopting fallback, evaluate each alternative destination against application requirements, cost limits and latency budgets. Treat a successful fallback response as something to validate, not proof that the application received an acceptable result.

Streaming deserves particular scrutiny. Verify what happens if the primary destination fails after output has begun; support for InvokeModelWithResponseStream should not be treated as a promise of mid-response recovery.