Unnecessary Additional Regions on Cosmos DB Accounts

An account with two extra read regions pays three times the throughput and three times the storage of a single-region account, whether or not any client ever reads from those regions.

Extra regions accumulate when production templates with geo-redundancy or multi-region writes are reused for development, test and staging accounts, when a region added for a past latency goal or a migration is never removed, or when a disaster recovery design is set once and not revisited. Microsoft's multi-region cost guidance tells teams to monitor consumed throughput per region and add or remove regions on demand, and calls under-utilized read regions inefficient.

Regional throughput

RU/s configured on databases and containers is reserved in every region of the account, so the hourly total is RU/s times the number of regions

Regional storage

Data and index storage is billed in each region that holds a replica

Multi-region writes

Every region becomes writable and throughput is billed at the multi-region write rate

Region removal

Regions can be removed at any time; in single-region write mode the write region must be failed over first

• List Cosmos DB accounts with more than one entry in properties.locations (Azure Resource Graph type microsoft.documentdb/databaseaccounts), and flag non-production accounts and accounts with enableMultipleWriteLocations set to true
• For each secondary region, chart Total Requests and Total Request Units split by Region over 30 days; read regions that serve almost no client traffic beyond replication are candidates
• Review application connection settings for the Cosmos DB SDK preferred regions list; regions that no client lists are serving only as replication or failover targets
• Confirm with owners whether each extra region is required by a documented recovery or latency objective
• Estimate the saving as the account's provisioned RU/s and stored GB multiplied by the number of regions that could be removed

• Remove read regions with no traffic and no recovery requirement from Replicate data globally in the portal, or by updating the account's locations with the CLI, PowerShell or templates
• Keep development, test and staging accounts single-region and without multi-region writes unless a test specifically needs them
• Disable multi-region writes where single-region writes plus a read region meet availability needs, and review client consistency and failover settings first
• Where a secondary region must remain only for disaster recovery, use autoscale with dynamic scaling so an idle secondary region scales down independently instead of matching the primary
• Document the reason for each region in account tags so replication settings are reviewed when requirements change

• Optimize Cost for Multi-Region Deployments - Azure Cosmos DBlearn.microsoft.com
• Manage by Using the Azure Portal - Azure Cosmos DBlearn.microsoft.com
• Create Containers and Databases with Autoscale Throughput - Azure Cosmos DBlearn.microsoft.com
• Monitoring Data Reference - Azure Cosmos DBlearn.microsoft.com
• Azure Cosmos DB pricingazure.microsoft.com