Disaster recovery (DR) planning asks two questions of every system: how long can it be down (Recovery Time Objective, RTO), and how much data can be lost (Recovery Point Objective, RPO). Applying those questions to Claude on Microsoft Foundry produces an unusual answer, because the Foundry side of your architecture is close to stateless — and that reshapes where the planning effort should go.
RPO first: what state actually lives in Foundry?
A Foundry resource holds configuration — security and billing settings, and the deployments inside it. Each Claude request is self-contained: you send the full conversation, the model responds, and the response's usage object tells you what was consumed. Conversation history, prompts, retrieved documents, and outputs live in your systems (your database, your queue, your logs), not in the model service. Two nuances: Foundry does have a beta Files API on Hosted-on-Anthropic deployments, so if you use it, uploaded files are provider-side state your DR plan must account for; and prompt caches are ephemeral performance state — losing them costs money and latency on re-warm, not data.
Practical consequence: for most Foundry applications the model-service RPO is effectively zero if your own state stores are protected. The real RPO exposure is in your application: in-flight requests at failure time, and any outputs you hadn't persisted. Design for idempotent, replayable requests — a queue in front of Claude calls means a failed call is retried, not lost.
RTO: rebuilding versus rerouting
Because the provider-side state is just configuration, you can meet an RTO two ways.
Rebuild (cold standby). Keep the Foundry resource and deployment definitions in infrastructure-as-code — the Claude starter kit's Bicep/Terraform templates are a reference — and re-provision into the surviving region on demand. Cheapest, but your RTO includes provisioning time, Marketplace terms acceptance in a fresh subscription if applicable, and any manual steps you never automated. Test the rebuild, or it isn't a plan.
Reroute (warm standby). Run a second resource and deployment in the other supported region ahead of time and switch traffic when the primary fails. Foundry's Global Standard region list is short — East US2 and Sweden Central — so the topology designs itself; multi-region Foundry deployments covers the routing mechanics. A warm standby deployment with pay-as-you-go billing costs nothing while idle beyond its maintenance overhead, since Claude usage in Foundry is metered on consumption (billed in Claude Consumption Units through Azure Marketplace), which makes the warm option unusually affordable compared to classic DR.
model value in requests and immutable after creation), keep both endpoints in configuration, and your failover reduces to swapping ANTHROPIC_FOUNDRY_RESOURCE or the base URL — no code change.One capacity caveat carries over from the multi-region article and belongs in every Foundry DR runbook: quota is subscription-level, and Global Standard deployments of the same model and version share one pool across regions. Failover moves traffic; it does not add throughput. If the disaster scenario includes retry storms, expect 429s and back off — don't bounce between regions that share the same budget.
What Foundry's availability commitments cover
Be precise about the promise stack under your application. Claude models in Foundry are Anthropic-operated Marketplace offerings in two hosting flavors — Hosted on Azure (GA, running end-to-end on Azure infrastructure) and Hosted on Anthropic infrastructure (running outside Azure). Microsoft's and Anthropic's public docs describe operation and support arrangements, but this guide won't paraphrase service-level agreements: check the Azure Marketplace offer terms and your agreements for the actual availability commitments, and note that any such commitment is typically a service credit mechanism, not a guarantee your dependent flow stays up. A model service being "available" also doesn't cover your failure modes above it — quota exhaustion, an expired key, a revoked role assignment, or a broken prompt deploy will take you down while the platform is green. Your DR plan should treat "Foundry is up but we can't use it" as a first-class scenario.
Also decide, with your compliance team, whether failover may change data-handling posture: Azure-hosted deployments keep prompts and outputs processing on Azure infrastructure with data at rest in the selected geography, while Hosted-on-Anthropic deployments may process data outside Azure. If your primary is a US Data Zone deployment, failing over to a Global deployment changes residency behavior — that trade-off belongs in the runbook, approved in advance, not improvised mid-incident.
The degraded-mode option nobody writes down
Not every Claude feature needs the same RTO. A DR tier worth designing: fall back to a smaller model (a claude-haiku-4-5 deployment costs nothing to keep alongside), shed non-essential AI features behind a flag, and queue the rest for replay. "Summaries are delayed an hour" is often an acceptable disaster posture; "the app is down" rarely is.
Where to go next
Pair this with multi-region deployments for the routing layer and Azure support plans for Foundry for the incident path; multi-platform failover covers surviving a whole-provider outage.