Azure VM Resilience Strategy

Subject: Resilience strategy for Azure VMs currently deployed without Availability Zone assignment

Audience: Project leadership and architecture

Executive summary

The customer Azure estate includes single-instance VMs without Availability Zone assignment or Availability Sets. This includes SQLNODE01 and SQLNODE02, which are intended to host the primary and synchronous secondary replicas of a SQL Server Always On Availability Group (AG) in the primary region. SQLNODE03 is planned for a separate disaster recovery (DR) region and will use asynchronous commit with manual regional failover.

Retaining the current placement leaves SQLNODE01 and SQLNODE02 exposed to a common datacenter or infrastructure event. A Proximity Placement Group (PPG) may support latency objectives, but it is not a fault-isolation mechanism. A short, controlled deferral may be acceptable where the workload is not yet serving production traffic and formal risk controls are in place.

The proposed target architecture places SQLNODE01 and SQLNODE02 in separate Availability Zones in the primary region, subject to validation of Azure service support, capacity, SQL Server and WSFC configuration, and the migration procedure. Zone separation improves fault isolation, but it does not by itself guarantee automatic failover, a particular recovery time, or zero data loss. Those outcomes depend on the tested AG, WSFC, networking, quorum, backup, and failover configuration.

Based on the current information, the recommended decision is to complete the zonal design during the current delivery iteration, or to approve only a short, time-bound deferral with documented risk acceptance and a committed remediation date.

Background and scope

The analysis focuses on SQLNODE01 and SQLNODE02 in the primary region. SQLNODE03 is already separated into another region by design and is considered primarily in relation to quorum, regional recovery, and data-loss exposure.

The current assumptions are:

• SQLNODE01 and SQLNODE02 will host synchronous AG replicas in the primary region.
• SQLNODE03 will host an asynchronous replica in a separate DR region and will require manual regional failover.
• The primary-region replicas are intended to provide high availability for normal operations and local infrastructure failures.
• The current VMs have no Availability Zone assignment and no Availability Set.

These assumptions require confirmation before implementation. In particular, the team must confirm the Azure regions, zone support, VM SKU capacity, disk and networking configuration, SQL Server licensing and support requirements, listener addressing, subnet and load balancer behavior, and the WSFC quorum design.

Availability, SLA, and recovery implications

Azure VM availability commitments depend on the exact VM configuration, managed disk type, deployment model, region, and the eligibility conditions in the applicable Microsoft SLA. The commonly referenced single-instance and multi-instance percentages must not be treated as universal values for this estate until the configuration has been checked against the current Azure SLA documentation.

An Azure SLA is a contractual availability commitment. It defines eligibility conditions and may provide service credits when the commitment is not met. It is not a recovery-time guarantee, does not promise restoration within a particular period after every failure, and does not replace an application-level recovery design.

Availability Zones provide separate datacenter locations within a supported Azure region and can reduce the likelihood that a single datacenter event affects multiple VMs. They do not eliminate all common dependencies or all failure modes. The final design should record the applicable Azure SLA, its prerequisites, and the tested service-level objectives separately from the SQL Server recovery objectives.

SQL Server AG and WSFC considerations

An Always On AG automatic failover is conditional. It requires, at minimum, a healthy synchronous secondary, suitable AG failover modes and policies, network reachability, a functioning WSFC, and sufficient quorum. Zone separation improves the likelihood that one primary-region replica remains available during a zonal event, but it does not guarantee failover in seconds or zero data loss in every scenario.

SQLNODE03 is asynchronous and is not an automatic failover target under the stated design. Its ability to participate in WSFC quorum is a separate question from its SQL replica failover eligibility. Whether it has a vote, whether the cloud witness has a vote, where the witness is located, and which quorum model is configured determine the cluster's behavior during a regional or node failure.

The team must document and test:

• The WSFC vote allocation for all three nodes and the cloud witness.
• The witness location and its independence from the primary failure domain.
• The quorum model and expected behavior when the primary region or an individual node is unavailable.
• The AG synchronous and asynchronous commit settings, automatic failover partners, and failover policies.
• The tested recovery time objective (RTO) and recovery point objective (RPO) for local node failure, zonal failure, and regional DR failover.

If both primary-region VMs share a failure domain and that domain becomes unavailable, both replicas may be lost simultaneously. The resulting service impact depends on the WSFC quorum configuration and the availability of SQLNODE03 and the witness. The primary region may require infrastructure recovery and AG resynchronisation; a regional failover to SQLNODE03 would remain a controlled manual operation and could involve data loss equal to the asynchronous replication lag at the time of failover.

Options assessed

Option 1 — Retain the current placement

Scope

Leave the VMs as single-instance machines without Availability Zone assignment or Availability Sets.

Benefits

• No immediate engineering effort or migration activity.
• No change to the current delivery schedule.
• No additional placement constraints to manage.

Risks

• A host, datacenter, or other shared infrastructure event could affect both primary-region replicas.
• The AG may not be able to provide local automatic failover if both primary-region nodes become unavailable or quorum is lost.
• Recovery depends on the configured Azure, WSFC, SQL Server, and backup recovery paths rather than on a tested zonal design.
• The applicable VM and disk SLA may be less favourable than a qualifying multi-VM zonal deployment; the exact SLA must be confirmed rather than assumed.
• The architecture may not satisfy internal availability, hosting, or accreditation requirements.

Assessment

This option leaves a material, known fault-isolation limitation in place. It may be suitable for non-production or short-lived environments, subject to the service owner's risk assessment. It is not the preferred design for a business-critical production SQL workload.

Option 2 — Introduce a Proximity Placement Group

Scope

Evaluate a PPG to support a latency or placement objective for the SQL VMs.

Benefits

• May reduce network distance or latency between compatible VMs.
• May be relevant if synchronous replication performance testing identifies a latency constraint.
• May be usable alongside a zonal design, subject to Azure support for the selected region, VM SKU, API, and deployment pattern.

Limitations and dependencies

• A PPG is primarily a placement and latency feature; it is not a substitute for Availability Zone fault isolation.
• The placement behavior, supported combinations with Availability Zones, VM SKU compatibility, attachment process, and allocation constraints must be verified against current Azure documentation and the Terraform provider version.
• Adding or changing a PPG may require a VM stop and deallocation and may affect the change window.
• A PPG does not establish WSFC quorum, protect against a datacenter event, or provide an application recovery guarantee.

Assessment

A PPG should be considered only if validated latency or placement requirements justify it. It should not be selected as the resilience control for the current single-fault-domain exposure.

Option 3 — Defer the zonal design

Scope

Retain the current placement temporarily while committing to a future zonal implementation date.

• Short deferral: up to four weeks with a scheduled change window and hard completion date.
• Medium deferral: one to three months with formal risk acceptance and a separately managed workstream.
• Indefinite deferral: no committed completion date.

Conditions

A deferral should be considered only when the exposure is understood and controlled. Before approval, the following conditions should be met:

1. The production status and business criticality of the SQL nodes are confirmed.
2. Azure Backup is active, retention is appropriate, and a VM and application restore test has been completed.
3. A recovery runbook covers VM loss, WSFC quorum behavior, AG recovery, listener validation, and regional failover.
4. The applicable SLA and its eligibility conditions have been confirmed.
5. A formal risk acceptance is signed by the service owner where required.
6. A specific delivery date, owner, dependencies, and change window are recorded.

Assessment

A short, bounded deferral may be proportionate for pre-production VMs or an imminent migration. A medium deferral requires explicit risk acceptance and evidence that the recovery baseline has been tested. An indefinite deferral provides no reliable remediation control and should be treated as retention of Option 1.

Proposed target architecture — separate primary-region zones

The proposed target is to place SQLNODE01 and SQLNODE02 in separate Availability Zones in the primary region, subject to regional support, capacity, and configuration validation. SQLNODE03 should be assigned an appropriate zone at build time if the DR region supports zones and the placement aligns with the DR design.

The target architecture is intended to improve fault isolation for the synchronous primary-region pair. It does not alone define the SQL Server RTO or RPO. The project must set those objectives and demonstrate them through controlled tests.

Migration approach

Three implementation patterns may be available:

• Rebuild and recreate: create zonal replacement VMs, migrate or restore the workloads, and retire the original VMs. This is operationally explicit but may require planned downtime and data migration.
• Supported Azure move procedure: use an Azure-supported migration service or procedure only after specialist verification confirms support for the specific VM size, disks, networking, operating system, SQL Server installation, and AG configuration.
• Parallel build: provision zonal replacement nodes, validate them, and move the SQL and cluster roles in a controlled sequence. This may provide the clearest recovery path but requires additional temporary capacity and licensing review.

The ASR-backed zone-move procedure described in earlier drafts must not be treated as approved by default. The implementation team must confirm that the selected Azure service supports the exact source and target configuration and must document a tested cutover, recovery, and data-protection procedure. Zone assignment is generally an immutable VM placement property; Terraform import and a resource definition update may not be sufficient to change an existing VM's zone and must not be used as the sole migration plan.

No rollback, absence of data rebuild, or specific downtime duration should be promised until the procedure has been tested in a representative environment and approved by the Azure, SQL Server, and operations specialists.

Validation sequence

1. Confirm prerequisites. Verify region and zone availability, VM SKU capacity and quota, disk types, subscription limits, SQL Server licensing, supportability, backup status, network design, subnet placement, load balancer rules, listener addressing, and domain connectivity.
2. Confirm cluster and AG health. Verify synchronisation, log send and redo queues, WSFC health, quorum, witness reachability, cluster votes, listener connectivity, and failover policy.
3. Define success criteria. Record the approved downtime, local failover RTO, local failover RPO, regional DR RTO, and regional DR RPO. Include the expected data loss from asynchronous replication.
4. Test the selected migration procedure. Use representative VM, disk, network, SQL Server, and AG configurations. Capture recovery steps if the target VM or service does not start as expected.
5. Move or rebuild one node at a time. Protect the remaining healthy replica and preserve quorum throughout the change. Do not proceed if the remaining configuration cannot support the planned operation.
6. Validate the target node. Confirm boot, domain membership, storage, SQL services, security controls, network routes, listener behavior, cluster membership, and AG synchronisation.
7. Repeat for the second primary-region node. Use a separate change window if required by the tested procedure and risk assessment.
8. Run post-change tests. Test application connectivity, planned and automatic failover where approved, backup and restore, monitoring, alerting, and the documented DR procedure.
9. Reconcile infrastructure management. Update Terraform only after the Azure resources and migration state are confirmed. Run a plan review to ensure that the provider configuration accurately represents the deployed architecture and does not propose destructive changes.

Effort and implementation risks

A preliminary estimate of two to three engineering days across one to two calendar weeks may be reasonable for a well-prepared migration, but it is not a commitment. Actual effort depends on the selected migration pattern, data volume, testing requirements, change controls, temporary capacity, and any licensing or network changes.

RiskControl Target zone lacks capacity for the selected VM SKUValidate capacity and quota before the change; confirm an approved alternative SKU or implementation path. AG resynchronisation exceeds the change windowMeasure log generation and synchronisation times in advance; schedule low-activity windows and define stop criteria. WSFC loses quorum during the operationValidate votes and witness placement; move one node at a time and maintain an approved quorum plan. Listener or application connectivity changesValidate subnet, IP, DNS, load balancer, firewall, and client-driver behavior before production cutover. Migration service does not support the configurationObtain specialist confirmation and use a tested rebuild or parallel-build approach instead. Recovery from an unsuccessful change is incompleteDocument and test recovery steps; do not describe rollback as available until the test demonstrates it.

Dependencies and open validations

• Confirm the primary and DR Azure regions support the required Availability Zones and VM SKU.
• Confirm capacity, quota, disk support, subscription limits, and expected maintenance behavior.
• Confirm SQL Server licensing, edition, version, Microsoft supportability, and any Azure Hybrid Benefit assumptions.
• Validate subnet, IP address, DNS, load balancer, firewall, routing, and AG listener behavior after zonal placement.
• Confirm Azure Backup configuration and complete a representative restore test.
• Document WSFC quorum votes, cloud-witness placement, quorum model, and behavior during zonal and regional failures.
• Confirm the PPG requirements, if still considered, against the current Azure region, VM SKU, API, and Terraform provider.
• Define and test local failover and regional DR RTO and RPO values, including asynchronous replication lag.

Recommendation

Proceed with the proposed zonal design for SQLNODE01 and SQLNODE02 during the current delivery iteration, subject to completion of the specialist validations and a tested migration procedure. Build SQLNODE03 with an appropriate zone assignment where supported, while retaining its separate-region and manual-failover role.

If delivery timing requires a deferral, limit it to a documented period of up to four weeks. Require confirmed backups and restore testing, a recovery runbook, formal risk acceptance where applicable, and a locked implementation date. A longer or indefinite deferral should be escalated because it preserves the current shared-failure-domain exposure.

Decision record

Decision or actionRequired outcomeOwner Primary-region placement for SQLNODE01 and SQLNODE02Approve zonal design now, or approve a time-bound deferral with risk acceptance and date.Service owner and project lead Migration methodValidate the selected Azure procedure or approve a rebuild or parallel-build method. Document tested recovery steps.Azure and SQL architecture teams Backup and restore baselineConfirm Azure Backup and complete a representative restore test.Platform and operations WSFC and AG designConfirm quorum votes, witness placement, failover policies, listener behavior, and synchronisation health.SQL and Windows platform teams DR objectivesApprove and test regional RTO and RPO, including expected asynchronous replication loss.Service owner and architecture SQLNODE03 placementConfirm DR-region zone support and assign a zone at build time where appropriate.Platform and architecture