Service Availability by Region — Why You Cannot Trust the Map

A provider’s region map is a useful starting point. It does not prove that a particular service tier, deployment shape or recovery configuration is available to your subscription.

For recovery planning, verify the destination as carefully as production. A backup in another region is not enough if the application cannot be deployed or operated there.

Separate four different questions

Check	Evidence to collect
Service and feature support	Current documentation for the exact region, service, tier and feature
Access and eligibility	Subscription, account, commercial and preview requirements
Quota	Approved limits sufficient for production and recovery
Capacity	Evidence that the needed resources can be allocated, including any applicable reservation

These are distinct checks. A quota increase is permission to consume more resources; it is not a blanket capacity reservation. Review the resource-specific limits and allocation behavior. Azure limits and quotas

Start with provider sources

For Azure, start with Products available by region. Follow that with the service reliability guide and the service’s tier, SKU and deployment documentation.

For OCI, use the regions and service availability documentation, followed by the particular service’s limits and recovery documentation. Check the intended realm and region, not an apparently comparable commercial location.

Record source links and a review date. Where documentation leaves uncertainty, confirm it with the provider and test a representative deployment in the intended account. A successful small test does not reserve future recovery capacity.

Check the recovery configuration, not just the service name

A useful register describes a concrete requirement: the database tier, required storage features, zone support, replication method, recovery destination and network connectivity. “Managed database available” is too broad.

Record the primary and recovery configurations side by side. Feature differences may require a different recovery pattern, a different location or a revised business requirement. Include keys, private endpoints, DNS, identity and monitoring in the comparison.

A supported region pair does not automatically configure disaster recovery. Verify each service’s actual behavior and the application’s recovery steps. Azure region-pair limitations

Treat preview status as an explicit decision

Read the terms for the specific preview: production permission, support, SLA, data handling, breaking changes and a migration path. Do not infer suitability from how long a feature has been in preview or from a case study.

Record the accepted limitations and the fallback if the feature changes or disappears. Where the provider excludes production use, respect that restriction. A generic label such as “preview” or “sovereign” is not a substitute for the applicable service terms.

Inventory helps find drift, not prove availability

An inventory query shows resources that exist and that the caller can see. It does not prove that new resources of the same kind can be deployed during an outage.

For Azure Resource Graph, an inventory can group deployed resource types by location:

Resources
| summarize resourceCount=count() by subscriptionId, location, type
| order by location asc

For OCI, Search only covers supported resource types and the resources visible under the caller’s permissions. Review its coverage before treating it as an estate-wide inventory. OCI Search overview

Compare the inventory with the approved register. Investigate unexpected resources and missing dependencies; do not turn an inventory into an availability guarantee.

A practical review record

Keep one row for each required primary or recovery configuration:

• Business operation and technical owner.
• Region, account, service, tier and required features.
• Eligibility, quotas and capacity assumptions.
• Data location and key-access requirements.
• Provider references and verification date.
• Deployment and recovery test evidence.
• Open gaps, accepted risks and the next review trigger.

Revisit the record after a material architecture change, a provider announcement that affects it or a failed exercise. Use the resilience planner to establish the targets the register must support, and the platform guide to clarify who operates the chosen services.