Enable geo-replication (Preview)

This article covers replication of Azure App Configuration stores. You'll learn about how to create, use and delete a replica in your configuration store.

To learn more about the concept of geo-replication, see Geo-replication in Azure App Configuration.

Prerequisites

Create and list a replica

To create a replica of your configuration store in the portal, follow the steps below.

  1. In your App Configuration store, under Settings, select Geo-replication.

  2. Under Replica(s), select Create. Choose the location of your new replica in the dropdown, then assign the replica a name. This replica name must be unique.

    Screenshot of the Geo Replication button being highlighted as well as the create button for a replica.

  3. Select Create.

  4. You should now see your new replica listed under Replica(s). Check that the status of the replica is "Succeeded", which indicates that it was created successfully.

    Screenshot of the list of replicas that have been created for the configuration store.

Delete a replica

To delete a replica in the portal, follow the steps below.

  1. In your App Configuration store, under Settings, select Geo-replication.

  2. Under Replica(s), select the ... to the right of the replica you want to delete. Select Delete from the dropdown.

     Screenshot showing the three dots on the right of the replica being selected, showing you the delete option.

  3. Verify the name of the replica to be deleted and select OK to confirm.

  4. Once the process is complete, check the list of replicas that the correct replica has been deleted.

Use replicas

Each replica you create has its dedicated endpoint. If your application resides in multiple geolocations, you can update each deployment of your application in a location to connect to the replica closer to that location, which helps minimize the network latency between your application and App Configuration. Since each replica has its separate request quota, this setup also helps the scalability of your application while it grows to a multi-region distributed service.

When geo-replication is enabled, and if one replica isn't accessible, you can let your application failover to another replica for improved resiliency. App Configuration provider libraries have built-in failover support by accepting multiple replica endpoints. You can provide a list of your replica endpoints in the order of the most preferred to the least preferred endpoint. When the current endpoint isn't accessible, the provider library will fail over to a less preferred endpoint, but it will try to connect to the more preferred endpoints from time to time. When a more preferred endpoint becomes available, it will switch to it for future requests.

Assuming you have an application using Azure App Configuration, you can update it as the following sample code to take advantage of the failover feature.

Note

You can only use Azure AD authentication to connect to replicas. Authentication with access keys is not supported during the preview.

Edit the call to the AddAzureAppConfiguration method, which is often found in the program.cs file of your application.

configurationBuilder.AddAzureAppConfiguration(options =>
{
    // Provide an ordered list of replica endpoints
    var endpoints = new Uri[] {
        new Uri("https://<first-replica-endpoint>.azconfig.io"),
        new Uri("https://<second-replica-endpoint>.azconfig.io") };
    
    // Connect to replica endpoints using AAD authentication
    options.Connect(endpoints, new DefaultAzureCredential());

    // Other changes to options
});

Note

The failover support is available if you use version 5.3.0-preview or later of any of the following packages.

  • Microsoft.Extensions.Configuration.AzureAppConfiguration
  • Microsoft.Azure.AppConfiguration.AspNetCore
  • Microsoft.Azure.AppConfiguration.Functions.Worker

The failover may occur if the App Configuration provider observes the following conditions.

  • Receives responses with service unavailable status (HTTP status code 500 or above).
  • Experiences with network connectivity issues.
  • Requests are throttled (HTTP status code 429).

The failover won't happen for client errors like authentication failures.

Next steps