Edit

Share via

Enable geo-replication

  • Article

This article covers replication of Azure App Configuration stores. You 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.

Note

Creating a replica for an App Configuration store with private endpoints configured with Static IP is not supported. If you prefer a private endpoint with Static IP configuration, replicas must be created before any private endpoint is added to a store.

  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.

Automatic replica discovery

The App Configuration providers can automatically discover any replicas from a given App Configuration endpoint and attempt to connect to them. This feature allows you to benefit from geo-replication without having to change your code or redeploy your application. This means you can enable geo-replication or add extra replicas even after your application has been deployed.

Automatic replica discovery is enabled by default, but you can refer to the following sample code to disable it (not recommended).

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

configurationBuilder.AddAzureAppConfiguration(options =>
{
    // Disable automatic replica discovery
    options.ReplicaDiscoveryEnabled = false;

    // Other changes to options
});

Note

The automatic replica discovery support is available if you use version 7.1.0 or later of any of the following packages.

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

Scale and failover with replicas

Each replica you create has its dedicated endpoint. If your application resides in multiple geo-locations, 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 providers have built-in failover support through user provided replicas and/or additional automatically discovered replicas. 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 will fail over to a less preferred endpoint, but it tries to connect to the more preferred endpoints from time to time. If all user provided replicas aren't accessible, the automatically discovered replicas will be randomly selected and used. When a more preferred endpoint becomes available, the provider 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. You can either provide a list of endpoints for Microsoft Entra authentication or a list of connection strings for access key-based authentication.

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

Connect with Microsoft Entra ID

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

    // Other changes to options
});

Connect with Connection String

configurationBuilder.AddAzureAppConfiguration(options =>
{
    // Provide an ordered list of replica connection strings
    var connectionStrings = new string[] {
        Environment.GetEnvironmentVariable("FIRST_REPLICA_CONNECTION_STRING"),
        Environment.GetEnvironmentVariable("SECOND_REPLICA_CONNECTION_STRING") };
    
    // Connect to replica endpoints using connection strings
    options.Connect(connectionStrings);

    // Other changes to options
});

Note

The failover support is available if you use version 6.0.0 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.

Load balance with replicas

By default, your application always sends requests to the most preferred endpoint you provide, except in the event of a failover. However, in addition to failover, replicas can also be used to balance the load of requests. By proactively distributing requests across any available replicas over time, you can avoid exhausting the request quota of a single replica and improve the overall scalability of your application.

The App Configuration providers offer built-in support for load balancing across replicas, whether provided in code or discovered automatically. You can use the following code samples to enable this feature in your application (recommended).

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

configurationBuilder.AddAzureAppConfiguration(options =>
{
    // Enable load balancing
    options.LoadBalancingEnabled = true;

    // Other changes to options
});

Note

Load balancing support is available if you use version 8.0.0-preview.3 or later of any of the following packages.

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

Next steps

Geo-replication concept