Relocate Azure Key Vault to another region (2024)

Article
04/11/2024

There are various reasons why you may want to move your existing Azure resources from one region to another. You may want to:

Take advantage of a new Azure region.
Deploy features or services available in specific regions only.
Meet internal policy and governance requirements.
Align with company mergers and acquisitions
Meet capacity planning requirements.

Azure Key Vault doesn't support key vault relocation to another region.

Instead of relocation, you need to:

Create a new key vault with the relocation of the associated Azure services.
Regenerate any required keys, secrets, or certificates. In some cases, you may need to transfer the secrets or certificates from your existing key vault to the relocated key vault.

Prerequisites

Verify that your Azure subscription allows you to create key vaults in the target region.
Create a dependency map with all the Azure services used by the Key Vault. For the services that are in scope of the relocation, you must choose the appropriate relocation strategy.
Depending on your Key Vault design, you may need to deploy and configure the Virtual Network in the target region.
Document and plan to re-configure in the Key Vault in the target region:
- Access Policies and Network configuration settings.
- Soft delete and purge protection.
- Autorotation settings.

Downtime

To understand the possible downtimes involved, see Cloud Adoption Framework for Azure: Select a relocation method.

Consideration for Service Endpoints

The virtual network service endpoints for Azure Key Vault restrict access to a specified virtual network. The endpoints can also restrict access to a list of IPv4 (internet protocol version 4) address ranges. Any user connecting to the Key Vault from outside those sources is denied access. If Service endpoints were configured in the source region for the Key Vault resource, the same would need to be done in the target one.

For a successful recreation of the Key Vault to the target region, the VNet and Subnet must be created beforehand. In case the move of these two resources is being carried out with the Azure Resource Mover tool, the service endpoints won’t be configured automatically. Hence, they need to be configured manually, which can be done through the Azure portal, the Azure CLI, or Azure PowerShell.

Consideration for Private Endpoint

Azure Private Link provides private connectivity from a virtual network to Azure platform as a service (PaaS), customer-owned, or Microsoft partner services. Private Link simplifies the network architecture and secures the connection between endpoints in Azure by eliminating data exposure to the public internet.

For a successful recreation of the Key Vault in the target region, the VNet and Subnet must be created before the actual recreation occurs.

Consideration for Azure Private Endpoint DNS Integration

It’s important to correctly configure your DNS settings to resolve the private endpoint IP address to the fully qualified domain name (FQDN) of the connection string.

Existing Microsoft Azure services might already have a DNS configuration for a public endpoint. This configuration must be overridden to connect using your private endpoint.

The network interface associated with the private endpoint contains the information to configure your DNS. The network interface information includes FQDN and private IP addresses for your private link resource.

You can use the following options to configure your DNS settings for private endpoints:

Use the host file (only recommended for testing). You can use the host file on a virtual machine to override the DNS.
Use a private DNS zone. You can use private DNS zones to override the DNS resolution for a private endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
Use your DNS forwarder (optional). You can use your DNS forwarder to override the DNS resolution for a private link resource. Create a DNS forwarding rule to use a private DNS zone on your DNS server hosted in a virtual network.

Prepare

Portal
PowerShell

To export a template by using Azure portal:

Sign in to the Azure portal.
Select All resources and then select your key vault.
Select > Automation > Export template.
Choose Download in the Export template blade.
Locate the .zip file that you downloaded from the portal, and unzip that file to a folder of your choice.
This zip file contains the .json files that comprise the template and scripts to deploy the template.

Keep in mind the following concepts:

Key vault names are globally unique. You can't reuse a vault name.
You need to reconfigure your access policies and network configuration settings in the new key vault.
You need to reconfigure soft-delete and purge protection in the new key vault.
The backup and restore operation doesn't preserve your autorotation settings. You might need to reconfigure the settings.

Modify the template

Modify the template by changing the key vault name and region.

Portal
PowerShell

To deploy the template by using Azure portal:

In the Azure portal, select Create a resource.
In Search the Marketplace, type template deployment, and then press ENTER.
Select Template deployment.
Select Create.
Select Build your own template in the editor.
Select Load file, and then follow the instructions to load the template.json file that you downloaded in the last section.

In the template.json file, name the key vault by setting the default value of the key vault name. This example sets the default value of the key vault name to mytargetaccount.

"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#","contentVersion": "1.0.0.0","parameters": { "vaults_name": { "defaultValue": "key-vault-name", "type": "String" }},

Edit the location property in the template.json file to the target region. This example sets the target region to centralus.
```
"resources": [ { "type": "Microsoft.KeyVault/vaults", "apiVersion": "2023-07-01", "name": "[parameters('vaults_name')]", "location": "centralus", ... }, ...]
```
To obtain region location codes, see Azure Locations. The code for a region is the region name with no spaces, Central US = centralus.

Remove resources of typ private endpoint in the template.

{"type": "Microsoft.KeyVault/vaults/privateEndpointConnections",...}

In case you configured a service endpoint in your key vault, in the networkAcl section, under virtualNetworkRules, add the rule for the target subnet. Ensure that the ignoreMissingVnetServiceEndpoint flag is set to False, so that the IaC fails to deploy the Key Vault in case the service endpoint isn’t configured in the target region.

parameter.json

{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "target_vnet_externalid": { "value": "virtualnetwork-externalid" }, "target_subnet_name": { "value": "subnet-name" } }}

_template.json

 "networkAcls": { "bypass": "AzureServices", "defaultAction": "Deny", "ipRules": [], "virtualNetworkRules": [ { "id": "[concat(parameters('target_vnet_externalid'), concat('/subnets/', parameters('target_subnet_name')]", "ignoreMissingVnetServiceEndpoint": false } ] }

Redeploy

Deploy the template to create a new key vault in the target region.

Portal
PowerShell

Save the template.json file.
Enter or select the property values:
- Subscription: Select an Azure subscription.
- Resource group: Select Create new and give the resource group a name.
- Location: Select an Azure location.
Select I agree to the terms and conditions stated above, and then select Select Purchase.
Access Policies and Network configuration settings (private endpoints) need to be re-configured in the new Key Vault. Soft delete and purge protection need to be re-configured in the new key vault and the Autorotation settings.

Tip

If you receive an error which states that the XML specified is not syntactically valid, compare the JSON in your template with the schemas described in the Azure Resource Manager documentation.

Redeploy with data migration

Important

If you plan to move a Key Vault across regions but within the same geography, it's recommended that you do a backup and restore for secrets, keys and certificates is recommended.

Follow steps described in the redeploy approach.
For secrets:
1. Copy and save the secret value in the source key vault.
2. Recreate the secret in the target key vault and set the value to saved secret.
For certificates:
1. Export the certificate into a PFX file.
2. Import the PFX file into the target key vault. If you can't export the private key (exportable is not set) you must generate certificate a new certificate and import it into the target key vault.
With the relocation of the associated Azure service the keys are regenerated.
Confirm that the keys have been generated for the associated service.

Verify

Before deleting your old key vault, verify that the new vault contains all of the required keys, secrets, and certificates after the relocation of the associated Azure services.