Same-Model Failover for Claude Across Anthropic, Bedrock, Azure and Vertex

Same-model failover for Claude across Anthropic, Bedrock, Azure and Vertex is an infrastructure problem. The weights are identical, but authentication, capacity, networking and data protection depend on the route. A dedicated routing layer must manage those differences so that recovering from an outage does not create an untracked change in cost, compliance or model lifecycle.

Why Claude production deployments need more than one path to the model

The October 25 incident shows how a provider can fail. A production deployment can lose access to Claude even when the model itself is not the source of the failure. Authentication, rate limits, networking and availability are all part of the provider layer. A single-provider deployment has no independent fallback when that layer fails.

The distinction determines what redundancy must protect. Another region may address a regional disruption, but it does not necessarily provide a separate authentication path or access to another provider’s capacity. Production resilience therefore depends on more than model availability. It depends on having another usable route to inference.

What actually differs at each provider boundary

Anthropic’s direct API, AWS Bedrock, Google Vertex AI and Azure AI Foundry expose identical model weights through different infrastructure. Bedrock authenticates through AWS IAM and integrates with VPC, CloudTrail and the existing AWS security posture. Vertex uses Google Cloud’s identity model and regional network, while Foundry uses Azure AD and Microsoft’s infrastructure. The direct API can be used without a contract with a cloud vendor. It has no automatic VPC integration or managed compliance tooling, however, so those properties do not follow from access to Claude alone.

Data residency depends on the endpoint as well as the provider. Bedrock offers its EU Inference Profile, identified by the eu. prefix, while Vertex offers EU regional and multi-region endpoints. These are distinct from Vertex’s global processing route. The Microsoft Q&A thread on Claude in Foundry describes a different boundary, where the expected EU infrastructure and residency guarantees were not yet available. Azure authentication therefore does not, by itself, establish where Claude inference takes place.

Rate limits, billing and model availability dates are independently set. Reaching Bedrock’s concurrency limit does not establish that Vertex is also throttled. Access to a model through one provider does not mean it is available through another. The shared weights remove one variable from failover, but they do not make the surrounding services interchangeable.

How speed and cost actually vary across the four routes in practice

Artificial Analysis benchmarks as of October 2026 show that the route changes performance even when the model is held constant. For Claude Opus 4.6 in non-reasoning mode, Bedrock leads on output speed and time-to-first-token, while blended pricing is flat across providers. For Claude 4.5 Haiku in Reasoning mode, Bedrock leads at 127.7 tokens/second, while Vertex, Anthropic and Azure tie for the lowest blended price.

For Claude Opus 4.6 Max, Bedrock leads output speed at 63.2 tokens/second, while Azure offers the lowest time-to-first-token. A route that starts responding first need not finish generating first, so a primary route depends on which delay the workload needs to minimize.

AWS commitment discounts, volume contracts and prompt caching can change the effective price, with cached prefixes reducing repeat-query costs significantly. Routing can therefore optimize normal operation as well as recover from outages. Doing so requires the routing layer to hold credentials and health state for all active routes simultaneously, rather than treating the secondary provider as an untested emergency endpoint.

The failover architecture and where routing logic belongs

Each route introduces different authentication, error codes and health characteristics, and embedding those differences in application logic makes the application responsible for infrastructure behavior. A dedicated layer should instead map a shared model name to provider-specific identifiers and authenticate to each destination that can be used. The application keeps a stable interface. The routing record identifies which provider actually served the request.

A regional switch within Bedrock can remain inside AWS infrastructure, whereas a switch from Bedrock to Vertex or the direct API requires a layer above both services. A Bedrock-fronted deployment cannot transparently reach Vertex during a Bedrock outage without that additional layer. DNS health checks can support failover, but they do not replace the authentication and model-identifier translation that crossing providers requires.

Health checks should exercise inference. A small test prompt can measure response time against a latency budget, while error rates over a short window can identify an unhealthy endpoint. DNS-level failover can switch routes in well under a few minutes with the standard configuration, and fast-interval checks and a pre-lowered TTL can make it switch faster. Application retries remain useful for transient failures, but should not be the primary recovery mechanism.

Authentication failure needs to be handled on its own because trying the same broken authentication path again cannot restore access. A tested fallback to a different path, such as Bedrock’s IAM, provides an independent option. Managed gateways can supply this dedicated infrastructure boundary so the application does not have to choose the provider. The architectural requirement remains the same whether the gateway is managed or self-hosted.

The retirement-date problem and four independent clocks

Outages are not the only reason a route stops working. Retirement dates also belong to providers, and the gap between the first and last retirement for the same model ID can exceed four months. AWS states that “for Amazon Bedrock usage, only the dates on this page apply”. Teams that read only the model maker’s announcement may get the wrong migration deadline for Bedrock calls.

Azure’s lifecycle clock starts at its own general availability date. Its retirement date is set programmatically at launch and is not extendable, while Anthropic’s deprecations page explicitly excludes Bedrock and Google Cloud from its schedule. Vertex AI’s release notes give August 23, 2026 as the shutdown date for Claude 3 Haiku. That deadline applies specifically to that route.

Provider attribution consequently serves lifecycle planning as well as incident response. A shared model alias does not reveal which deadline applies to a request. The provider and its model identifier do. Logging both gives teams a record they can audit of which deployments are running out of time to migrate.

Spend visibility across four providers without a unified layer

Uber gave engineers access to Claude Code in December 2025 and exhausted its annual AI budget by April 2026. A FinOps Foundation executive described tracking token costs as a trillions-of-rows-a-month problem that teams “can't just stick into whatever spreadsheet or even basic tool”. Separate provider invoices do not supply the workflow context needed to explain that consumption.

Routing is the point where usage and ownership meet. Each call needs its exact model name, input and output token counts, timestamp and originating workflow captured before those details become disconnected billing records. Attribution must span team, project, key, model and provider simultaneously. A total for a cloud vendor cannot show which project’s fallback traffic raised the cost or which team’s token use is close to its budget.

Visibility and enforcement are different functions. A dashboard reports costs already incurred, while a gateway can check a team’s token budget before allowing a request and block the call when that budget is exhausted. That capability must be established in the routing implementation.

Security and compliance obligations that differ by provider route

After failover, different data protection terms can apply to the same prompt. Bedrock’s EU Inference Profile provides contractually guaranteed EU-region inference, while Vertex’s EU regional and multi-region endpoints must be distinguished from its global processing route. Vertex’s global processing has CDPA guarantees but not geographic inference pinning. The supplied residency descriptions conflict on whether Bedrock is the only guaranteed EU route, so that exclusivity claim cannot safely determine a fallback policy.

The Microsoft Q&A thread describes a separate limitation for Foundry. Its accepted answer says the expected EU residency guarantees were not yet available and gives no more specific public date for their arrival. The Azure Preview status described here also prohibits personal data. Consequently, switching from a Bedrock EU route to Vertex global processing or Azure cannot be treated as a neutral infrastructure substitution merely because Claude’s weights remain unchanged.

Sensitive-data policy must constrain route eligibility before availability decides the destination. PII and PHI redaction belong at a single upstream chokepoint, before any provider receives the prompt. Delegating that work to individual application teams leaves protection dependent on every request path being implemented correctly. A gateway can apply the same redaction policy across all four routes, while the agreements that apply still decide what is covered downstream.

Access controls require the same consistency. RBAC, SSO and audit logs implemented separately at each provider produce four permission systems and four audit trails, with gaps wherever configuration is incomplete. Central enforcement makes the routing layer the common policy boundary. It does not make a provider’s data-processing terms or BAA coverage irrelevant.

Build versus buy for the routing layer

The practical choice is data custody and operational capacity. LiteLLM is a credible open-source option for teams that want to self-host the routing layer. Prompts, responses and provider keys can remain within the team’s VPC or on-premises network. That keeps custody under the team’s control. It also keeps out a managed gateway vendor whose DPA changes would need another legal review.

A managed gateway trades that control for less infrastructure work. There is no proxy for the team to deploy and no routing-layer on-call rotation to staff, allowing engineers to focus on product work instead. The additional vendor-controlled hop is the strongest objection. Its data-processing terms, subprocessors and retention policies must pass legal review, and its DPA must be reviewed again when it changes.

Teams that need custody within their own network and have the capacity to operate the gateway have a sound case for self-hosting. Teams without that operational capacity have a sound case for a managed service whose controls and agreements satisfy their requirements. Neither choice is permanent, and teams can move from managed infrastructure to self-hosting as volume, custody requirements or operational capacity change.

What the routing layer must log to make failover auditable

An unlogged failover leaves a gap in both financial and compliance evidence. The request record must identify the provider that served it, the model identifier presented to that provider, whether failover occurred and which route became the fallback. The model alias alone is insufficient. Without the provider-specific identifier, the record cannot establish which lifecycle schedule applies.

The same record must connect consumption to ownership. Input and output token counts, timestamps, and the originating team, project and key support spend attribution, budget enforcement and RBAC review. Redaction evidence must also show whether PII or PHI redaction ran and what was redacted.

Agentic workloads extend that obligation beyond inference calls. As of 2026, engineering teams are asking gateways to govern MCP tool access, agent-to-agent communication and the associated compliance trails. Claude Cowork, Anthropic’s desktop runtime for enterprise, makes the broader control surface concrete through its LLM gateway, MCP allowlist, org-plugins folder and MDM policy file.

The practical test is a single log query. It should establish which provider served a request, at what cost, with what data, under which compliance agreement, and whether it failed over. When that evidence is available together, reliability, finance, security and lifecycle planning can work from the same record of what actually happened.