Multi-region solutions in nonpaired regions

Some Azure services support geo-redundancy and geo-replication by using paired regions, but you can create solutions that support multiple regions even when those regions aren't paired. This article lists some of the services and possible configurations for multi-region solutions that don't require paired regions. To learn more about each Azure service and how it supports reliability, see the Azure service reliability guides.

To learn about how to create multi-region solutions using Azure AI Search, see Reliability in AI Search.

Azure API Management

To learn about how to create multi-region solutions by using Azure API Management, see Reliability in API Management.

Azure App Service

To learn about how to create multi-region solutions by using Azure App Service, see Reliability in App Service.

Azure Blob Storage

To learn about how to create multi-region solutions using Azure Blob Storage, see Reliability in Blob Storage.

Azure Cache for Redis

Azure Cache for Redis provide one cross-region replication options that is passive geo-replication. In this cases, there's no explicit dependency on region pairs.

Azure Container Registry

To learn about how to create multi-region solutions by using Azure Container Registry, see Reliability in Container Registry.

Azure Cosmos DB

If your solution requires continuous uptime during region outages, you can configure Azure Cosmos DB to replicate your data across multiple regions and to transparently fail over to operating regions when required. Azure Cosmos DB supports multi-region writes and can distribute your data globally to provide low-latency access to your data from any region without any pairing restrictions.

Azure Database for MySQL

Choose any Azure Database for MySQL available Azure regions to create your read replicas.

Azure Database for PostgreSQL

For geo-replication in nonpaired regions with Azure Database for PostgreSQL, you can use a managed service that supports geo-replication. The Azure Database for PostgreSQL managed service supports active geo-replication to create a continuously readable secondary replica of your primary server. The readable secondary replica might be in the same Azure region as the primary server or, more commonly, in a different region. This kind of readable secondary replica is also known as geo-replica.

You can also use either of the following customer-managed data migration methods to replicate data to a nonpaired region:

Azure Event Grid

For geo-replication of Azure Event Grid topics in nonpaired regions, you can implement client-side failover.

Azure Kubernetes Service (AKS)

To learn about how to create multi-region solutions by using Azure Kubernetes Service (AKS), see Reliability in AKS.

Azure Monitor Logs

Log Analytics workspaces in Azure Monitor Logs don't use paired regions. To ensure business continuity and protect against data loss, enable cross-region workspace replication.

Azure Queue Storage

To learn about how to create multi-region solutions by using Azure Queue Storage, see Reliability in Queue Storage.

Azure SQL Database

For geo-replication in nonpaired regions with Azure SQL Database, you can use the following features:

  • The failover group feature, which replicates across any combination of Azure regions without any dependency on underlying geo-redundant storage.

  • The active geo-replication feature to create a continuously synchronized, readable secondary database for a primary database. The readable secondary database might be in the same Azure region as the primary database or, more commonly, in a different region. This kind of readable secondary database is also known as a geo-secondary or geo-replica.

Azure SQL Managed Instance

For geo-replication in nonpaired regions with Azure SQL Managed Instance, you can use the following feature:

  • The failover group feature, which replicates across any combination of Azure regions without any dependency on underlying geo-redundant storage.

Azure Storage

To achieve geo-replication in nonpaired regions:

  • For object storage:

  • For Azure Files:

    Important

    You must disable cloud tiering to ensure that all data is present locally. You must also provision enough storage on the Azure VM to hold the entire dataset. To ensure that changes replicate quickly to the secondary region, files should only be accessed and modified on the server endpoint rather than in Azure.

  • For Queue Storage:

  • For Azure Table Storage:

Azure Table Storage

To learn about how to create multi-region solutions using Azure Table Storage, see Reliability in Azure Table Storage.

Azure Virtual Desktop

For geo-replication in nonpaired regions for Azure Virtual Desktop, you need to consider session host VMs and storage for user profiles, applications, and data. Azure manages the Azure Virtual Desktop control plane, which is globally distributed and highly available.

  • For session hosts, you can deploy VMs in multiple regions in an active-active scenario, or replicate them across regions by using Azure Site Recovery in an active-passive scenario.

  • For storage, see Azure Storage.

For more information, see Multiregion business continuity and disaster recovery (BCDR) for Azure Virtual Desktop and Azure Virtual Desktop service architecture and resilience.

Azure Virtual Machines

To achieve geo-replication in nonpaired regions, use Site Recovery . Site Recovery is the disaster recovery service from Azure that provides BCDR by replicating workloads from the primary location to the secondary location. The secondary location can be a nonpaired region if Site Recovery supports it.

Next steps