AgentCore Gateway adds InvokeModel support and fallback routing

Amazon Bedrock AgentCore Gateway has added support for the InvokeModel and InvokeModelWithResponseStream APIs on its inference endpoint, extending the requests that endpoint can handle.¹ The gateway also now provides fallback routing for inference requests, so traffic can be directed to another model or provider when the primary destination cannot serve it.¹ These are two related changes: API support lets existing Bedrock SDK integrations use the gateway, while fallback adds a configured way to change destinations when specified problems arise.¹ The announcement describes no numerical measure of how much traffic or how many users the additions affect; their stated scope is the API capability, routing behavior, and regional availability.¹

The API change concerns two named ways to invoke inference: InvokeModel and InvokeModelWithResponseStream, both supported through the gateway's inference endpoint.¹ For an integration already using an Amazon Bedrock SDK, the gateway can serve as the destination without requiring the client code to be rewritten.¹ The described endpoint can connect with model providers through one governed gateway destination, rather than requiring the client integration to be changed for that access.¹ This explains the practical distinction between API support and fallback: the former concerns how existing SDK clients reach providers, while the latter concerns where a request goes if its primary target encounters a configured issue.¹

Fallback behavior begins with a gateway rule that lists alternative destinations in a specified sequence.¹ That rule also identifies the conditions that permit a move away from the primary destination, including throttling, server errors, or response timeouts.¹ The gateway's routing behavior therefore depends on both the ordered alternatives and the trigger conditions entered in the rule, rather than on an unspecified destination choice.¹ The broader description also names lack of capacity and an unreachable primary destination as circumstances in which a request can be routed elsewhere.¹

Once a qualifying condition occurs, fallback sends the request toward an alternative model or provider instead of leaving it solely at the primary destination.¹ A built-in circuit breaker avoids destinations that are presently failing, helping requests get to a functioning destination sooner and avoiding extra delay from trying those failing targets.¹ This breaker works alongside the configured fallback chain: the rule supplies the alternatives and conditions, while the breaker skips destinations identified as failing.¹ The stated purpose of skipping those destinations is to reach a healthy one faster without adding latency through attempts against destinations already failing.¹

From the client's perspective, fallback does not expose a sequence of separate requests and replies: the client sends one request and receives one response even when internal retries occur.¹ That client-facing behavior is distinct from the internal routing process, which can include retries and movement among destinations in the configured chain.¹ The announcement characterizes the fallback as transparent to the client, but does not say that internal retries are absent; it specifically allows for them.¹ For integrations using the supported APIs, the stated single-request, single-response pattern sits alongside the ability to reach model providers through the governed gateway endpoint.¹

The affected client integrations described are existing Amazon Bedrock SDK integrations that can direct their calls to the gateway to access model providers.¹ The announcement says those integrations need not have their client code rewritten to use the gateway for that access.¹ It identifies the supported API calls and the gateway's routing functions, but gives no count of integrations, requests, models, or providers using them.¹ Accordingly, the size of the change is described by the two added APIs and the fallback capability, not by a reported total of users or inference traffic.¹

The announcement presents fallback as an automated response to a primary destination being throttled, lacking capacity, or becoming unreachable.¹ Its more specific configuration guidance identifies throttling, server errors, and response timeouts as possible conditions for initiating the alternate route.¹ These descriptions establish both the kinds of service problems addressed and the role of the rule: the system follows alternatives selected in advance when the rule's conditions apply.¹ No named official or direct quotation is supplied in the announcement facts, so the change can be described only through the stated product behavior.¹

Availability is described in regional terms: the two new features can be used in every AWS Region where AgentCore Gateway is available, apart from the Regions in China.¹ That scope applies to the features announced here, while the statement does not provide a count of the Regions covered.¹ The regional qualification matters when reading the broader API and routing descriptions, because those descriptions do not remove the stated China exception.¹ The announcement therefore defines availability by reference to the existing footprint of AgentCore Gateway, with China excluded, rather than claiming universal regional access.¹

Taken together, the additions let supported Bedrock SDK clients use the gateway for the named inference APIs and allow configured routing to alternatives when specified conditions occur.¹ The circuit breaker and client-transparent response pattern describe how the fallback process handles failing destinations and internal retries without presenting multiple exchanges to the client.¹ These details explain the change's operational scope without establishing a measured improvement in availability, latency, or any other outcome.¹ The stated wider context is a governed gateway for access to model providers, with the new API and fallback features limited to the Regions where that gateway is offered outside China.¹