Blog
AVD disaster recovery architecture: how to design for resilience across Azure regions
Plan AVD disaster recovery architecture with active-active host pools, FSLogix Cloud Cache, identity failover, and automation.
Table of Contents
- Why the ownership boundary shapes everything
- Active-active, active-passive, or Azure Site Recovery: choosing your disaster recovery posture
- FSLogix profile replication (where your real RPO lives)
- Identity and networking dependencies that break failover
- Golden image and application consistency across regions
- Setting RTO and RPO targets and testing them without breaking Azure Virtual Desktop
- How Nerdio Manager automates multi-region Azure Virtual Desktop disaster recovery
- What this means for your Azure Virtual Desktop disaster recovery architecture
- Frequently asked questions about Azure Virtual Desktop disaster recovery architecture
Your primary Azure Virtual Desktop deployment region goes dark at 9:15 on a Tuesday morning. Two thousand session hosts vanish, profile shares stop responding, and the help desk queue fills with people who can't log in to do their jobs.
Azure Virtual Desktop's managed control plane includes resilience, while customer-owned layers such as session hosts, profiles, apps, data, and identity need a separate disaster recovery design. That ownership boundary is the design constraint that defines every decision you'll make.
This guide is for Azure Virtual Desktop platform owners and end-user computing (EUC) leaders designing multi-region disaster recovery at enterprise scale. Windows Cloud, Microsoft's umbrella for Windows 365 and Azure Virtual Desktop, gives enterprises two cloud desktop paths that often coexist; this article focuses on the Azure Virtual Desktop architecture decisions that determine regional resilience.
Those decisions include Microsoft-documented architectural patterns, FSLogix profile management mechanics that determine recovery point, identity and networking dependencies that affect failover, and automation for orchestration that teams would otherwise run manually.
Why the ownership boundary shapes everything
Microsoft and you split disaster recovery responsibility along a clear line, and where that line sits drives every design choice that follows. The managed control plane has resilience built in. Everything that actually delivers a desktop to a user is your job.
Microsoft's side is straightforward. The Azure Virtual Desktop control plane is Microsoft's responsibility. Host pool metadata lives in a per-region database with replicas across availability zones, and that metadata replicates to a paired region for cross-region failover. The gateway and connection broker infrastructure is global and highly resilient. If a control plane outage hits, those components automatically switch to healthy replicas in another zone or region with no setup on your part.
Your side is where the work lives. Session host VMs, FSLogix profiles, applications, user data, and identities all sit in your column, and Microsoft defines that split in its disaster recovery concepts documentation. You compose Azure services into the disaster recovery posture for each layer, and that's where management complexity increases.
The first real decision is which disaster recovery pattern matches your recovery targets and your budget.
Active-active, active-passive, or Azure Site Recovery: choosing your disaster recovery posture
The pattern you pick determines your recovery time, your steady-state cost, and how much work your team faces on the morning things go wrong.
Microsoft documents BCDR options for Azure Virtual Desktop, including Azure Site Recovery and secondary host pools, and the right fit depends on two factors. The first is your host pool design. The second is how much downtime and data loss you can tolerate, expressed as your recovery time objective (RTO, how long the service can be unavailable) and recovery point objective (RPO, how much data loss is acceptable).
Active-active for multi-session pooled host pools
In an active-active design, you deploy one multi-session pooled host pool per region across two Azure regions, a primary and a secondary, and both host pools serve users in steady state. When an outage hits one region, the other already has live capacity ready to absorb the load. Microsoft's business continuity guidance confirms that no administrator intervention is needed for failover.
That resilience comes at a price. Each host pool runs its own storage account, FSLogix Cloud Cache syncs profiles across regions asynchronously, and users must never access both host pools at the same time or you risk profile conflicts.
The planning trade-offs follow from there. Active-active can deliver near-zero RTO, while RPO depends on how far Cloud Cache replication lags behind in any given moment. Steady-state cost runs high because you're paying for dual compute and dual storage around the clock.
Active-passive for cost-conscious resilience
In an active-passive design, the primary host pool carries all production traffic while a secondary host pool sits in another region with reduced compute or none at all. When the primary region fails, users get reassigned to the secondary, which scales up to absorb the load. The pattern is the right choice when it meets your RTO and RPO without paying for dual full-capacity environments around the clock.
Capacity planning is the catch. Azure only guarantees VM capacity when the VMs are actually running, so a cold secondary that's sized to zero in steady state can't assume the region will have headroom on the day you need it. On-demand capacity reservations close that gap by holding Azure capacity for your disaster recovery scenario in advance.
The trade-offs follow from the cold-start design. RTO depends on how quickly compute comes online in the secondary region. Steady-state cost lands in the middle, well below active-active but above doing nothing. Failover itself requires real admin work, including group reassignment and capacity scaling, so the team needs runbooks and rehearsal time.
Personal host pools and Azure Site Recovery
Personal (dedicated) desktops carry persistent user state on the VM itself, so rebuilding from a golden image throws away the user's data. Azure Site Recovery (ASR) is the recommended approach for these pools. VMs continuously replicate to a target region and can be failed over during an outage, and that target region should align with the disaster recovery region of the storage back end FSLogix uses.
ASR creates crash-consistent recovery points every five minutes by default, and this interval can't be modified. RTO depends on failover and reprotect time, RPO is driven by those recovery points, and failover triggers per VM. ASR is also supported for multi-session pooled host pools, but it's optional there because deploying another host pool in the secondary region is usually the simpler path.
One terminology note before moving on. Microsoft's Well-Architected Framework defines two relevant patterns:
- active-passive cold standby (minimal or no infrastructure until disaster)
- active-passive warm standby (some pre-deployed infrastructure at reduced capacity)
These are sometimes called pilot-light patterns in industry shorthand, but Microsoft's Azure Virtual Desktop documentation doesn't use that label.
Compute and replication patterns only get you so far. The profile layer determines whether any of them actually recovers a working desktop, because a session host with no profile is just a blank Windows machine.
FSLogix profile replication (where your real RPO lives)
Your recovery point objective is decided almost entirely by how you replicate FSLogix profiles. A host pool can spin up in seconds in the secondary region, but if the profile data isn't there, users log into empty sessions. Microsoft documents three replication patterns, and the storage tier you chose months ago constrains which ones are available to you.
The three replication patterns
Native Azure Storage replication uses Geo-Redundant Storage (GRS) for standard file shares, cross-region replication for Azure NetApp Files, or Azure File Sync for VM-based file servers.
FSLogix Cloud Cache replicates containers asynchronously between up to four different storage accounts.
Geo disaster recovery is a strategy for application data only. Store important data in locations like OneDrive and don't replicate profile containers at all.
For profile and Office container storage, Microsoft's priority order is Azure Files Premium tier, then Azure NetApp Files Standard tier, then Azure NetApp Files Premium tier.
Cloud Cache mechanics and the Premium tier constraint
Cloud Cache lets you specify multiple profile storage locations and replicate asynchronously without relying on underlying storage replication. The first location becomes the primary read/write location for every user, and the others become read-only replicas for failover.
Cloud Cache fails over automatically when the primary can't be reached. You configure it through the CCDLocations registry value, pointing the profile container at HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles and the Office container at HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC.
Azure Files Premium tier doesn't support GRS, and Azure Files offers geo-redundancy only for standard (HDD) file shares with no RA-GRS or RA-GZRS at all. So if you chose Premium for FSLogix performance (which Microsoft recommends), you rely on Cloud Cache for cross-region replication instead. The same applies to standard tier with large file support enabled.
Cloud Cache isn't free in cost or operations. Planning should account for:
- Double storage cost, since profile data lives in two locations
- Manual failover initiation that can require business sign-off
- Async sync that introduces potential latency or inconsistency
- Heavy post-recovery replication load, since Cloud Cache is I/O intensive
- All users signing out of the failover location before failback
Azure NetApp Files for low-RPO requirements
When you need a tighter RPO than Cloud Cache delivers, Azure NetApp Files supports cross-region replication through SnapMirror, which sends only changed blocks in compressed form. Actual RPO depends on the replication schedule and volume size, so verify the numbers for your configuration against the Azure NetApp Files documentation. One trap to avoid: Zone-Redundant Storage (ZRS) provides zone resilience within a single region, not across regions, so it doesn't satisfy a cross-region disaster recovery requirement on its own.
Nerdio Manager for Enterprise manages FSLogix profile configuration and storage provisioning from one console. You create FSLogix profiles, point them at Azure Files, Azure NetApp Files, or server locations, and select VHDLocations, Cloud Cache, or Azure Blob storage modes without hand-editing registry values across hundreds of hosts.
For Azure Files, Nerdio Manager handles storage account creation, Active Directory domain join, role assignments, and NTFS permissions in one sequence, and monitors capacity so you get alerted before a share fills up mid-incident. For teams standardizing profile operations, Nerdio for FSLogix keeps that configuration work in one place.
Getting profiles to the secondary region solves nothing if users can't authenticate or the network can't route them there. The dependency layer is where well-designed disaster recovery plans quietly fail.
Identity and networking dependencies that break failover
A disaster recovery plan that addresses compute and profiles but ignores identity and networking will fail in a region outage. Session hosts need something to authenticate against and a network path to reach it. These dependencies must exist and be healthy in the secondary region before failover.
Identity: domain services are where the trouble starts
Microsoft Entra ID is globally resilient by design, so it needs no additional BCDR action. Domain services are a different story.
If your session hosts join Active Directory Domain Services (AD DS), you need domain controllers deployed in both the primary and secondary regions, spread across availability zones. For Microsoft Entra Domain Services, you deploy a replica set in the secondary region. Active Directory authentication must be available in the disaster recovery region, or connectivity to the on-premises domain must be guaranteed.
Cold-standby designs in Azure carry one AD DS caveat worth flagging. When every domain controller in a domain is stopped and deallocated at the same time, none of them can find an authoritative replica on restart, and each one needs manual intervention to come back online.
Networking: the secondary region needs a path to identity and DNS
The secondary region needs either the same capabilities as the source environment or connectivity to identity and DNS services. Hybrid connectivity must be highly available in both regions. Your join type drives the specifics:
- Entra Domain Services-joined VMs need network connectivity to the identity service host
- Entra ID-joined VMs make outbound connections to Entra ID public endpoints and need no private connectivity setup
- Port requirements: 443/TCP for the standard model, plus 3390/UDP or 3478/UDP for STUN or TURN with RDP Shortpath
Traffic routing: the control plane handles most of it for you
The Azure Virtual Desktop control plane handles user traffic redirection during an outage without any configuration on your part. Azure Traffic Manager routes the web service and Azure Front Door routes the gateway service to the next closest available instance, so users can still make new connections. If you've built custom routing on top of that, short DNS time-to-live values of 300 to 600 seconds help failover propagate quickly.
Identity, networking, and routing get users to a session host in the secondary region. The next question is whether the desktop they land on actually matches production.
Golden image and application consistency across regions
When you rebuild host pools in a secondary region, the golden image and applications must already be there and must match production. A drifted image turns a successful failover into an application support event.
Azure Compute Gallery is regional, so you replicate manually
Azure Compute Gallery is a regional resource rather than a global one. If the region holding your gallery goes down, you can't create or update gallery resources, though image versions already replicated elsewhere stay usable.
That regional scope drives Microsoft's Azure Compute Gallery disaster recovery guidance:
- At least two galleries should exist in separate regions
- Separate galleries should exist for production and test images
- ZRS and image copies should create the image, with at least two copies of the image per region
- Image versions can be replicated cross-region with --target-regions and --replica-count
There's no built-in automatic replication of gallery resources or image definitions. You manually create a matching gallery and image definitions in the secondary region, then use az sig image-version create --remote-gallery to copy versions across, ideally automated on a schedule.
The image in your secondary region should match the primary exactly, with multiple replicas depending on your failover deployment batch size. Repeatable image management keeps the primary and secondary images aligned over time.
App Attach or Packer: pick how apps reach the secondary region
You have two consistency strategies for getting applications to the secondary region. One strategy bakes universal apps into the golden image using the Packer method; the other uses App Attach to deliver apps dynamically at logon, which keeps your base image smaller. Separating applications from VM images means there's no need to publish a new image for every code change. For App Attach disaster recovery, ZRS supports zone resilience and GRS for Azure Files supports region-level protection, driven through CI/CD pipelines.
How Nerdio Manager keeps images consistent across regions
Nerdio Manager uses Azure Compute Gallery as the central hub for storing, versioning, and replicating images globally. Scripted Actions automate software installs and OS hardening during image builds. An independent benchmark found that updating a custom image in Nerdio Manager took 37 seconds and 13 clicks compared to 5 minutes 9 seconds and 146 clicks natively. Fewer manual steps mean fewer chances to introduce configuration drift between your primary and disaster recovery images, which matters when you fail over.
Consistent images and apps get you a working desktop in the secondary region. Whether you can prove that before a real disaster comes down to how you test, and Azure Virtual Desktop has a testing rule that catches many teams off guard.
Setting RTO and RPO targets and testing them without breaking Azure Virtual Desktop
Microsoft doesn't publish numeric RTO or RPO SLA targets for Azure Virtual Desktop disaster recovery, and there's no financially backed SLA for the service itself, though Microsoft targets at least 99.9% availability for the service URLs (from previously linked BCDR resource). You define your own targets first, then pick the pattern that meets them.
Define your reliability metrics before the architecture work starts
RTO and RPO set the recovery boundaries, but they're only two of the three reliability metrics that you should define up front.
The third is mean time between failures (MTBF), or how long the workload runs before failing. Together, these targets tell you how much resilience each layer needs, with higher-criticality components demanding faster recovery and lower-criticality ones tolerating slower restoration.
Once those numbers are set, the next decision is how much regional and zonal separation you actually need to hit them.
Availability zones and region pairs don't replace a disaster recovery design
Availability zones are your first resilience layer and the default for host pool deployment. Distributing VMs across zones keeps them in the same region but raises the formal high-availability SLA to 99.99%, so your capacity planning should include enough extra compute that Azure Virtual Desktop keeps running even if a single zone is lost.
For mission-critical workloads, Microsoft recommends a solution that is both multi-region and multi-zone. Zone-to-zone disaster recovery can fall short during a region-wide natural disaster.
Region pairs aren't a reliable disaster recovery default either. Newer Azure regions aren't paired, and many services support geo-redundancy whether regions are paired or not. Microsoft's region pairs documentation states that deploying to a region pair doesn't automatically make resources resilient or provide failover, and Microsoft-managed GRS failover only triggers in catastrophic situations after repeated failed recovery attempts. You design your own disaster recovery regardless of pairing.
Once the architecture is in place, the only way to know it works is to test it, and Azure Virtual Desktop has one testing rule that catches many teams off guard.
Don't use Site Recovery test failover on Azure Virtual Desktop session hosts
The Site Recovery test failover feature looks like the obvious way to validate readiness, but it breaks Azure Virtual Desktop. A test failover creates a duplicate VM that registers with the Azure Virtual Desktop control plane and conflicts with the original session host.
Instead, validate session host VM readiness by starting secondary session hosts on a schedule, confirming each VM registers with the control plane, and running documented failover and failback procedures with a test user group. Build that validation into a regular testing cadence:
- Tabletop exercises so the team practices roles and trains new members
- Dry runs in non-production to rehearse the mechanics
- Production-level drills, the only way to verify you actually meet RTO and RPO
Treat disaster recovery runbooks like production code: versioned in Git, stored as offline and printable copies so they're reachable during an outage, and written with health validation checks and an escalation plan. Failback gets its own plan that mirrors any manual failover steps.
All of this works on paper. In practice, secondary-region compute costs money the moment it runs, and manual failover validation consumes incident-response time the team doesn't have during a real outage. A management layer automates those operational steps so the team can focus on decision-making and validation.
How Nerdio Manager automates multi-region Azure Virtual Desktop disaster recovery
Nerdio Manager is an automation and intelligence layer inside your Azure tenant that extends the native Azure Virtual Desktop service rather than replacing it. It connects host pool, FSLogix, image, auto-scaling, and Azure Site Recovery workflows into one console, replacing the mix of Azure Portal clicks, registry edits, scripts, and runbooks teams otherwise stitch together across regions and subscriptions.
For active/active disaster recovery designs across two Azure regions, that single management layer handles the moving parts continuously. Users distribute across VMs in both regions as they log in, FSLogix profiles replicate through Cloud Cache, and if a region fails, users keep accessing VMs in the surviving region as long as it has capacity. Image replication and host availability run on a steady cadence rather than getting scrambled together during a crisis.
Nerdio Manager also supports multi-region disaster recovery for the Nerdio Manager control plane itself, so the management layer can sit inside your continuity plan instead of outside it.
Three capabilities carry the most weight in a disaster recovery context:
- Patented auto-scaling shuts down and deallocates VMs during nights and weekends, so a warm or cold standby pool only consumes compute when needed and idle disaster recovery compute spend stays near zero between tests. Storage and baseline services remain in place. You can use Azure auto-scaling with Nerdio to make standby capacity more cost-aware.
- Auto-Heal detects and repairs broken Azure Virtual Desktop session hosts automatically, reducing downtime by up to 36%.
- Azure Site Recovery integration replicates Azure Virtual Desktop workloads to a secondary region for personal host pools or any pool that can't be quickly rebuilt. For pooled multi-session pools with no unique data, rebuilding session hosts in the secondary region stays the lighter option.
Standby capacity costs less when it scales with demand
Dual-region resilience is expensive by default, so cost discipline shapes whether the design holds up at budget review.
TechTarget's Enterprise Strategy Group found that Nerdio Manager reduces Azure compute costs by up to 55% through auto-scaling. Sage reported reducing virtual machine costs by 62 to 65% and scaling its customer base from 200 to 1,000 without adding staff, with $1.5 million in annual savings. Applied to disaster recovery, the same auto-scaling discipline keeps a standby region from running at full spend around the clock when nobody's using it.
One console covers Windows 365 alongside Azure Virtual Desktop
Many enterprises run both Windows 365 and Azure Virtual Desktop, so the management layer needs to reach across both paths. Nerdio Manager keeps host pools, FSLogix, images, auto-scaling, application deployment, Intune policy backup and restore, and right-sizing signals in one place.
On the Windows 365 side, Cloud PCs are flat-rate and the value shows up in operations rather than compute savings. Nerdio Manager deploys applications to Windows 365 endpoints through unified application management in about 30 seconds, versus native Microsoft Intune delivery that can take up to 3 hours. It also backs up and restores Microsoft Intune policies, a capability native Intune doesn't offer, and flags right-sizing opportunities through Nerdio Advisor.
What this means for your Azure Virtual Desktop disaster recovery architecture
The 9:15 Tuesday outage doesn't have to mean a filled help desk queue and a scramble for runbooks nobody can find. Your resilience is exactly as good as the architecture you compose, which comes down to five decisions:
- Pattern selection. Match active-active, active-passive, or Azure Site Recovery to each host pool type.
- Profile replication. Use an FSLogix replication path that respects the Azure Files Premium-tier GRS constraint.
- Dependency pre-staging. Have identity and networking healthy in the secondary region before failover, not during it.
- Image consistency. Replicate golden images and keep the secondary copies matched to production.
- Testing cadence. Validate readiness by starting secondary session hosts on a schedule, never with ASR test failover.
Get those five layers right and a region failure becomes a controlled failover event instead of a help desk flood. The catch is that each layer adds orchestration, and manual orchestration under pressure is where disaster recovery plans get fragile. Nerdio Manager automates active/active distribution, Cloud Cache configuration, image replication and versioning, and standby cost control so the plan has fewer manual steps to execute during a regional outage.
You can get a demo to see how Nerdio Manager works across your Windows 365 and Azure Virtual Desktop environment, or try it free in your own Azure tenant.
Frequently asked questions about Azure Virtual Desktop disaster recovery architecture
Resources
Learn more about Nerdio Manager
