Cloud platforms are often described as highly available and resilient. That can create a dangerous assumption: If my application is hosted in Azure, Azure will automatically keep it running when infrastructure fails. The reality is more nuanced. Azure provides the infrastructure and services required to build resilient applications, but the final result still depends on the architecture you choose. So if one Azure datacenter goes down, does your application go down too? The correct answer is: it depends. The four infrastructure levels Before discussing failures, we need to distinguish between four related Azure concepts. Component Simple meaning What it protects against Datacenter A physical facility containing computing infrastructure Nothing by itself Availability Zone An isolated location within a region A datacenter or zone-level failure Region A geographical area containing one or more datacenters Provides a deployment location Region Pair A relationship between two distant Azure regions Supports geographical disaster recovery Let’s examine each one. 1. Azure datacenters A datacenter is a physical facility containing servers, storage devices, networking equipment, power systems, and cooling systems. Azure operates datacenters around the world, but customers do not normally select an individual datacenter directly. Instead, Azure organizes datacenters into regions and Availability Zones. A single datacenter can still experience problems such as: Power failure Cooling failure Network disruption Hardware failure Fire or another physical incident Running a workload in the cloud does not make these physical risks disappear. Cloud resiliency comes from designing the workload so that the failure of one component does not bring down the entire application. 2. Availability Zones An Availability Zone is made up of one or more physically separate datacenters within an Azure region. Each zone has independent: Power Cooling Networking infrastructure Availability Zones are connected using high-speed private networks. The objective is isolation. If one zone experiences an outage, resources running in another zone can continue operating. However, this does not mean that every resource is automatically protected. Azure services can behave differently. Zonal resources A zonal resource is deployed into a specific Availability Zone. For example, if you deploy one virtual machine into Zone 1, that machine remains dependent on Zone 1. If the zone becomes unavailable, the VM may also become unavailable. Zone-redundant resources A zone-redundant service distributes or replicates its workload across multiple Availability Zones. If one zone fails, another zone can continue providing the service. Support for zone redundancy depends on the Azure service and the selected region. The important lesson is: Having Availability Zones available is not the same as using them. Your architecture and configuration determine whether your application is protected. 3. Azure regions An Azure region is a geographical area containing at least one, and potentially multiple, nearby datacenters connected through a low-latency network. When deploying many Azure resources, you select a region such as West Europe or East US. The selected region can affect: Service availability Network latency Pricing Data residency Compliance requirements Disaster-recovery options A region may contain multiple Availability Zones, but not every Azure region supports zones. Even when zones are supported, selecting the region does not necessarily distribute your resources across them. You must choose services and configurations that provide the required level of redundancy. 4. Azure region pairs An Availability Zone helps protect against a failure inside one region. But what happens if an event affects the entire region? For wider geographical resilience, most Azure regions are paired with another region within the same geography and separated by a significant distance. Region pairs can support: Cross-region data replication Disaster-recovery planning Prioritized regional recovery Reduced risk during planned platform updates But there is an important warning: A region pair does not automatically protect every workload. Not every Azure service automatically replicates data or fails over to its paired region. In many cases, the customer must configure replication, backup, routing, and failover. Additionally, not every Azure region has a traditional region pair. A resilient cross-region architecture must therefore be planned deliberately instead of assumed. What happens during a failure? Consider three simplified architectures. Scenario 1: One VM in one zone Your application runs on one virtual machine deployed in a single Availability Zone. If that VM or zone becomes unavailable, the application can become unavailable. The cloud provider still cannot remove a single point of failure that exists in your architecture. Scenario 2: Workload distributed across zones Your application runs across multiple Availability Zones, with traffic distributed between healthy instances. If one zone fails, the remaining instances may continue serving users. This architecture provides protection against zone-level failures, assuming every critical component is also designed appropriately. A multi-zone application can still fail if its database, storage, or another dependency remains a single point of failure. Scenario 3: Workload distributed across regions Your application has resources and replicated data in more than one Azure region. If an entire region becomes unavailable, traffic can be redirected to the secondary region according to the configured recovery plan. This provides stronger protection, but it also introduces additional: Cost Complexity Data-replication requirements Testing requirements Operational responsibility Maximum redundancy is not always the correct answer. The architecture should match the business impact of downtime. A practical resilience checklist Before deploying an important workload, ask: How much downtime can the application tolerate? How much data loss is acceptable? Does the selected Azure region support Availability Zones? Are the services zonal or zone-redundant? Are all critical components protected? Is cross-region replication required? Is failover automatic or manual? Has the recovery process actually been tested? A disaster-recovery plan that has never been tested is still only a theory. The key takeaway Azure provides datacenters, Availability Zones, regions, and cross-region capabilities. But simply moving an application to the cloud does not automatically make it resilient. The cloud gives you the building blocks. Your architecture determines what happens when something fails. Microsoft Learn provides a concise beginner module explaining Azure’s physical and management infrastructure: https://learn.microsoft.com/en-us/training/modules/describe-core-architectural-components-of-azure/?wt.mc_id=studentamb_615882 If one component of your current application failed today, would the rest of the system continue working?