Regions, Zones, Availability Domains — Where Your Data Actually Lives
A region choice defines more than a location. It constrains failure isolation, service features and where recovery copies can live. Make the choice against a named business operation and its recovery requirements.
Use the resilience guide to frame recovery time, recovery point and the failure boundary you need to survive. Then validate the actual services and configurations.
Choose the failure boundary first
| Boundary | What it separates | What it does not establish |
|---|---|---|
| Instance or host | Individual compute resources | Independent storage, routing or identity |
| Azure availability zone | Datacenter groups within a region | Protection against a complete regional outage |
| OCI availability domain | One or more datacenters isolated from other ADs | Protection against a complete regional outage |
| OCI fault domain | Hardware and infrastructure groupings within an AD | Protection against loss of that entire AD |
| Another region | A separate regional deployment | Automatic application recovery or independent global dependencies |
An Azure zonal resource runs in a selected zone. To tolerate that zone failing, the application needs healthy capacity and its dependencies elsewhere. Zone-redundant managed services distribute resources across zones, but their supported tiers and configuration requirements vary. Azure logical zone numbers can map differently between subscriptions. Check the physical mappings when placement across subscriptions matters. Microsoft availability-zone documentation
OCI regions contain one or more availability domains; verify the count for the chosen region. Each availability domain contains three fault domains. Fault-domain distribution is useful within an AD, but does not turn a single-AD region into a multi-AD deployment. An AD can include multiple datacenters, so avoid describing it simply as one building. Oracle regions and availability domains
A region pair is not a recovery plan
Some Azure regions have a paired region. Others do not. Pairing affects particular platform behaviors and services; deploying in a paired region does not configure application failover. Even when a storage service replicates to another region, compute, networking, permissions, application state and traffic routing need their own recovery design. Microsoft region-pair guidance
Choose the destination supported by your services and permitted by your requirements. Document how data reaches it, who can activate it, what capacity exists and how users reach the recovered operation. Treat failback as a separate procedure.
Residency applies to the recovery design too
Record the allowed locations for production records, backups, replicas, logs, keys and support-related processing. A regional resource label alone does not describe every data flow or contractual commitment. Global services and managed backup settings need specific review.
If the workload must remain in one region, zone redundancy and protected recovery points may still be appropriate. They cannot keep the operation available during loss of that entire region. Record that limitation and align the recovery target with the permitted design. Microsoft guidance on regional constraints
Use the cloud compliance guide to identify questions about placement and protection. It does not replace checking the particular service and contract.
Validate the whole dependency chain
Two application instances can still share one database, one identity dependency, one deployment pipeline or one route. List what must work for a user to complete the business operation. For each dependency, record its failure scope, recovery mechanism and owner.
A representative recovery exercise should include access to credentials and keys, data consistency, available capacity, traffic changes and a real business transaction. Record elapsed interruption and the age of the recovered data. Restoring a server is only one step. Microsoft disaster-recovery guidance
Before committing to a region
- Agree the operation, recovery targets and failure scenarios.
- Verify zone/AD support for each critical service and tier.
- Check permitted primary and recovery locations.
- Verify destination features, quotas and capacity.
- Identify shared dependencies and owners.
- Exercise recovery and document gaps.
For the service-by-service checks, continue with Service Availability by Region.