High availability for an AI feature is the same discipline as for any other dependency: no single point of failure, and a tested plan for when a component degrades. On Amazon Bedrock, the first and cheapest layer of that plan is built into the platform. Cross-region inference profiles define a model plus a set of AWS regions requests can be routed to, and Bedrock routes each request dynamically across that set. If one region is congested or impaired, traffic flows to the others — with no load balancer, health checks, or retry router in your codebase.
Layer 1: let the profile do the routing
Choosing an inference profile instead of a single-region invocation is the core failover decision. Two scopes are available: geographic profiles (US, EU, APAC and similar groupings) keep requests inside one geography, which matters if your data-handling commitments restrict where prompts may be processed; global profiles can route to any supported commercial region and give you the largest capacity pool — AWS also cites roughly 10% cost savings for global routing versus geographic/standard pricing. On the current "Claude in Amazon Bedrock" surface, the Global endpoint plays this role and covers Claude Fable 5, Opus 4.8, Opus 4.7, Sonnet 5, and Haiku 4.5 across 27 regions. On the legacy surface you select scope through the model-ID prefix — global., us., eu., jp., or apac..
Operational properties worth telling your security team: cross-region traffic stays on the AWS network (never the public internet) and is encrypted in transit; requests can be routed to regions not manually enabled in your account; and every request is logged by CloudTrail in your source region, with additionalEventData.inferenceRegion recording where it was actually processed. Note the SCP prerequisites — geographic profiles need all destination regions allowed, and global profiles need "aws:RequestedRegion": "unspecified" permitted.
Layer 2: client-side fallback for what routing can't fix
Routing protects you against a destination region having trouble. It does not protect you against everything — your source region's endpoint being unreachable, a model-level issue, or sustained throttling against your own quota. Bedrock does not support Anthropic's server-side fallbacks parameter, so the second layer is client-side: catch failures and retry against an alternative you have pre-approved, such as the same profile called from a second source region, or a different Claude model.
from anthropic import AnthropicBedrockMantle
PLANS = [("us-east-1", "anthropic.claude-sonnet-5"),
("us-west-2", "anthropic.claude-sonnet-5")]
def invoke_with_fallback(messages):
last_err = None
for region, model in PLANS:
try:
client = AnthropicBedrockMantle(aws_region=region)
return client.messages.create(
model=model, max_tokens=1024, messages=messages)
except Exception as err: # narrow this in production
last_err = err
raise last_errKeep the fallback list short and deliberate. Each entry must be independently tested, covered by IAM permissions in that region, and sized against that region's quotas — a fallback that immediately throttles is not a fallback. Distinguish retryable throttling from quota exhaustion before failing over; the throttling guide covers backoff design.
Design constraints to plan around
Provisioned Throughput doesn't ride along. Inference profiles do not support Provisioned Throughput. If you rely on purchased capacity in one region, cross-region routing cannot use it — your failover path runs on on-demand quotas, and you should verify those quotas can absorb your traffic.
Quotas are per source region. Cross-region capacity is governed by quota dimensions like "Cross-Region InvokeModel tokens per minute" in the region you call from. A second source region in your fallback plan means a second quota pool to size and, if needed, a second increase request.
Residency boundaries are a design input, not an afterthought. If prompts must stay in the EU, choose the EU geographic profile from the start; failing over from a regional endpoint to a global profile during an incident is a compliance change, not just a technical one. Your deployment inherits your cloud provider's compliance posture — confirm specifics with your provider.
inferenceRegion field to verify — during a game-day test, not a real incident — that traffic actually moves.Where to go next
Start with choosing regions for inference profiles if you haven't picked a routing scope yet, then size the quota side with Bedrock quota dimensions.