Azure / Basic: scope, identity, location, and resources / Lesson 3

Regions, availability zones, and failure boundaries

Choose location and redundancy from residency, service support, and failure requirements. Distinguish a zone outage from a regional disaster and model surviving capacity explicitly.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish region, geography, and availability zone.
Verify service-specific zonal and regional support.
Calculate capacity after a stated failure.

Location is a requirement, not just a dropdown

An Azure region is a set of datacenter facilities and networking in a geographic area, while availability zones provide distinct physical locations within supported regions. Geography, residency, latency, service availability, and operational ownership all influence placement. Do not assume every service, SKU, feature, or redundancy option exists in every region. Some regions are paired and others are not; a pair does not automatically replicate every application or establish a recovery plan. Record current service documentation and the particular option being considered rather than deriving guarantees from a generic map of Azure regions.

A zone strategy must include every critical dependency

Distributing application instances across zones helps only if routing, data, secrets, identity dependencies, and capacity remain usable under the chosen failure. A zone-redundant service and a resource pinned to one zone have different behavior. Logical zone labels and service support must be interpreted within the subscription and region context, not assumed to identify a globally identical datacenter. The JSON model names logical failure domains, not actual Azure placement settings. It declares what the design hopes to survive; it does not prove any real service is zone redundant or that failover was exercised.

json A synthetic zone-capacity plan

{
  "model": "failure-domain-plan",
  "domains": [
    "zone-a",
    "zone-b",
    "zone-c"
  ],
  "instances_per_domain": 3,
  "required_surviving_instances": 5,
  "regional_recovery_plan_required": true
}

Expected output

one-domain loss leaves 6 instances; regional loss needs a separate plan

The labels are not Azure zone identifiers or a deployment document. Application dependency and routing behavior are not simulated.

Redundancy is useful only with enough surviving capacity

For three zones with three equal-capacity instances each, losing one zone leaves six instances. If five are needed for the agreed workload, that arithmetic passes the stated one-zone capacity check. It says nothing about startup time, data failover, network congestion, or actual throughput. Size the surviving path from a measured workload and safe headroom rather than assuming any multi-zone layout is sufficient. The local program demonstrates only the synthetic count and margin. A real verification would also test whether traffic and dependencies use the surviving resources without violating data consistency or access requirements.

python Offline surviving-capacity arithmetic

zones = 3
instances_per_zone = 3
lost_zones = 1
required = 5
surviving = (zones - lost_zones) * instances_per_zone
print(surviving, surviving - required)
print(surviving >= required)

Expected output

6 1
True

Six minus five leaves one synthetic instance of margin. No load, service health, failover, or Azure capacity is measured.

Regional recovery is a separate design

A regional event can affect several zones and shared dependencies, so a one-zone plan is not automatically a disaster-recovery plan. Define recovery time and data-loss objectives, then choose replication, backup, restoration, traffic steering, and decision authority for the complete workload. Cross-region replication may be asynchronous and can copy unwanted changes as well as good data. Backups and tested restores address a different risk from maintaining a replica. Verify data-residency and service-specific recovery constraints before selecting a second location, and do not promise automatic recovery merely because two region names appear in a diagram.

Document which failure was actually evaluated

A useful review names the failure domain, affected dependencies, remaining capacity, recovery assumptions, and evidence still missing. A service SLA has defined conditions and is not the same as the workload’s observed availability or business recovery objective. Avoid multiplying advertised percentages without a justified dependency and independence model. This course calculates hypothetical cases only and performs no failover, service test, or regional deployment. For a future authorized implementation, verify the chosen resource configurations and recovery procedure with controlled tests, and preserve evidence of restoration and user-task completion rather than just a green dashboard.

Common errors and fixes

Every region is assumed to have every zone-capable service

Why it happens: Generic regional presence replaces service-specific verification.
How to fix it: Check the exact service, option, and region support.
Prevent it next time: Record the reviewed documentation and deployment assumptions.

Multi-zone placement is called regional disaster recovery

Why it happens: Failure domains are conflated.
How to fix it: Create a separate complete regional recovery plan.
Prevent it next time: Test zone and region scenarios as different cases.

Replicas are treated as tested backups

Why it happens: Continuity replication is confused with recoverable history.
How to fix it: Define retention and restoration evidence independently.
Prevent it next time: Include corruption and accidental deletion in recovery reasoning.

Check your understanding

1. Nine equal instances are spread evenly over three zones. Five are needed. What does losing one zone establish arithmetically?

Show worked solution

Six remain, leaving one instance above the required count. This passes only the stated equal-capacity count model. It does not prove traffic failover, dependency availability, throughput, or data correctness. Those require separate controlled evidence for the actual services and workload.

2. A region has a paired region. Is the application automatically recoverable there?