A governance analysis of resilience, redundancy, and the cost of diversifying AI providers.
Dependence on a single generative AI provider is no longer merely an architectural decision; it has become a corporate and governance risk. The past eighteen months have repeatedly shown that even the most sophisticated infrastructure operators fail. For organizations that have incorporated AI into critical processes, this creates concentration risk: a single point of failure with the potential for material impact.
The most immediate response is usually to adopt more than one provider, which reduces some exposure but also introduces new costs and dependencies. In practice, this is a risk-transfer decision: it expands the governance surface, increases operational complexity, and, when redundancy exists only in the diagram, can create a false sense of security.
The central point of this article is that this choice should be based on proportionality, rather than treated as a binary decision between one or multiple providers: size the architecture to the function's criticality, verify that redundancy is supported by infrastructure rather than just logos, treat silent quality degradation as a different problem from failover, and consider reversibility and exit strategy governance requirements.
The recent history#
The idea that AI providers should be treated as reliable infrastructure by default does not hold up against recent incidents. The observed failures can be grouped into three classes, each requiring a different response.
Provider-level unavailability is the most visible class: OpenAI experienced a global outage in April 2026, simultaneously affecting ChatGPT, Codex, and the API platform, and an even broader event in June 2025, when its own status page reported more than twenty degraded components at the same time, suggesting an architectural failure rather than an isolated component failure. At Anthropic, June 2026 saw dozens of incidents in a single month, totaling hours in an incident state, with individual episodes exceeding six hours.
Failure of the cloud infrastructure supporting the service is less visible and often underestimated: in October 2025, a race condition in DynamoDB's DNS system took down AWS's us-east-1 region for about fifteen hours; the failure affected around 140 AWS services, including Amazon Bedrock, and roughly a thousand customer companies and applications reported interruptions. This was not the only case during the period: AWS experienced physical data center events (a fire at a Middle East facility in March 2026 and a thermal event in May of the same year), and Azure OpenAI Service suffered about seven hours of multiregion degradation in May 2026, originating in retry amplification from an internal workload. For those designing resilience, the implication matters: the model provider and the cloud used to serve it may belong to the same failure boundary.
Silent quality degradation is the hardest class to detect because the service remains available and does not trigger an availability alarm: between August and September 2025, three overlapping bugs compromised Claude's responses without taking the service down; at the peak, about 16% of one model's requests were misrouted, with different symptoms depending on the platform. Similar behavioral problems also affected development tools in early 2026. In such situations, the API keeps responding and traditional indicators remain green, but output quality has already been compromised. An availability dashboard alone does not identify this type of failure.
These episodes did not occur at inexperienced operators or experimental platforms; they involved some of the most mature model and infrastructure providers in the market. Assuming that recurring failures will not happen is therefore a management decision, not a technical conclusion.
A taxonomy of five risks#
To make an appropriate decision, we must recognize that dependence on a single provider concentrates five different risks:
Provider unavailability: the service or API goes down. This is the most visible risk and the easiest to mitigate with redundancy.
Cloud infrastructure failure: the region or infrastructure layer hosting the service fails, taking down the systems and models that depend on it. When the model and the cloud share the same failure boundary, model redundancy no longer provides protection.
Single-origin quality degradation: the model starts producing worse responses because of a defect in its own service layer. Because it has a single origin, it propagates to all clouds serving it at the same time and escapes mitigation through failover.
Access, regulatory, or contractual risk: the provider suspends or restricts a model (because of export controls or a policy change, for example), deprecates a version, or changes terms or prices. The decision is theirs.
Commercial lock-in and loss of bargaining power: the deeper the dependence, the less leverage there is in negotiations, support, and the roadmap. This risk is more financial and strategic than operational in nature.
Each risk requires a different response. The most common mistake, and often the most expensive, is trying to address them all in the same way: adding a second provider.
The real scope of multiple providers#
Adopting more than one provider is an effective response to the first two risks in the taxonomy: supplier unavailability and cloud infrastructure failure. This strategy also became more viable throughout 2026, with convergence moving in both directions. In June, OpenAI's leading models arrived on Amazon Bedrock, enabling OpenAI and Anthropic frontier models to operate side by side within the same identity, billing, and governance layer. That same month, Claude models became generally available in Microsoft Foundry, hosted on Azure's own infrastructure. This weakened the historical association between choosing a laboratory and necessarily depending on a particular cloud. Claude, in particular, came to be served on all three major clouds, in addition to the direct API.
Enlarge ↗This possibility, however, should not be confused with a complete solution. A multiprovider architecture can reduce the impact of one supplier's unavailability, but it does not eliminate quality degradation or failures in shared infrastructure. It also introduces new costs, dependencies, and operational risks, discussed in the next section.
The pitfalls of diversification#
Diversification has a cost, some of which only becomes apparent when the alternative path must be activated. The main pitfall lies in the difference between the redundancy designed and the redundancy that actually exists in the infrastructure. When two providers share the same cloud, region, or backend, a single incident can affect both. The relevant mapping must therefore consider the provider, cloud, region, and model origin; the number of logos in the diagram says little about the actual failure boundary. This is the logic behind the matrix presented in Appendix A.
A recent launch makes the pitfall concrete. Claude Platform on AWS, generally available since May 2026, offers access through IAM credentials, consolidated billing, and CloudTrail logs, but inference runs on Anthropic's first-party platform, with data processed outside the AWS boundary. AWS itself classifies it as a third-party offering, outside its compliance programs (SOC, ISO, HIPAA eligibility). In the diagram, the service appears as a second path within AWS, while its failure boundary remains that of Anthropic's direct API, with a different entry point.
Enlarge ↗Diversification also does not resolve single-origin failures. When the problem is in the model itself or a shared service layer, it can manifest simultaneously on every platform offering it. In that scenario, failover merely directs traffic to another instance of the same degraded model.
Each additional provider also expands the governance surface. This means adding another data processor, contracts and processing agreements, audit scope, third-party risk assessment, and potential attack points. In a regulated institution, this overhead must be anticipated, funded, and monitored like any other operating cost. Technical complexity grows in the same proportion. Providers adopt different SDKs, authentication mechanisms, limits, and error behaviors. There is also a less obvious difference: prompt sensitivity. An instruction that works well with one model can produce different results with another, requiring observability, evaluations, and guardrails specific to each route. Platform equivalence must be demonstrated; it can rarely be assumed.
Another effect of diversification is the possible loss of access to the latest capabilities. Building a solution using only the features common to every provider tends to constrain the architecture to the lowest common denominator. Furthermore, models offered by cloud platforms may expose only some of the capabilities available in the native API. In some cases, therefore, diversifying also means sacrificing innovation speed. There are also direct costs: redundant capacity, gateways, integration, duplicated testing, and the need to maintain technical expertise across multiple platforms. Redundancy works like an insurance policy and only makes sense when its cost is proportional to the risk it aims to cover.
Data residency and jurisdiction also become more complex. A cloud's physical region does not necessarily correspond to the jurisdiction the model provider applies to storage, processing, or support. When regulated data is involved, each new path requires its own analysis.
The most serious risk, however, is the false sense of security. An architecture can look resilient on paper while remaining subject to the same correlated failures. When this happens, the organization tends to invest less precisely in the risks that remain open, such as quality degradation and shared infrastructure. Redundancy reassures management without actually reducing exposure.
The same model, different behaviors#
The previous section presented behavioral differences between channels as one of the costs of a multiprovider strategy. The topic deserves particular attention because it challenges a common assumption in redundancy projects: the idea that the same model will behave identically regardless of the channel used to access it. That assumption is true at one level, but not at every level. At the weights level, equivalence tends to be high. When calling the same model version through the supplier's direct API or through a hyperscaler, using the same parameters, very similar behavior is expected. The model identifier, context window size, and semantics of supported tools are generally preserved.
If the analysis ended there, the channels could be treated as interchangeable. In practice, however, observed behavior depends on everything surrounding the model: the available version, filters, guardrails, compute capacity, loaded tools, platform policies, and orchestration approach.
Version skew: a model with the same name may not correspond to the same version in every channel at the same time. New versions usually arrive first in the direct API and are then made available on hyperscalers, often through a gradual regional rollout. During that interval, two channels may serve different versions of what the customer understands to be the same model. For a contingency architecture, this difference can produce unexpected changes in quality and behavior at failover time.
Platform-injected layers: content filters and guardrails also vary between channels. A response allowed by the direct API may be altered, blocked, or refused along another path. In these cases, the difference is not in the model's weights but in the policies and controls applied by the hosting platform.
Preview versus general availability: maturity also influences reliability. A preview version may operate with more limited capacity, additional restrictions, or higher error rates than those observed after general availability. In one case recorded in 2026, a preview image-generation model experienced approximately 45% errors at the peak. The model was the same, but its operational reliability varied according to its availability stage in each channel.
Harness and orchestration: the harness can alter behavior even when the model, code, and machine remain the same. In one public case involving a coding agent, execution through the direct API loaded 26 tools, while the hyperscaler path made 45 available. With fewer tools, the agent began taking smaller, more cautious steps, tripling both the number of calls and total task time. Token generation speed was practically identical. What changed was the environment provided to the model. This example shows that an application's behavior depends on more than the selected model. It also depends on the tools, instructions, policies, and orchestration mechanisms composing its harness.
Data policy and jurisdiction by channel: data-processing policies can also vary within the same ecosystem. A channel intended for prototyping may use prompts and responses to improve the service, while an enterprise offering may contractually exclude that use. Similarly, selecting a local region does not automatically eliminate every jurisdictional issue. On some platforms, the law of the supplier's home country may remain relevant regardless of the chosen processing region. Cloud region, data residency, and applicable jurisdiction should therefore not be treated as equivalent concepts.
The clearest example so far comes from the same supplier at the same entry point. On AWS, Claude through Amazon Bedrock keeps data within the AWS boundary, with AWS as processor and coverage under the cloud's own compliance programs; Claude Platform on AWS, accessed with the same IAM credentials and billing, has data processed by Anthropic outside that boundary, without coverage under those programs. Two offerings accessed through the same AWS account can therefore have opposing data regimes.
Even when paths use genuinely independent infrastructure, behavioral equivalence must be tested before an alternative channel is incorporated into the continuity plan. The matrix in Appendix A also highlights a structural difference between suppliers. Some distribute their models across several independent clouds, now reaching four distinct inference stacks for the same model, enabling real redundancy while requiring behavioral validation on each path. Others have historically concentrated their most advanced models on a single cloud, making much of the redundancy between channels more apparent than effective. There are also suppliers whose models are available only on their own infrastructure. In that case, the different channels still rely on the same processing and serving layer.
For a critical function dependent on that type of supplier, the only genuinely external redundancy may require changing the model, not just the channel. Four governance controls follow from this scenario:
Explicitly pin the version by channel: the organization should record the version used on each path and monitor any differences between them.
Normalize parameters and guardrails: equivalent settings should be applied wherever possible. Differences that cannot be eliminated must be documented.
Evaluate each model-and-channel combination separately: a test suite approved on one channel should not automatically be considered valid on another.
Map data policy and jurisdiction by path: data treatment, retention, processing, and access conditions may change even within the same provider.
In a resilient architecture, therefore, the same model does not necessarily mean the same behavior. The channel is also part of the unit that needs to be tested, monitored, and governed.
The regulatory perspective#
The topic fits best within third-party concentration risk and operational resilience, an area receiving growing attention from financial regulators.
Internationally, DORA, the European digital operational resilience regime for the financial sector, explicitly addresses concentration risk in third-party ICT providers. Among other requirements, it calls for exit strategies, substitution capability, and testing for critical functions. The European AI framework also establishes obligations for systems classified as high risk. Frameworks such as the NIST AI Risk Management Framework help translate reliability, robustness, and continuity into structured, measurable, auditable controls.
In Brazil, the logic is similar. CMN Resolution No. 4.893/2021, updated by CMN Resolution No. 5.274/2025, addresses cybersecurity and the contracting of data processing, storage, and cloud computing services by financial institutions. Although it does not use the expression “concentration risk” as explicitly as DORA, it incorporates principles of continuity, reversibility, and third-party management. The LGPD also enters this analysis. A multiprovider architecture can expand the number of processors involved in data processing, transfer flows, and contractual and operational responsibilities. Each new path therefore adds obligations that must be assessed and governed.
Regulatory references should always be checked against the current text and the interpretation of legal, regulatory, and compliance teams. For this article, the main point is the governance principle running through these different regimes. The common message is clear: concentrating a critical function in a single third party represents significant risk, and an organization is expected to have a documented exit strategy and an effectively tested ability to replace it.
Excessive dependence on a single provider can become a governance finding. So can the uncontrolled proliferation of suppliers. Maturity means avoiding both extremes.
A decision framework#
The choice between a single provider and a multiprovider architecture should consider two variables: the function's criticality and switching cost, meaning the solution's degree of reversibility.
Enlarge ↗The matrix also helps answer when multiple providers are not justified. For functions with low criticality and low switching costs, redundancy tends to add expenses, complexity, and governance obligations without reducing a material risk. In that scenario, a single provider may be the most appropriate decision.
Six principles guide the application of the matrix:
Stratify by criticality: reserve redundancy for functions where unavailability, degradation, or excessive dependence could materially affect the business.
Adopt an abstraction layer: a gateway decouples the application from providers through a common interface. With that layer, switching or redirecting traffic can become a configuration decision. Without it, each new provider increases coupling and technical debt.
Require genuine infrastructure independence: alternative paths should be assessed by cloud, region, model origin, and other shared dependencies. When two paths lie within the same failure boundary, they should be treated as one for resilience purposes.
Treat degradation separately: failover addresses unavailability but does not guarantee quality. Degradation requires a different set of controls: continuous production evaluations, version pinning, rollback, and canary deployments.
Treat reversibility and exit as first-class requirements: the exit strategy must be documented, tested, and contractually feasible. The question “how quickly can we migrate?” should have a rehearsed answer, not merely an estimate.
Size governance accordingly: each new provider expands the scope of third-party management, data-processing agreements, security, monitoring, and auditing. Diversification remains sustainable only while the organization can govern that complexity.
Questions for senior management#
For every critical function supported by AI, senior management should be able to answer:
What is the actual blast radius, considering provider, cloud, region, and model origin?
Where are the shared dependencies and failure boundaries?
Does the declared redundancy use genuinely independent infrastructure, or does it protect only against one supplier's unavailability?
Is there a documented and tested exit strategy? How quickly can the organization actually migrate?
How does the company identify silent quality degradation, rather than just unavailability?
Has each additional provider undergone third-party risk assessment, a data-processing agreement, and audit scope definition?
Is the cost of redundancy proportional to the criticality of the function it protects?
Who is accountable for this risk at the executive level?
The inability to answer any of these questions is itself already a governance finding.
Conclusion#
The decision is not simply about choosing one or several providers. The central issue is understanding which failure modes the organization is exposed to, which can cause material impact, and what response is proportional to the risk and feasible to govern.
Dependence on a single supplier represents a real and recurring concentration risk. A multiprovider strategy can reduce some of that exposure, but it also transfers risk into new layers of cost, complexity, and governance. When poorly implemented, it creates only the appearance of resilience and can conceal dependencies that remain intact.
Maturity involves three moves: aligning the architecture with each function's criticality, verifying that redundancy actually exists in the infrastructure, and treating quality degradation and reversibility as central requirements. Diversification is a control and, like any control, must be justified, sized, tested, and governed.
Appendix A - Exposure matrix by provider and access path#
The matrix below translates the article's central thesis into practical terms: an alternative path only increases resilience when its infrastructure is genuinely independent of the primary route. The last two columns contain the most important interpretation. If paths share a cloud, region, backend, or model origin, they belong to the same failure boundary. In that case, they must be treated as a single path for continuity purposes, even if they appear as different providers in the diagram.
Enlarge ↗How to use the matrix in routing decisions#
Combinations such as Claude through the direct API and Vertex AI, Claude through Bedrock and Azure-hosted Foundry, or GPT through Azure OpenAI and Amazon Bedrock offer genuine redundancy because they rely on distinct infrastructure. Claude is currently the only case where the same model runs on four independent inference stacks: Anthropic's own infrastructure, AWS, Azure, and Google Cloud.
The combinations that merely appear redundant have also increased. OpenAI's direct API and Azure OpenAI remain within the same failure boundary, just as Claude and GPT running on Bedrock in the same region remain exposed to the same cloud event. The new case is on Anthropic's side: the direct API, Claude Platform on AWS, and Anthropic-hosted Foundry are three entry points into the same first-party stack and count as a single path for resilience purposes, even though two use hyperscaler credentials and billing. Conversely, Claude through Azure-hosted Foundry comes to share Azure's failure boundary with Azure OpenAI.
Gemini remains the most restrictive case. Because its channels sit within the Google Cloud ecosystem, switching between the direct API, AI Studio, and Vertex AI does not create multicloud redundancy; they all continue to rely on the same infrastructure stack. For a critical function based on Gemini, genuinely independent redundancy requires adopting another model, not merely changing the channel.
Appendix B - Reference incident register (2023–2026)#
This appendix brings together the evidence supporting the analysis in the “The recent history” section. Durations are approximate and, for the Claude incidents in June 2026, events were consolidated because they involved multiple occurrences throughout the month. The Class column follows the taxonomy presented in the “A taxonomy of five risks” section.
Enlarge ↗The historical record shows that classes ① provider unavailability and ② cloud infrastructure failure are the most frequent and also those that can be mitigated through genuine redundancy. Class ③ quality degradation appears less visibly but recurrently. Because it can simultaneously affect different access channels to the same model, failover alone does not resolve it. In these cases, the API remains available, but output quality has already been compromised. Class ④ access, regulatory, or contractual occurs less often but can have longer-lasting impacts and is outside the customer's direct control. The episode involving Mythos 5 and Fable 5 shows that this type of restriction can also be reversed, but not necessarily within the timeframe the organization expects. The most severe class ② incidents during the period (us-east-1 in October 2025 and Azure OpenAI in May 2026) affected cloud paths, not just suppliers' direct APIs. This reinforces a central point of the article: the most relevant failure boundary often lies in the infrastructure serving the model, not in the laboratory that developed it.
Including Gemini adds two important pieces of evidence to the argument in the “The same model, different behaviors” section: first, because it remains concentrated in Google's ecosystem, the model has no genuinely multicloud contingency path. The incident on 27 February 2026 even affected the São Paulo region, which is particularly relevant to operations depending on local processing; second, different channels from the same provider can have their own failure surfaces. Problems observed in AI Studio Build, related to dependencies such as Cloudflare and esm.sh, show that changing channels does not necessarily eliminate risk; in some cases, it merely shifts the dependency to another architectural layer.
Sources and references#
Official postmortems and write-ups#
Anthropic - A postmortem of three recent issues (September/2025, degradation August–September/2025): anthropic.com/engineering/a-postmortem-of-three-recent-issues
Anthropic - An update on recent Claude Code quality reports (April/2026, degradation March–April/2026): anthropic.com/engineering/april-23-postmortem
OpenAI - March 20 ChatGPT outage: Here's what happened (redis-py incident, March/2023): openai.com/index/march-20-chatgpt-outage
OpenAI - write-up of the 09–10/06/2024 incident (systemd-networkd): status.openai.com
OpenAI - write-up of the 03–04/02/2026 incident, related to the feature gate cache: status.openai.com
AWS - Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region(19–20/10/2025): aws.amazon.com/message/101925
Microsoft Azure - Post Incident Review LYXT-C1Z, Azure OpenAI Service (29/05/2026), available in the official status history: azure.status.microsoft/en-us/status/history
Official status pages and histories#
Sources used for incidents without a dedicated write-up, including 22/05/2024, 26/12/2024, 03/09/2025, Sweden Central on 27/01/2026, the us-east-1 thermal event on 07/05/2026, and Anthropic's series of incidents in June 2026:
Anthropic: status.claude.com, history accessed on 03/07/2026
OpenAI: status.openai.com
Microsoft Azure: azure.status.microsoft/en-us/status/history
AWS Health Dashboard: health.aws.amazon.com/health/status
AWS Post-Event Summaries: aws.amazon.com/premiumsupport/technology/pes
Suspension of Fable 5 and Mythos 5#
Anthropic - Statement on the US government directive to suspend access to Fable 5 and Mythos 5 (12/06/2026): anthropic.com/news/fable-mythos-access
Fortune - coverage of the suspension (13/06/2026): fortune.com
CNBC - withdrawal of controls and return of Fable 5 (30/06/2026): cnbc.com
Technical press coverage#
Bloomberg - Claude outage on 02/03/2026, attributed to “unprecedented demand”: bloomberg.com
Data Center Dynamics - fire at an AWS data center in ME-CENTRAL-1 on 01/03/2026: datacenterdynamics.com
TechRadar - global ChatGPT, Codex, and API outage on 20/04/2026: techradar.com
ThousandEyes - analysis of OpenAI's systemic incident on 10/06/2025: thousandeyes.com
Fortune - coverage of the Claude Code postmortem on 24/04/2026: fortune.com
Simon Willison - note on the postmortem of OpenAI's incident on 11/12/2024, referencing the official write-up: simonwillison.net
InfoQ - analysis of AWS's postmortem for the us-east-1 incident in October 2025: infoq.com
Multicloud availability#
AWS - OpenAI models and Codex on Amazon Bedrock are now generally available (01/06/2026): aws.amazon.com/blogs
InfoQ - coverage of general availability on Bedrock after the end of the Azure exclusivity arrangement: infoq.com
Microsoft Azure - Claude in Microsoft Foundry is now generally available (June/2026): azure.microsoft.com/en-us/blog/claude-in-microsoft-foundry-is-now-generally-available/
Anthropic - Claude in Microsoft Foundry (June/2026): claude.com/blog/claude-in-microsoft-foundry
Microsoft Learn - Claude models in Microsoft Foundry (Hosted on Azure and Hosted on Anthropic modes, regions, and deployment types): learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/claude-models
AWS - Claude Platform on AWS (official service page, including the description of processing outside the AWS boundary): aws.amazon.com/claude-platform/
AWS Docs - Claude Platform on AWS vs Amazon Bedrock (classification as a third-party offering outside AWS compliance programs): docs.aws.amazon.com/claude-platform/latest/userguide/cpa-vs-bedrock.html
Regulatory references and frameworks#
DORA - Regulation (EU) 2022/2554: eur-lex.europa.eu
EU AI Act - Regulation (EU) 2024/1689: eur-lex.europa.eu
NIST AI Risk Management Framework: nist.gov
CMN Resolution No. 4.893/2021: bcb.gov.br
CMN Resolution No. 5.274/2025: bcb.gov.br
LGPD - Law No. 13.709/2018: planalto.gov.br
Transparency note: records of Sonnet 4.5 instability through Bedrock in Europe in October 2025, and Claude Code 500 errors on 4 February 2026, are based on community reports and developer discussions on GitHub. No official write-up was found for these events, so they are not linked to a primary source in this list.
Incident references are based on public status and press data from 2023–2026; regulatory references are illustrative and should be checked against the current regulatory text before any formal application.