High availability and disaster recovery are related reliability disciplines, but they answer different failure questions. High availability (HA) is primarily about keeping a workload running through expected component or localized infrastructure failures. Disaster recovery (DR) is about restoring service when the primary environment can no longer meet the business requirement.

The distinction matters for AZ-305 because an architect cannot select zones, regions, replication, backup, or failover services intelligently without first translating business requirements into recovery objectives. A solution with excellent uptime inside one region may still have no credible regional disaster plan. Conversely, a secondary region that takes hours to activate does not replace the need for local high availability.

The design starts with failure scope, recovery time objective (RTO), recovery point objective (RPO), and the cost the organization is willing to carry for resilience.

Define RTO and RPO before choosing Azure services

RTO describes how long the business can tolerate the workload being unavailable. RPO describes how much data loss, measured in time, the business can tolerate after recovery.

Those two targets drive very different architectures.

A workload with an RTO of seconds and an RPO near zero may require active redundancy, automatic failover, and synchronous or near-synchronous data replication. A reporting system that can be unavailable for several hours and lose one hour of data can use a much less expensive recovery design.

The business continuity and disaster recovery discussion provides the broader planning context. In Azure architecture, RTO and RPO become concrete design constraints for compute placement, data replication, networking, identity, DNS, backups, and operational runbooks.

Recovery objectives should be defined per business capability rather than copied from an arbitrary enterprise standard. The authentication tier, order-processing tier, marketing website, and analytics platform can justify different targets even when they belong to the same application portfolio.

Use high availability to survive localized failures

HA reduces disruption from failures that the architecture expects to absorb without invoking a full disaster process.

Examples include:

• a VM host failure
• a single instance failure
• a datacenter or availability-zone outage
• a load-balancer backend failure
• a planned maintenance event

Azure availability zones are separate groups of datacenters within a region with independent power, cooling, and networking. Zonal resources are pinned to a specific zone, while zone-redundant services can distribute or replicate across zones and often fail over automatically.

The important design question is not simply “does this region have zones?” It is whether every critical dependency can tolerate a zone failure. A web tier spread across zones is not truly zone resilient if its database, firewall, private endpoint, or identity dependency still has a single-zone bottleneck.

Azure regions and availability zones describe different failure scopes. Two zonal replicas in one region can reduce exposure to a single-zone outage but do not by themselves provide recovery from a regional loss. Confirm where the database, identity dependency and backups reside before claiming that a VM placement meets the stated recovery-time and recovery-point objectives.

Disaster recovery addresses failures beyond the primary design boundary

DR becomes necessary when the primary environment cannot continue to deliver service within the agreed recovery target. The event might be a regional outage, a destructive configuration error, ransomware, severe data corruption, or another incident whose impact exceeds normal HA controls.

A DR architecture defines where service is restored and how the organization gets there.

Common models include:

• backup and rebuild, where infrastructure and data are restored after the event
• pilot light, where critical shared services already exist in the recovery region but most capacity is created during failover
• warm standby, where a reduced-capacity environment is already running
• active/active, where multiple regions normally serve production traffic

The more aggressively the design reduces RTO and RPO, the more operational complexity and ongoing cost it generally carries. Active/active is not automatically “better” than warm standby; it is justified only when business requirements and application design support it.

Availability zones do not automatically provide regional DR

One of the most common architecture mistakes is treating zone redundancy as if it eliminated regional risk.

Availability zones protect against many failures inside a region. They do not guarantee continued operation if the entire region or a shared regional dependency is unavailable.

For workloads with high reliability targets, Microsoft recommends considering both multi-zone and multi-region strategies. A common pattern is zone redundancy for normal high availability combined with backups, replication, or a prepared deployment path in another region for disaster recovery.

That layered model is often more realistic than trying to run every application active/active across regions. It gives fast response to common localized failures while retaining a credible answer to the less frequent regional event.

Data protection determines the achievable RPO

Compute can often be recreated from infrastructure as code. Data is harder.

The DR plan must identify how each stateful component protects data and what recovery point that protection can actually deliver. Options may include synchronous replication across zones, asynchronous replication across regions, application-native replication, database geo-replication, Azure Site Recovery for VMs, and backup-based recovery.

These mechanisms have different semantics. A backup taken every four hours cannot satisfy a five-minute RPO. Asynchronous cross-region replication can reduce data loss dramatically but may still have a nonzero replication lag. Synchronous designs can improve RPO but add latency and may not be available or appropriate across distant regions.

The architect should also distinguish replication from backup. Replication can copy bad data, accidental deletion, or corruption to the secondary location. Backup creates historical recovery points that can support point-in-time restoration. Many critical systems need both.

Recovery quality matters as much as recovery frequency. A crash-consistent copy may restore the disks to a point in time but still require application-level recovery when services restart. Application-consistent protection can reduce that work for supported workloads by coordinating data state more carefully. The design should identify which databases or transactional systems need application-aware recovery rather than assuming every replicated disk is immediately ready for business use.

Backup storage redundancy also deserves review. Keeping a backup in the same failure domain as the workload may protect against accidental deletion but provide little help during a larger infrastructure event. The organization should know whether backups are locally redundant, zone redundant, or geo-redundant and whether the chosen option aligns with the disaster scenario being mitigated.

Azure Site Recovery supports orchestrated VM recovery

Azure Site Recovery is one option for protecting VM-based workloads. It can continuously replicate supported Azure VMs to another region and coordinate failover when the primary location is unavailable.

That can reduce the work required to reconstruct a VM estate manually, but it does not remove application-level design responsibilities. The recovery region still needs appropriate networking, name resolution, security controls, identity dependencies, capacity, and any managed services the workload requires.

Recovery plans should also account for sequencing. Domain services, databases, middleware, and application tiers may need to start in a defined order. A collection of replicated VMs is not automatically a working business service.

Testing is essential because recovery depends on the whole dependency chain rather than the replication status of one resource.

Networking and DNS are also part of failover.

A secondary region that contains healthy compute but cannot receive users is not recovered.

The DR design should document:

• how clients discover the recovery endpoint
• whether global traffic management or DNS changes are required
• whether private connectivity exists in the secondary region
• how on-premises routes change during failover
• whether firewalls and security policies are already present
• whether private endpoints and private DNS resolve correctly after recovery

DNS time-to-live and caching affect recovery speed when failover relies on name changes. Proxy-based global services can behave differently from DNS-only routing. The selected mechanism should be tested under the same assumptions used to claim the RTO.

Recovery must include identity, secrets, and deployment tooling

Architects often focus on application servers and databases while overlooking the systems needed to rebuild or operate them.

A regional recovery plan might depend on:

• Microsoft Entra identities and role assignments
• Key Vault secrets and keys
• container registries or package repositories
• infrastructure-as-code templates
• deployment pipelines
• monitoring workspaces
• certificate authorities or TLS certificates
• management jump hosts or privileged-access paths

If these dependencies are unavailable or inaccessible during the incident, recovery can stall even when the primary application data has been protected.

Deployment tooling should itself be resilient enough to recreate infrastructure. Keeping infrastructure definitions in version control, validating them regularly, and avoiding region-specific assumptions can materially improve recovery time.

Test failover and failback, not just backup success

A backup job reporting “succeeded” proves that a backup was created. It does not prove that the business service can be restored within its RTO.

A mature DR program tests:

1. whether the secondary environment can be activated
2. whether the most recent acceptable recovery point is usable
3. whether dependencies start in the correct order
4. whether users and integrations can reach the recovered service
5. whether monitoring and security controls function after failover
6. how the organization returns to normal operation after the primary region is healthy

Failback deserves explicit planning. Data changed in the recovery environment must be reconciled, routes must be moved deliberately, and users should not be switched back simply because the original region has returned.

Regular exercises also reveal operational assumptions that documentation alone will not expose.

Choose resilience by business consequence

A useful architecture review connects each failure scope to a specific control.

For a VM or instance failure, use redundancy and health-based load distribution. For an availability-zone outage, use zonal or zone-redundant design where the service supports it. For a regional event, use a tested cross-region recovery model. For corruption or destructive change, use protected historical backups. For extreme RTO/RPO requirements, consider active multi-region patterns only where the application and data layer can support them safely.

Maximizing redundancy everywhere is not an architecture goal. A third-party AZ-305 resilience scenario should first state its recovery-time objective, recovery-point objective, failure scope, and accepted cost. Only then can an architect decide whether replication, backup, or regional failover addresses the business consequence. A documented RTO or RPO is not evidence that the chosen recovery procedure was actually tested.