Enable zone redundancy and AZ migration capability disabled

The error indicates that the subscription is currently not allowed to perform the internal migration that enables availability zones for an existing Azure Cosmos DB region. That subscription-level capability can only be enabled by Microsoft, so a support request is required.

For the technical steps, the supported way to enable zone redundancy on an existing Azure Cosmos DB account is:

1. Add a temporary region to the account.
2. Fail over writes to the temporary region (if the account is single‑write‑region).
3. Remove the original region.
4. Add the original region back with Availability Zones/isZoneRedundant=True.
5. Fail over writes back to the newly zone‑redundant region.
6. Remove the temporary region.

This process can be done either in the Azure portal or with Azure CLI.

Using the Azure portal:

1. Add a temporary region to the database account as described in "Add region to your database account".
2. Wait until the new region is marked Available.
3. If the account is not configured for multi‑region writes, change the write region to the temporary region using the failover‑priority settings.
4. Remove the region that needs zone redundancy.
5. Add that region back, then in the Write region column enable Availability Zone for that region and save.
6. Wait until the region is Available.
7. Change the write region back to this zone‑redundant region.
8. Remove the temporary region.

Using Azure CLI (example with eastus as original and westus as temporary):

1. Add temporary region:

    az cosmosdb update \
    --name MyCosmosDBDatabaseAccount \
    --resource-group MyResourceGroup \
    --locations regionName=eastus failoverPriority=0 isZoneRedundant=False \
    --locations regionName=westus failoverPriority=1 isZoneRedundant=False
   

2. After the region is Available, if the account is single‑write‑region, fail over writes to westus:

    az cosmosdb failover-priority-change \
    --name MyCosmosDBDatabaseAccount \
    --resource-group MyResourceGroup \
    --failover-policies westus=0 eastus=1
   

3. Remove the original region:

    az cosmosdb update \
    --name MyCosmosDBDatabaseAccount \
    --resource-group MyResourceGroup \
    --locations regionName=westus failoverPriority=0 isZoneRedundant=False
   

4. Add the original region back with zone redundancy:

    az cosmosdb update \
    --name MyCosmosDBDatabaseAccount \
    --resource-group MyResourceGroup \
    --locations regionName=westus failoverPriority=0 isZoneRedundant=False \
    --locations regionName=eastus failoverPriority=1 isZoneRedundant=True
   

5. After it is Available, fail over writes back:

    az cosmosdb failover-priority-change \
    --name MyCosmosDBDatabaseAccount \
    --resource-group MyResourceGroup \
    --failover-policies eastus=0 westus=1
   

6. Remove the temporary region:

    az cosmosdb update \
    --name MyCosmosDBDatabaseAccount \
    --resource-group MyResourceGroup \
    --locations regionName=eastus failoverPriority=0 isZoneRedundant=True
   

Important operational considerations from the documented process:

• Zone redundancy is configured per region, not per account; only regions that support availability zones can be made zone‑redundant.
• Enabling zone redundancy on an existing account requires adding/removing regions as above; it cannot be toggled directly on an already‑added region.
• There is a brief write unavailability (a few seconds) when adding/removing the secondary region, and additional cost for the temporary region and replication.

Regarding whether to create a new account instead of modifying the existing one:

• Documentation supports both creating a new zone‑redundant account and enabling zone redundancy on an existing one.
• Creating a new account with zone redundancy is straightforward: when creating the account, enable Availability Zones in the portal or set isZoneRedundant=True for the desired regions via CLI/Bicep/ARM.
• Migrating to a new account shifts complexity to data and traffic migration (moving data and switching connection strings), whereas the documented procedure keeps the same account identity and endpoints but requires temporary regional changes and brief write downtime.

Given the error about AZ migration capability being disabled, the next step is to open an Azure support request to have that capability enabled for the subscription or to get guidance specific to that subscription. Once enabled, follow the documented region add/remove procedure above to turn on zone redundancy for the existing account. Creating a new account is an alternative, but it does not avoid the need for data migration and application reconfiguration.

---

References:

• Enable zone redundancy on an Azure Cosmos DB account
• Reliability in Azure Cosmos DB

AI-generated content may be incorrect. Read our transparency notes for more information.