Azure Cosmos DB - Part Two - Enable Geo Replication Of Data

In this article, we will learn how to replicate data to any Azure region globally.

Azure Cosmos DB allows distributing the data globally to any available Azure region with a click. With it, Azure Cosmos DB data is replicated in a transparent manner. Azure Cosmos DB also provides configurable options to replicate your data across multiple datacenters.

There are two ways to replicate the data,

  • Manual Replication
  • Automatic Replication

Each selected region is billed based on throughput (RUs) and data stored on SSDs for the cosmos db account. Throughput is billed as Request Units (RU) per second which is a currency for charging throughput for read, write, and query operations on an Azure Cosmos DB container.

Consistency Levels

Cosmos DB has different consistency level per account which applies automatically to all the databases and collections within the cosmos account.


These consistency levels are,

  1. Strong 
    Strong consistency provides the most predictable and intuitive programming model and ensures that your versions of documents in your replica do not lag behind the primary. When you configure your account with a strong consistency level, Cosmos DB provides a linearizability guarantee which means that reads are guaranteed to see the most recent write. If your application requires all replica documents to exactly match the primary at any point in time, this strategy makes a lot of sense. The downside is that the primary write operation will be a lot slower than usual because that operation has to wait for every replica to confirm that the operation has been committed.

  2. Bounded Stateless
    Bounded staleness consistency is most frequently chosen by globally distributed applications expecting low write latencies but total global order guarantees. Unlike strong consistency which is scoped to a single region, you can choose bound stateless consistency with any number of read regions (along with a write region). Bounded stateless is great for applications featuring group collaboration and sharing, stock ticker, publish-subscribe/queueing etc.

  3. Session
    Session consistency is the most widely used consistency level both for single region as well as, globally distributed applications. It provides write latencies, availability and read throughput comparable to that of eventual consistency but also provides the consistency guarantees that suit the needs of applications written to operate in the context of a user.

  4. Consistent Prefix
    Consistent prefix level guarantees that reads never see out of order writes. If writes were performed in the order `A, B, C`, then a client sees either `A`, `A,B`, or `A,B,C`, but never out of order like `A,C` or `B,A,C`. Consistent Prefix provides write latencies, availability and read throughput comparable to that of eventual consistency, but also provides the order guarantees that suit the needs of scenarios where the order is important.

  5. Eventual
    Eventual consistency is the weakest form of consistency which occurs because operations against the primary database commit immediately and do not wait for the replicas to confirm that they are committed. This is useful for scenarios where you need the highest tier of performance and the application does not require any ordering guarantees. Examples include the count of Retweets, Likes or non-threaded comments.

Provision the replication of data globally

  1. Sign in to the Azure Portal.

  2. Create the Azure cosmos account as discussed in the next steps.

    Let’s create an Azure Cosmos DB account using following steps,
  1. Sign in to the Azure Portal.

  2. In the search option, type cosmos DB and select Azure Cosmos DB option as shown in below image,

  3. In the Azure Cosmos DBwindow, specify the desired configuration using the following steps,

    First, enter a name in the ID option to uniquely identify the account. It will become the host name within URI and a green check appear if validation is successful.
  1. In the APIsection, select SQL API.

  2. In the Subscription section, select the Azure subscription that you want to use for the account.

  3. In the Resource Group section, create a new resource group for your account of your choice. For the demo, I created a resource group with the name cosmos db.

  4. Select Location to specify the geographic location which is closest to your current location to host your cosmos db account.

  5. After providing all the details, click the Create button to begin the deployment.

  6. After the cosmos account is created, open the Azure cosmos DB account.

  7. Click the Replicate data globally option on the left-hand side of the blade.

  8. In the Replicate data globally section, you need to select at least one region as read region to enable the manual failover and automatic failover for data replication.

  9. Here, I have added North Europe as the read region. We can associate multiple read regions with cosmos db account as per the need.
  10. Click the Save button to continue the locations as Read regions for your account. This will enable the option of Manual and Automatic replication.

Let’s go through these options one by one.

Manual Failover

  1. In the case of Manual failover, if any failure happens then the selected Read region will become the new Write region.

  2. In the below screenshot, West Europe has been selected as Read Region and it will become the Write Region if any failure happens.

  1. Click OK button to save this setting for Manual Failover.

Automatic Failover

  1. To enable the Automatic Failover, you need to click the ON option.

  2. Now you need to select the read region which will be the Write region in case of failover.

  3. You can also select multiple the Read regions and set the priorities. If you have selected multiple Read Regions, then you can drag and drop the read region items to reorder the failover priorities.

  4. In the below screenshot, two read regions, West Europe and East Asia, are selected. If any failover happens then Read region with high priority (West Europe has priority 1) will be Write Region. After this, if another failover happens then Read Region (East Asia) will automatically be Write Region.


So, this is how you can replicate the data globally to multiple Azure data regions.