Enable geo-replication

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

• An Azure subscription - Create a trial subscription
• We assume you already have an App Configuration store. If you want to create one, create an App Configuration store.

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.

   

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.

   

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.

   

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).

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

    // Other changes to options
});

spring.cloud.azure.appconfiguration.stores[0].replica-discovery-enabled=false

apiVersion: azconfig.io/v1
kind: AzureAppConfigurationProvider
metadata:
  name: appconfigurationprovider-sample
spec:
  endpoint: <your-app-configuration-store-endpoint>
  replicaDiscoveryEnabled: false
  target:
    configMapName: configmap-created-by-appconfig-provider

config = load(endpoint=endpoint, credential=credential, replica_discovery_enabled=False)

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.

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
});

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
});

spring.cloud.azure.appconfiguration.stores[0].endpoints[0]="<first-replica-endpoint>"
spring.cloud.azure.appconfiguration.stores[0].endpoints[1]="<second-replica-endpoint>"

spring.cloud.azure.appconfiguration.stores[0].connection-strings[0]="${FIRST_REPLICA_CONNECTION_STRING}"
spring.cloud.azure.appconfiguration.stores[0].connection-strings[1]="${SECOND_REPLICA_CONNECTION_STRING}"

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).

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

    // Other changes to options
});

Next steps