Azure Cosmos DB multi-region cost: what each replica region adds

Quick answer

Cosmos DB bills provisioned throughput (RU/s) per region, so each additional read region adds roughly the same RU/s cost as your primary, and enabling multi-region writes raises the per-region rate further because every region can accept writes. A container provisioned at 1000 RU/s costing about $58 per month in one region costs about $116 across two regions, and more with multi-region writes enabled. Storage is also replicated per region at about $0.25 per GB. The rule: add regions only where you need the latency or availability, and prefer single-region writes with multiple read regions unless you truly need global write.

One of Cosmos DB's headline features is turnkey global distribution: add a region with a click and your data replicates there. The convenience hides a linear cost consequence, because Cosmos bills throughput per region. Every region you add multiplies the throughput bill, and enabling writes in multiple regions multiplies it again. Understanding this is essential before spreading a container across the globe.

How regions multiply cost

Configuration	Throughput cost
Single region	Base RU/s cost (1x)
Primary + 1 read region	Roughly 2x
Primary + 2 read regions	Roughly 3x
Multi-region writes	Higher per-region rate on top

Provisioned throughput is charged in every region the container spans. A container at 1000 RU/s costs about $58 per month in one region, about $116 across two, and about $174 across three, before multi-region writes. Storage replicates per region too, at about $0.25 per GB per month each. So global distribution's cost scales directly with the number of regions.

The multi-region write premium

By default, Cosmos uses single-region writes: one region accepts writes and the others are read replicas. Enabling multi-region writes, so every region can accept writes with conflict resolution, raises the RU/s rate charged in each region beyond the single-write rate. This is a meaningful premium, justified only when you genuinely need low-latency writes from multiple geographies or write availability during a regional outage. Many applications need global reads but write from one place, and for them single-region writes with multiple read regions is the cheaper, sufficient configuration.

When extra regions are worth it

Additional regions buy two things: lower read latency for users near each region, and higher availability if a region fails. Add a region when you have users in that geography who benefit from local read latency, or when your availability requirements demand surviving a regional outage. Adding regions speculatively, without users or an availability requirement that needs them, simply multiplies cost. Tie each region to a concrete latency or resilience need, the same discipline as the broader multi-region cost versus latency tradeoff.

Keep throughput efficient before scaling out

Because the per-region cost is the RU/s cost multiplied, reducing RU/s first makes every region cheaper. Efficient partitioning, indexing only what you query, and using autoscale for variable traffic all lower the base RU/s, as the RU optimization guide and the autoscale cost guide cover. Optimizing the base throughput before multiplying it across regions compounds the savings.

Choosing a topology on cost

Decide how many regions you truly need for latency and availability, prefer single-region writes with read replicas unless global write is essential, and minimize the base RU/s before multiplying it out. Price the multi-region configuration against the resource catalog before you deploy so the per-region multiplication, and the multi-region write premium, are known numbers rather than a surprising multiple on the first global bill.

FAQ

How does Cosmos DB charge for multiple regions?

It bills provisioned throughput (RU/s) in every region the container spans, so each additional read region adds roughly the same RU/s cost as the primary. A container at 1000 RU/s costs about $58 per month in one region, about $116 across two, and about $174 across three. Storage replicates per region too at about $0.25 per GB, so cost scales linearly with region count.

What does enabling multi-region writes cost?

Enabling multi-region writes raises the RU/s rate charged in each region beyond the single-region-write rate, because every region can accept writes with conflict resolution. This premium applies on top of the per-region multiplication, so it is only justified when you genuinely need low-latency writes from multiple geographies or write availability during a regional outage. Many apps need only global reads and single-region writes.

Should I use single-region or multi-region writes?

Prefer single-region writes with multiple read regions unless you truly need global writes. Single-region writes let one region accept writes while others serve reads at a lower rate, which is cheaper and sufficient for applications that write from one place but read globally. Reserve multi-region writes for cases needing low-latency writes from several geographies or write availability through a regional failure.

When is adding a Cosmos DB region worth the cost?

When you have users in that geography who benefit from local read latency, or when availability requirements demand surviving a regional outage. Each region multiplies the throughput bill, so add one only for a concrete latency or resilience need. Adding regions speculatively without users or an availability requirement simply multiplies cost without delivering value.

How does C3X help with Cosmos DB multi-region cost?

C3X prices Cosmos DB configurations from Terraform before you deploy, including the number of regions and whether multi-region writes are enabled, so the per-region multiplication and the write premium are visible in the pull request. That lets you tie each region to a real need and choose the write topology deliberately before the global configuration lands on the bill.

What to do next

Price Cosmos DB global topology before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.