Is Your Azure Environment Actually Resilient?

What are the three areas of Azure resiliency? 

Azure resiliency can be considered across three interconnected areas: 

• Infrastructure resiliency: keeping applications available during failure conditions. 
• Data resiliency: keeping data protected, durable and recoverable. 
• Cyber recovery: recovering safely from a compromised state. 

A highly available application isn’t much use if you can’t recover trusted data after an attack. Likewise, having backups doesn’t mean customers can continue using your application during a regional outage. You need to consider the workload as a whole. 

Who is responsible for resiliency in Azure? 

Microsoft provides the foundation. This includes: 

• Azure regions 
• Physical datacentres 
• Networking 
• Isolation boundaries 
• Availability Zones
• Recovery capabilities such as Azure Backup and Azure Site Recovery. 

You’re responsible for how your application handles failures, dependencies, recovery objectives, backups and disaster recovery. 

For regulated and sovereign workloads, this also includes deciding where data can reside, how it moves and how recovery remains within jurisdictional and compliance requirements.

How can regional and geopolitical disruption affect Azure?

Regional disruption doesn’t necessarily start inside Azure. Cloud applications depend heavily on telecommunications networks and undersea cables. Conflicts can affect communication routes when cables, landing stations or telecommunications infrastructure are damaged.

The 2025 Red Sea undersea cable disruptions, for example, affected internet connectivity across parts of the Middle East and Asia. Microsoft reported increased latency affecting connectivity in the region before Azure services were subsequently restored.

That’s an important distinction: your Azure resources can be running while your customers still experience disruption.

Regional resiliency therefore needs to consider more than datacentres. Connectivity, latency, capacity, data residency and the ability to operate elsewhere can all become part of the equation.

Redundancy vs resiliency

• Redundancy means you’ve duplicated critical resources.
• Resiliency means the system can actually respond to failure and continue delivering the service your customers need.

That difference matters. You could have infrastructure sitting in two regions and still have an app that can’t successfully fail over. A shared dependency could fail. Data might not be synchronised correctly. Your deployment could rely on functionality unavailable in the secondary region.

Multi-region redundancy can form part of a resilient architecture, but simply deploying resources elsewhere doesn’t prove that your workload will keep working.

Azure regions aren’t identical. A workload that runs in one Azure region isn’t guaranteed to run unchanged in another. Azure service availability, infrastructure capabilities and capacity can differ between regions.

Your target region could differ in:

• Azure service availability.
• Availability Zone support.
• VM SKU availability.
• Regional capacity.
• CPU-to-memory ratios.
• Processor architecture.
• Network latency.

Your deployment configuration matters too. A hard-coded region in your Infrastructure as Code (IaC) or another deployment script could prevent infrastructure from deploying somewhere else.

Processor architecture can create another problem. If available capacity in your recovery region uses ARM processors, your container images also need to support ARM.

A secondary region is only useful if your workload can actually run there.

Data residency can restrict your options

Geopolitical resilience also intersects with sovereignty. The technically obvious failover destination isn’t always an acceptable destination for your data.

Some Azure regions are paired. Others are non-paired due to geographic, regulatory or sovereignty constraints. In some environments, moving sensitive data across a border may simply not be an acceptable recovery strategy.

This creates several possible approaches:

• Paired-region recovery: use a more predictable primary and secondary recovery pattern.
• Non-paired region recovery: select the secondary region according to service availability, capacity, latency and data residency requirements.
• Asymmetric recovery: fail over critical services using Azure Site Recovery while sensitive data remains within its required boundary and relies on Azure Backup for recovery.

Your disaster recovery strategy therefore needs to fit your workload, not the other way around.

Your application may be your biggest resiliency risk

Highly available Azure infrastructure can still run a fragile application. Your code needs to handle failure correctly if you want to make use of the resiliency Azure provides.

Common application-level risks include:

• Transient errors: if your application talks to Azure SQL, your code needs to account for temporary failures.
• Multiple replicas: Kubernetes can run multiple replicas, but your application still needs to work correctly across them.
• Session and token affinity: these can create dependencies that make scaling or failover more difficult.
• Service dependencies: the way multiple instances interact with a service bus can expose assumptions within the application architecture.
• Single-instance design: an application built around one instance can prevent you from using Azure’s high-availability capabilities.

At some point, software architecture becomes the limiting factor in your Azure resiliency.

This is particularly relevant for "lift-and-shift" migrations. You can move an existing problem to Azure and end up with the same problem running on somebody else’s infrastructure.

Infrastructure improvements only take you so far. Development practices need to account for failure too.

Stop measuring Azure resiliency by SLA alone

It’s tempting to look at the SLA for each component and conclude that the workload is highly resilient. But what happens when one dependency fails and the whole application stops working?

That’s why individual availability percentages don’t give you the complete picture. Your customer doesn’t care which Azure resource failed. They care that your service stopped working.

SLAs still have a place, particularly for contractual, legal and compliance reasons.

But operationally, the better questions are:

• Can customers still use the application?
• Can they still place orders?
• Can employees and customers authenticate?
• Is critical data still available?
• What happens when a dependency disappears?
• How quickly can the service recover?

Measure resiliency from the workload and customer perspective, not resource by resource.

How to build a more resilient Azure environment

Azure resiliency requires several layers working together. Zone-resilient infrastructure, application architecture, data protection, regional recovery and testing all contribute to the final workload outcome.

There isn’t one architecture that makes every workload resilient. Your approach needs to balance recovery speed, cost, complexity, regulatory requirements and operational effort.

Start with Availability Zones

A zone-resilient Azure workload should continue operating when an Availability Zone becomes unavailable.

Taking a VM offline doesn’t necessarily simulate the impact of losing a complete zone. Your workload has dependencies across compute, data, networking and other services.

You therefore need to understand how the application behaves when an entire part of its underlying environment becomes unavailable.

Choose the right regional resilience pattern

The right Azure resilience pattern depends on the workload, recovery objectives, geographic risk and regulatory constraints. More redundancy isn’t automatically the right answer.

Common approaches include:

• In-region high availability: use multiple Availability Zones within one Azure region.
• Regional BCDR: use a primary and secondary region, selected around geographic risk, service availability and regulatory requirements.
• Non-paired region BCDR: choose a secondary region based on capacity, latency, data residency and required Azure services.
• Multi-region active/active: run production workloads across several regions simultaneously.
• Asymmetric recovery: use different recovery methods for different components when regulation or data residency prevents everything from failing over in the same way.

More resiliency also means more cost and complexity.

An active/active architecture can make sense when downtime carries a significant financial impact. At other times, active/passive recovery may provide a better balance between resilience and cost.

Ask yourself: How much disruption can this workload tolerate, and what are we prepared to spend to reduce that risk?

Design your application for failure

Your application should expect infrastructure and dependencies to fail. Failure handling needs to be part of application architecture rather than something added only at the infrastructure level.

That includes thinking about:

• Transient failures.
• Multiple application instances.
• Replicas.
• Database behaviour.
• Session state.
• Caching.
• Identity.
• DNS.
• Shared dependencies.

Hidden dependencies deserve particular attention.

A multi-region application can still depend on one component that causes the entire workload to fail. Mapping those dependencies helps expose single points of failure before an outage does it for you.

Make your infrastructure portable

If another region forms part of your recovery plan, prove that you can deploy there.

Check your infrastructure as code for regional assumptions. Confirm the Azure services you require exist in the target region. Check SKUs, Availability Zones, processor architectures, regional capacity and subscription quotas.

“We can redeploy it somewhere else” isn’t a recovery strategy until you’ve demonstrated that it works.

Test what happens when Azure fails

A resilient architecture that has never been tested is still based on assumptions. Failure testing shows how the complete workload behaves when individual resources, dependencies or zones become unavailable.

You need to understand what happens when a VM fails, a network connection drops, DNS becomes unavailable or an Availability Zone disappears.

Use Azure Chaos Studio to test failure scenarios

Azure Chaos Studio lets you use fault injection to run hypotheses, game days and test different failure modes. These can include a VM failing, a network connection dropping or a DNS failure, modelled on things that have happened in Azure.

This is the idea behind chaos engineering. You simulate failures to see how your system responds and find weaknesses in your cloud architecture.

This practice lets you validate recovery mechanisms and make sure they work during disruptions. Regular chaos testing builds confidence in your system’s resilience.

Measure resilience with Azure Infrastructure Resiliency Manager

Azure Infrastructure Resiliency Manager, introduced at Microsoft Build 2026 and available in public preview, helps assess resiliency at application and resource level.

It brings together capabilities including Azure Advisor, Azure Chaos Studio and Azure Monitor. Service groups let you assess application resources across resource groups and subscriptions as one workload.

It follows a three-stage lifecycle:

• Start resilient: build with the right foundations.
• Get resilient: identify and address weaknesses.
• Stay resilient: continuously test and monitor.

The important point isn’t another Azure feature. It’s the shift towards measuring resiliency at workload level and making continuous validation part of operations.

Automate assessments with the Azure Resiliency Agent

The Azure Resiliency Agent evaluates workloads for risks, misconfigurations and resilience trade-offs. It can consider cost, availability and compliance, and generate infrastructure-as-code templates for recommended changes.

This brings resiliency into DevOps workflows, making it something teams can continuously assess rather than review as a separate architecture exercise.

The Azure Backup MCP Server can also make backup validation, recovery-readiness checks and policy-driven restores programmable.

Closing thoughts

Azure resiliency isn’t simply about replicas, failover or SLAs. It’s about keeping your workload operating, protecting what matters and recovering safely when something goes wrong.

And resiliency isn’t static. Applications and dependencies change, so the environment you designed isn’t necessarily the environment you’re running today.

There’s no single resilience pattern for every workload, or one that removes every risk. You’ll never be 100% resilient. Failure is ultimately a probability problem. As applications and dependencies change, the goal is to reduce risk, test what matters and know how your workload will respond.

Because ultimately, resiliency comes down to one thing: when something goes wrong, can your service keep working?