I've lost count of the enterprise clients I've visited who can produce a beautifully formatted DR runbook on request — complete with recovery time objectives, recovery point objectives, and escalation matrices. Then I ask the follow-up question: "When was the last time you actually tested it?"

The room goes quiet.

This is the dirty secret of disaster recovery in Southeast Asia. We document it. We present it to auditors. We put it in the compliance binder. And then we pray we never have to use it — because the honest truth is that most DR plans have never been exercised end-to-end. The runbook is theory. The failover procedure is fiction.

Two things changed that equation in mid-2026. First, the Resiliency in Azure service — the rebrand and expansion of what was Azure Business Continuity Center — shipped Availability Zone Down Drills and Recovery Orchestration Plans in public preview, giving us platform-native ways to actually exercise zone failure and orchestrated failover. Second, and just as important for my Malaysian clients: Malaysia West (malaysiawest) launched as a nonpaired region, which breaks the default DR architecture playbook most of us have been following for a decade.

This article is the implementation guide I wish someone had handed me six months ago: what these new capabilities actually do, how Malaysia West's unpaired status changes your DR design, and how to build and test a real plan. I've covered the fundamentals of Azure Resiliency in [Azure Resiliency Gets Real — Availability Zone Drills, Zonal Recovery Orchestration](https://wenfeng.my/azure-resiliency-in-2026-availability-zone-drills-and-zonal-recovery-that-actually-work/), so here I'm going deeper on the build-and-test workflow.

Caveat up front: Availability Zone Down Drills and Recovery Orchestration Plans are in public preview as of mid-2026. ARM API versions in the Microsoft.AzureResilienceManagement provider are preview-stamped (2025-02-01-preview through 2026-06-01-preview). Schemas and portal workflows may change before GA. Treat everything here as preview-grade and validate against the current docs before you wire it into production procedures.

The Problem: Documented but Untested

Here's the realistic picture of DR readiness at most mid-to-large Malaysian enterprises I work with:

  • The runbook exists — usually a Word document or Confluence page written by a consultant two years ago. It references resource groups and naming conventions that have since changed.
  • The backup infrastructure is there — Azure Site Recovery is configured, database backups flow to geo-redundant storage, and someone created a Recovery Services vault.
  • Nobody has actually failed over — the last "test" was a tabletop exercise where people walked through the runbook verbally. The actual failover has never been executed.
  • Nobody knows how long recovery really takes — the RTO in the document says 4 hours, but that was an estimate from deployment day. Nobody has measured real recovery time under realistic conditions.

This is dangerous for reasons specific to Malaysian enterprises. Bank Negara Malaysia's Risk Management in Technology (RMiT) policy document — dated 1 January 2020, with a revised version in force from June 2023 and further revisions in exposure draft — sets a continuous-compliance expectation: financial institutions must maintain and produce defensible, current evidence that recovery capabilities actually work, including regular DR and cyber-resilience testing. If your evidence is a two-year-old runbook and a tabletop exercise, you're going to struggle to demonstrate effectiveness when BNM asks.

PDPA matters too. Malaysia's PDPA Amendment Act 2024 introduced mandatory data breach notification — data users must notify the Commissioner of qualifying breaches within the prescribed timeframe. A disaster that exposes personal data can trigger that obligation, and your DR plan should include a breach-assessment step at the start of any failover event, not as an afterthought.

The historical blocker has been cost and risk: testing DR meant either accepting production risk (real failover against live traffic) or maintaining a parallel environment that's expensive and diverges from reality. Azure Resiliency's preview features attack exactly that problem — but they do it in a way that surprises people, so let's be precise about what they actually are.

What Azure Resiliency Actually Gives You

Three capabilities matter for DR testing, all preview as of mid-2026:

1. Availability Zone Down Drills

AZ Down Drills live in Infrastructure Resiliency Manager. They let you simulate an availability zone outage for a Service Group — a logical grouping of the resources that must survive a zone failure together — and assess cross-zone resiliency before a real outage forces you to find out.

Here's the part that surprises people: the drill is a real fault injection, not a harmless simulation. Under the hood it uses Azure Chaos Studio-style faults — VM shutdowns, Virtual Machine Scale Set zone shutdowns, AKS node pool shutdowns, forced database failovers — injected against the resources in your target zone. Resources with native zonal resiliency absorb it; resources relying on a Recovery Plan get failed over and reprotected as part of the drill. For resource types without native support, you plug in custom fault logic via Azure Automation runbooks.

That has two consequences. First, schedule drills like a real exercise — notify stakeholders, pick a maintenance window, and expect real (if brief) impact on the drilled resources. Second, the drill produces exactly the evidence auditors want: run-level status, resource-level health and downtime metrics, attestation, and drill history.

2. Recovery Orchestration Plans

Recovery Orchestration Plans are executable recovery sequences for zonal failover. Key facts from Microsoft's own documentation, because they shape the whole design:

  • Zonal only. The service explicitly "supports only zonal recovery and doesn't support regional recovery." If you need cross-region DR, that's still Site Recovery, failover groups, geo-replication, and Traffic Manager — the orchestration plan is not that tool (yet).
  • Ordering via groups. Resources recover in groups: resources within a group fail over in parallel; groups execute sequentially. That's how you encode "databases before application tier, application tier before web tier."
  • Readiness checks every 24 hours. Automated checks detect drift — resources added or removed, protection health degraded — so the plan fails loudly in advance rather than silently during an incident.
  • Runbook integration. Azure Automation runbooks can run as pre-scripts and post-scripts at group level, and manual action steps can pause execution until a human completes an intervention.
  • It orchestrates, it doesn't protect. VMs still need Azure Site Recovery; other resources need their native HA solution. The plan sequences the failover; it is not a replication technology.

3. Zonal Resiliency Goals and Recommendations

Infrastructure Resiliency Manager also scores your estate against zonal resiliency goals and produces resource-level recommendations with cost-impact indicators (High / Medium / Low / None). This is the cheapest way to find the gaps before the drill finds them for you — single-zone VMs, non-zone-redundant disks, load balancers without zone-redundant front ends.

The Malaysia West Trap: Your Region Has No Pair

This is the part that matters most for my local readers. If you deployed into Malaysia West assuming the classic playbook — primary region, paired secondary, GRS handles the rest — you have a gap.

Per Microsoft's region pairs documentation, Malaysia West is a nonpaired region. Its paired region is N/A. It's in the same category as Indonesia Central, Mexico Central, and several European regions: newer regions built around availability zones rather than region pairs.

The practical consequences:

  • Storage GRS has no automatic paired target. Geo-redundant storage replicates to the paired region; with no pair, you must choose your secondary region explicitly (or rely on the service's own multi-region options).
  • No Microsoft-managed recovery-pair sequencing. You don't get the geography-wide-outage recovery prioritization that paired regions provide.
  • Cross-region failover is entirely your design. Azure Site Recovery, SQL failover groups, Cosmos DB multi-region, Traffic Manager — you pick the secondary region yourself. For most Malaysian enterprises the sensible choices are Southeast Asia (Singapore) or East Asia (Hong Kong), both of which are paired with each other.

The good news: zonal resiliency is strong. Malaysia West launched with three availability zones, and Microsoft's Malaysia region playbook pushes zone redundancy as the first line of defence. That's exactly why the new Azure Resiliency features land so well here: the platform's story for this region is zones first, cross-region second — and now there's tooling to prove both layers.

# Verify which regions are actually available to your subscription
# and confirm Malaysia West has no pair
az account list-locations \
  --query "[?contains(name,'malaysia') || name=='southeastasia' || name=='eastasia'].{region:name, displayName:displayName, pairedRegion:metadata.pairedRegion}" \
  --output table

Building the Plan: A Practical Walkthrough

Here's the workflow I now use with clients running production in Malaysia West. Zonal resilience is the foundation; cross-region is the backstop.

Step 1: Define Service Groups

A Service Group is the unit of everything in Resiliency: drills, recovery plans, and goals all hang off it. Define it as "the set of resources that must survive a zone failure together" — typically one application's full stack: web tier, app tier, database, cache, load balancer.

Service Groups are managed through the Resiliency area of the Azure portal. (The underlying resource type sits in the Microsoft.AzureResilienceManagement provider, but the portal is the practical surface — there is no dedicated az resiliency CLI extension as of mid-2026.)

Step 2: Register the Supporting Providers

AZ Down Drills pull in several platform services. Register them on the subscription where the drill's Chaos Workspace will live — registration takes 15-20 minutes, so do it before your drill window, not during:

# Prerequisites for AZ Down Drills (portal: Subscriptions > Resource providers)
for RP in Microsoft.AzureResilienceManagement Microsoft.Chaos Microsoft.Insights \
          Microsoft.OperationalInsights Microsoft.Automation; do
  echo "Registering $RP ..."
  az provider register --namespace "$RP"
done

# Wait for registration to complete
for RP in Microsoft.AzureResilienceManagement Microsoft.Chaos Microsoft.Insights \
          Microsoft.OperationalInsights Microsoft.Automation; do
  az provider show --namespace "$RP" --query "registrationState" --output tsv
done

Step 3: Close the Obvious Gaps First

Run the zonal resiliency goals assessment and fix the cheap ones before spending a drill on them. Meanwhile, verify the basics with plain CLI — these commands are the ones I run in every engagement:

# Which resource groups live in Malaysia West?
az group list \
  --query "[?location=='malaysiawest'].{name:name, location:location}" \
  --output table

# Inventory a critical resource group
az resource list --resource-group rg-prod-core \
  --query "[].{type:type, name:name, location:location}" \
  --output table

# Zone-redundant disks or not? (LRS vs ZRS)
az disk list --resource-group rg-prod-core \
  --query "[].{name:name, sku:sku.name, zones:zones}" \
  --output table

# Storage redundancy — check whether you're on GRS and where the secondary is
az storage account show --name stcoredata001 --resource-group rg-prod-core \
  --query "{sku:sku.name, primary:primaryLocation, secondary:secondaryLocation}"

Step 4: Set Up Protection and the Recovery Plan

Protection is still your job — the orchestration plan only sequences what's already protected:

  • VMs: enable Azure Site Recovery replication (zone-to-zone for zonal DR, region-to-region for the cross-region backstop).
  • Azure SQL: zone-redundant deployment, plus a failover group if you want cross-region.
  • AKS: zone-redundant node pools across at least two zones.
  • Storage: ZRS for zone redundancy; explicit secondary region choice for cross-region.

Then create the Recovery Orchestration Plan inside the Service Group. In Bicep terms, the published ARM schema makes the shape clear — planType is Zonal, sequencing happens through recoveryGroupsSetting (a required defaultGroup plus optional additionalGroups), and each group carries preActions/postActions that are either CustomRunbook (an Azure Automation runbook with an identity and parameters) or ManualAction steps:

// Recovery Orchestration Plan — zonal failover (preview schema)
// Source of truth: learn.microsoft.com/azure/templates/
//   microsoft.azureresiliencemanagement/recoveryplans
resource drPlan 'Microsoft.AzureResilienceManagement/recoveryPlans@2026-06-01-preview' = {
  name: 'drplan-prod-core'  // pattern: 5-24 chars, letters/numbers/hyphens
  properties: {
    planDescription: 'Zonal failover for prod core app in Malaysia West'
    planType: 'Zonal'
    recoveryGroupsSetting: {
      defaultGroup: {
        properties: {
          description: 'Database tier first'
          groupUniqueId: 'grp-database'
          orderId: 1
          postActions: [
            {
              name: 'db-health-check'
              description: 'Runbook: verify DB health post failover'
              type: 'CustomRunbook'
              timeoutInMinutes: 10
              actionResourceId: runbookDbHealth.id
              associatedIdentity: {
                type: 'UserAssigned'
                userAssignedIdentity: uamiDr.id
              }
              parameters: {
                targetEnv: 'production'
              }
            }
          ]
        }
      }
      additionalGroups: [
        {
          properties: {
            description: 'App tier after database'
            groupUniqueId: 'grp-app'
            orderId: 2
            preActions: [
              {
                name: 'drain-lb'
                description: 'Manual: confirm load balancer drained'
                type: 'ManualAction'
              }
            ]
          }
        }
      ]
    }
  }
}

Note what's not in that schema: there is no sourceRegion/targetRegion, and no testFailover endpoint — the plan is zonal, and testing happens through drills, not a separate test-failover mode. If you see example payloads with those fields, they're wrong.

Two RBAC roles exist for this work: Azure Resilience Management Recovery Contributor and Recovery Administrator — assign least-privilege accordingly.

Step 5: Define and Run an AZ Down Drill

Create the drill on the Service Group (portal: Service groups → your group → Resiliency → Drills). You'll pick a subscription/region for the Chaos Workspace and Log Analytics workspace (can differ from the workload), assign an identity for fault injection and recovery plan execution, review the drill scope, and design faults per resource — default fault duration is 10 minutes per resource.

Before executing, the portal runs a readiness check: Resync and check readiness must show Ready. This is where drift gets caught — excluded resources, broken role assignments, metrics not configured.

Then execute. The drill runs as one job with three stages:

  1. Fault Injection — the zone's resources take the injected faults.
  2. Failover — the Recovery Plan orchestrates recovery of affected resources.
  3. Reprotection — resources are reprotected to restore the protection baseline.

You advance each stage ("Mark step as complete") and monitor Service Group health throughout. At the end you attest the drill result and record notes. That attestation record is your RMiT evidence: who ran it, when, what the measured downtime was per resource.

Step 6: The Cross-Region Backstop (Still the Old Tools)

Since Recovery Orchestration Plans are zonal-only, your regional DR stays on the classic stack. The verification commands are worth automating:

# Site Recovery replication health for the cross-region backstop
az site-recovery protected-item list \
  --resource-group rg-prod-dr \
  --vault-name rsv-prod-dr \
  --query "[].{name:name, state:replicationHealth, rpo:recoveryPointTime}" \
  --output table

# Azure SQL: failover group status (if configured cross-region)
az sql failover-group show \
  --name fog-prod \
  --server sql-prod-malaysiawest \
  --resource-group rg-prod-data \
  --query "{replicationState:replicationState, partner:partnerServers[0].id}"

Design guidance for Malaysian enterprises: keep personal-data workloads in-region where PDPA residency arguments apply (Malaysia West primary + zone redundancy), use Southeast Asia as the explicit cross-region backstop, and document the cross-border transfer assessment in your DPIA.

PDPA Considerations for Malaysian Enterprises

If you process personal data of Malaysian citizens — and most enterprise applications do — your DR plan needs to account for PDPA:

  • Cross-region failover is a cross-border transfer. Failing over from Malaysia West to Southeast Asia moves personal data into Singapore. Under PDPA Section 129 — the cross-border transfer provision, in Part X (Miscellaneous) — you need to ensure comparable protection in the receiving jurisdiction and document the assessment. Singapore is generally a defensible choice, but write it down in your DPIA — don't assume it.
  • Breach notification is now mandatory. The PDPA Amendment Act 2024 added mandatory breach notification (the original PDPA 2010 had no such provision). A disaster event that risks exposing personal data can trigger notification to the Commissioner. Build a breach-assessment step into the first hour of every failover procedure.
  • Data minimisation in DR. Replicate only what recovery genuinely needs to the secondary region. Test data, dev data, and unnecessary PII don't belong in your DR site.
  • Tested DR is compliance evidence. PDPA's security principle requires demonstrating that you took reasonable precautions. A quarterly AZ drill with attestations and measured RTO is far stronger evidence than a runbook PDF.
# Tag DR resources for audit traceability
az tag create --resource-id "/subscriptions/{sub}/resourceGroups/rg-prod-dr" \
  --tags PDPA=applicable DataClassification=PersonalData DRTestFrequency=quarterly

Pitfalls I've Seen

Pitfall 1: Treating the drill as a harmless simulation. AZ Down Drills inject real faults — VMs actually shut down, databases actually fail over. Run them in a controlled window with stakeholders notified. The "risk-free testing" pitch is about recovery being safe because protection is in place, not about the drill touching nothing.

Pitfall 2: Assuming Malaysia West has a pair. I've seen three teams now discover at DR design time that GRS had nowhere to replicate. Check az account list-locations output for your actual region before you architect anything.

Pitfall 3: Expecting the orchestration plan to do regional failover. It's zonal only — that's documented, not a bug. If your runbook's scope is "region down," the plan covers the zone-level part of it; the regional part is still your Site Recovery and failover group design.

Pitfall 4: Forgetting the human factor. The best orchestration plan is useless if the on-call engineer doesn't know how to trigger it at 3 AM. Put the drill trigger steps in the on-call runbook, and make sure at least two people can execute independently.

Pitfall 5: Letting the plan rot. Readiness checks run every 24 hours precisely because environments drift. If you're seeing Needs Attention states and ignoring them, you've re-created the original problem: a plan that looked fine on paper. Drill quarterly, re-validate after every significant architecture change.

Pitfall 6: Not involving the security team. Failover changes your security posture temporarily — network rules, firewall behaviour, identity endpoints in the surviving zone or secondary region. Security should be in the drill, not briefed after it.

What This Costs

Let's talk numbers, with the honest caveat that these are order-of-magnitude estimates for a mid-sized enterprise (4-6 app VMs, managed databases, load balancers):

  • The Resiliency features themselves: preview tooling is currently part of the platform — the line items you'll actually pay for are the underlying protection (Site Recovery replicated instances, zone-redundant storage and disks, SQL failover groups), not the orchestration.
  • Zonal redundancy premium: mostly in storage and database replication. Compute and load balancer costs barely move between single-zone and multi-zone; zone-redundant disks and SQL zone redundancy are where the premium lives. My [companion article on Azure Resiliency](https://wenfeng.my/azure-resiliency-in-2026-availability-zone-drills-and-zonal-recovery-that-actually-work/) walks a component-by-component cost table.
  • Cross-region warm standby: the real money. A warm standby for a typical enterprise workload in Southeast Asia runs roughly MYR 8,000-15,000/month depending on SKUs and reserved capacity. Cold/pilot-light designs can cut that substantially at the cost of RTO.
  • Drill effort: budget 2-4 engineering hours per AZ drill including readiness fixes, execution, and attestation write-up. Quarterly drills are the sweet spot I recommend.

Set that against the cost of discovering your failover is broken during an actual outage. For a 500-person organisation, even one hour of regional downtime lands comfortably in six figures of MYR in lost productivity and revenue. The ROI of tested recovery is not close.

Key Takeaways

  1. Test, don't just document. AZ Down Drills and Recovery Orchestration Plans (both preview) remove most of the excuses for untested DR. RMiT's shift toward control effectiveness means untested runbooks are becoming a compliance liability, not just a technical one.
  1. Malaysia West has no paired region. Design zones-first for HA, and pick your cross-region secondary explicitly — Southeast Asia is the common choice for Malaysian enterprises. Verify with az account list-locations before you build on assumptions.
  1. Drills are real fault injection. They use Chaos Studio-style faults with real (if controlled) impact on the drilled zone. Schedule them like exercises, and use the attestation output as your audit evidence.
  1. Recovery Orchestration Plans are zonal only. They sequence failover groups, run Automation runbooks as pre/post-scripts, and check readiness daily — but they don't protect resources and don't do regional failover. Keep Site Recovery and failover groups for the cross-region layer.
  1. PDPA follows you into DR. Cross-border transfer assessment for your secondary region, mandatory breach notification steps in the failover procedure, and minimised data in the DR site. Your DPIA should name all three.

The era of "we have a DR plan, trust us" should be over. Azure Resiliency — even in preview — finally gives Malaysian enterprises the tooling to prove resilience instead of claiming it. The question is no longer whether you can afford to test your DR plan. It's whether you can afford to walk into your next BNM review with a runbook nobody has ever executed.