Cost

Lower or delete idle Azure Cosmos DB containers

Azure Advisor flags Cosmos DB containers with no activity for 30 days. Each one keeps billing for the throughput it reserves whether or not a single request hits it, so the fix is to lower the provisioned RU/s or delete the container outright.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Idle Cosmos DB containers: the basics

Why does an unused Cosmos DB container still cost money?

Azure Cosmos DB bills you for provisioned throughput, measured in Request Units per second (RU/s), not for the queries you actually run. When you create a container with manual throughput, you reserve a floor of RU/s, and Cosmos DB charges you for that reservation every hour the container exists. A container that nobody has read from or written to in a month is still holding its reservation, and you are still paying for it. That is the gap Azure Advisor is pointing at with its 'Consider taking action on your idle Azure Cosmos DB containers' cost recommendation.

Advisor looks for containers in the microsoft.documentdb/databaseaccounts resource type that have had no activity for 30 days and surfaces two clear options: lower the throughput on the container, or delete it if you do not plan to use it again. Both close the same waste. Lowering RU/s shrinks the reservation you keep paying for; deleting the container removes the charge entirely. The recommendation does not decide for you, because only you know whether the data behind the container still matters.

Most idle containers are leftovers, not live workloads. A proof of concept that shipped and was never cleaned up, a per-tenant container for a customer who churned, a copy made for a migration that finished months ago, a test collection that someone over-provisioned at 10,000 RU/s for a load test and never wound back down. None of them serve traffic, all of them bill. The work is to find every container Advisor flags, decide which still need to exist, right-size the keepers down to a sensible floor, and delete the rest.

In this lesson you will learn how Azure Cosmos DB turns provisioned throughput into a bill, why an idle container keeps charging, and how to act on Azure Advisor's idle-container recommendation safely: inventory what Advisor flags, separate keepers from leftovers, right-size the RU/s on the keepers down to the documented floor, and delete the rest. The keep-learning section links the Microsoft references for every command used here.

Fun fact

The load test that never went home

A surprising share of idle Cosmos DB spend traces back to a single pattern: a container provisioned high for a one-off load test or migration and never wound back down. Someone needs 50,000 RU/s for an afternoon, sets it, ships the test, and moves on. Cosmos DB keeps charging for that reservation every hour for months, because provisioned throughput is billed for what you reserve, not what you use. The container looks busy in the portal because it has a big number next to it, but Advisor sees the truth: thirty days with no activity, and the hourly charge still running.

Finding idle Cosmos DB throughput across an account

Priya runs the platform team at a SaaS company and gets the monthly Azure Advisor cost digest. This month it flags several idle Cosmos DB containers across two database accounts, recommending she lower their throughput or delete them.

Rather than open each container in the portal, Priya starts from the CLI, listing every container and the throughput it is provisioned at, so she can see at a glance which reservations are large and which are already at the floor before she decides what to keep.

List the containers in a database and show the throughput each one reserves. The big reservations on idle containers are the biggest savings.

$ for c in $(az cosmosdb sql container list -g rg-data --account-name cosmos-prod --database-name appdb --query "[].name" -o tsv); do echo -n "$c: "; az cosmosdb sql container throughput show -g rg-data --account-name cosmos-prod --database-name appdb --name "$c" --query "resource.throughput" -o tsv; done

loadtest-archive: 50000

tenant-acme-churned: 4000

orders: 4000

# loadtest-archive reserves 50,000 RU/s and Advisor says it is idle. That is the line to cut first.

An idle container reserving 50,000 RU/s costs many times what a 400 RU/s floor does. Right-size or delete the large idle reservations first.

How Advisor decides a Cosmos DB container is idle, and what it costsdeep dive

Azure Advisor watches the activity on each container in a Cosmos DB account and raises the idle-container cost recommendation when a container has had no activity over the trailing 30 days. The recommendation targets the microsoft.documentdb/databaseaccounts resource type and offers two remedies in its own text: lower the throughput, or delete the container if you do not plan to use it. Advisor is reading usage signals it already collects, so the finding costs you nothing to obtain; it is the action that captures the saving.

The cost itself comes from how Cosmos DB provisions throughput. With manual (standard) throughput, a container must reserve a minimum of 400 RU/s, and you are billed for the throughput you provision, by the hour, regardless of how many requests you send. With autoscale, the container scales between 10 percent and 100 percent of a maximum you set, with a documented minimum maximum of 1,000 RU/s, and Microsoft documents that you are billed each hour for the highest RU/s the system scales to during that hour. Either way, an idle container that reserves more than it needs is paying for headroom it never uses.

Two facts shape the right-sizing decision. First, the floor matters: a manual container cannot go below 400 RU/s, so lowering an over-provisioned container down to that floor captures most of the saving without deleting anything. Second, Microsoft documents that in single-write-region accounts the autoscale rate per 100 RU/s is 1.5 times the standard manual rate, so for a container that is genuinely idle and stays idle, manual at the 400 RU/s floor is cheaper than autoscale at its 1,000 RU/s minimum. The strongest saving, of course, is deletion: a container that no longer exists reserves nothing and bills nothing.

What is the impact of leaving idle containers running?

The direct impact is recurring waste. Every idle container reserves throughput and bills for it every hour, so the cost is not a one-off; it is an annuity paid out of the operating budget for capacity that serves no requests. A single over-provisioned load-test container left at tens of thousands of RU/s can cost more on its own than a handful of busy production containers running at the floor.

The second-order impact is drift. Idle containers accumulate because nobody owns removing them: each finished proof of concept, completed migration and churned tenant can leave one behind, and without a review they compound. The Cosmos DB line on the bill creeps up while usage stays flat, which is exactly the pattern that triggers an awkward question at the next cost review and is hard to explain after the fact.

The good news is that the trade-off is almost entirely one-directional. Lowering or deleting throughput on a container that has had no activity for 30 days cannot degrade a live workload, because no live workload is using it. The only thing you can get wrong is deleting data you later need, which is why the discipline is to confirm retention before deletion and to prefer lowering RU/s where there is any doubt, since a lowered container can always be raised again.

How do you act on the idle-container recommendation safely?

Work the recommendation as a short loop. The order matters: confirm which containers still need their data before you delete anything, so the only irreversible action is taken on purpose.

1. Inventory every flagged container by its reservation

List the containers Advisor flags and the throughput each one reserves. Sort by reserved RU/s, because the saving is proportional to the reservation: a single idle container at 50,000 RU/s is worth far more than ten at the 400 RU/s floor. Treat the reserved throughput, not the finding count, as the measure of what is recoverable.

2. Separate leftovers from keepers

For each container, decide whether the data still needs to exist. Abandoned proofs of concept, finished migrations and churned-tenant containers are leftovers and can be deleted. Containers whose data still matters but whose throughput is over-provisioned are keepers to right-size. When in doubt, treat it as a keeper and lower the RU/s rather than delete: lowering is reversible, deletion is not.

3. Right-size the keepers to the floor

For a keeper, query the minimum allowed throughput and lower the container to it. A manual container floors at 400 RU/s; an autoscale container floors at a 1,000 RU/s maximum. For a container that is genuinely idle and expected to stay idle, manual at 400 RU/s is the cheaper resting state. The change takes effect immediately and is fully reversible if the workload returns.

4. Delete the confirmed leftovers

Once retention is confirmed, delete the leftover containers. Deletion removes the throughput charge entirely, the largest possible saving for that container. Take a backup or export first if there is any chance the data is needed, then make a clean review part of the monthly Advisor cadence so idle capacity stops accumulating.

# 1. Right-size a keeper down to its documented minimum (manual throughput).
# Query the floor, then lower the container to it. Both take effect immediately.
min=$(az cosmosdb sql container throughput show \
  --resource-group rg-data \
  --account-name cosmos-prod \
  --database-name appdb \
  --name tenant-acme-churned \
  --query "resource.minimumThroughput" -o tsv)

az cosmosdb sql container throughput update \
  --resource-group rg-data \
  --account-name cosmos-prod \
  --database-name appdb \
  --name tenant-acme-churned \
  --throughput "$min"

# 2. Delete a confirmed leftover after checking the data is no longer needed.
az cosmosdb sql container delete \
  --resource-group rg-data \
  --account-name cosmos-prod \
  --database-name appdb \
  --name loadtest-archive \
  --yes

Quick quiz

Question 1 of 5

Why does an idle Azure Cosmos DB container still appear on the bill when no requests are hitting it?

Keep learning

Go deeper on how Azure Cosmos DB provisions and bills throughput, and on the commands used in this lesson.

You can now act on Azure Advisor's idle Cosmos DB container recommendation with confidence: inventory every flagged container by the throughput it reserves, separate the leftovers from the keepers, right-size the keepers down to the documented floor, and delete the confirmed leftovers once retention is checked. Make that review a monthly cadence and idle capacity stops quietly accumulating on the bill.

Back to the library

Idle Cosmos DB containers: the savings view

A recurring line on the Azure bill that disappears the moment you act, at no engineering cost

This is one of the cleanest savings on an Azure bill. A provisioned Cosmos DB container charges for its reserved RU/s every hour, so an idle container is pure recurring waste with nothing on the other side of the ledger. Unlike most cost work, there is no capacity to re-architect and no commitment to negotiate: you either lower the floor or remove it, and the saving lands on the very next bill.

The decision splits cleanly into two cost outcomes. Deleting a container that nobody needs removes its full throughput charge, the highest-value action. Lowering RU/s on a container you must keep cuts the charge down to the documented minimum floor, typically a fraction of an over-provisioned reservation. Both are reversible in spirit: you can always raise RU/s again if a workload comes back, so the only genuinely irreversible call, deletion, is the one to gate behind a check that the data is no longer needed.

Frame the payback as immediate. There is no migration cost to amortise and no break-even period to model. The saving is the reserved RU/s you stop paying for, the cost of acting is a few minutes of an engineer's time per container, and the payback is effectively the first hour after the change. The only judgement call is data retention, not money.

This lesson is for the finance partner who sees Cosmos DB on the Advisor cost recommendations and wants to know how much is recoverable, how fast, and what the trade-offs are. It covers why the saving is immediate, how deleting versus lowering RU/s differ in payback, and how to turn a list of idle containers into a savings number with the data-retention question called out separately.

Fun fact

The load test that never went home

How a finance partner sizes the Cosmos DB saving

Priya is the finance partner working with the platform team on the quarterly Azure cost review. Advisor's cost digest flags several idle Cosmos DB containers, and the instinct is not to celebrate a vague saving; it is to put a number on it. Because Cosmos DB bills for reserved RU/s by the hour, each idle container's monthly cost is its reserved throughput multiplied by the published RU/s rate, so the inventory above translates straight into pounds: the 50,000 RU/s load-test archive dwarfs the rest, and a single 400 RU/s floor is close to noise.

Priya asks the team to tag each flagged container with one of two outcomes. The load-test archive and the churned-tenant container are leftovers nobody owns, so deleting them removes their full charge, the headline saving. The few keepers that are merely over-provisioned get lowered to the documented floor, recovering most of their cost without losing the data. The finance pack reads: 'The bulk of the recoverable spend is in two abandoned containers we can delete outright; the rest is right-sizing to the minimum floor. Payback is immediate, there is no migration cost, and the only open question is data retention on the deletions, not budget.'

Why idle containers are the easiest saving to bank

The cost model here is unusually friendly. Most cloud savings involve a trade: reserve capacity for a discount, re-architect for efficiency, accept some performance risk. Idle Cosmos DB containers involve none of that. The container reserves RU/s, bills for them hourly, and serves nothing, so removing or lowering the reservation is pure saving with no offsetting cost beyond the few minutes it takes to act.

Quantifying it is straightforward because the bill is mechanical: reserved RU/s times the published rate times the hours in the month. That makes the recoverable amount easy to forecast and easy to verify on the next invoice, which is exactly the kind of saving finance can commit to and check. The role of finance is to turn Advisor's list into that number, separate the delete-now leftovers from the right-size keepers, and flag the one genuine dependency, data retention, so the engineering team confirms it before any deletion.

What finance can do about idle Cosmos DB spend

Finance cannot lower a container's throughput, but it owns the framing that turns Advisor's list into a banked, verifiable saving with the one real dependency called out. Three levers.

1. Convert the inventory into a forecast saving

Because Cosmos DB bills reserved RU/s by the hour, each flagged container's monthly cost is its reserved throughput times the published rate. Sum the reservations Advisor flags and you have a defensible, recoverable number to commit to, and one you can verify on the very next invoice. Insist the saving be tracked per container so the delete-now items and the right-size items show their payback separately.

2. Prioritise by reserved RU/s, not by finding count

An idle container reserving 50,000 RU/s and one at the 400 RU/s floor both appear as a single Advisor finding, but their recoverable spend differs by two orders of magnitude. Ask the team to order the work by reserved throughput so the largest reservations are trimmed first. The metric for the cost review is recoverable RU/s, not the raw count of idle containers.

3. Gate deletions on confirmed retention, not on cost

The only irreversible action here is deletion, and its single dependency is whether the data is still needed, not money. Require that each deletion carries a recorded confirmation that retention has been checked and, where sensible, a backup taken. Lowering RU/s needs no such gate because it is reversible, so encourage right-sizing as the default and reserve deletion for confirmed leftovers.

Quick quiz

Question 1 of 5

Advisor flags six idle Cosmos DB containers. As the finance partner, how do you turn that into a forecast saving?

Keep learning

Go deeper on how Azure Cosmos DB provisions and bills throughput, and on the commands used in this lesson.

You have finished the finance view of idle Cosmos DB containers. You know the saving is mechanical and immediate: reserved RU/s times the rate, recoverable on the next invoice, with no migration cost and no break-even to model. Next time Advisor flags idle containers, you will price the inventory by reserved throughput, separate the delete-now leftovers from the right-size keepers, and gate only the deletions on confirmed data retention rather than asking how long the saving takes to pay back.

Back to the library

Idle Cosmos DB containers: the headline

Money leaving the business every hour for database capacity nobody is using

Azure Cosmos DB charges for capacity you reserve, not capacity you use, so a container that has gone idle is a standing order paying for an empty seat. Azure Advisor has already found these for you and labelled them a cost recommendation. The only thing between the finding and the saving is a decision about whether the data still matters.

The leadership question is not whether to cut Cosmos DB spend in general; it is whether anyone owns the housekeeping that stops idle capacity accumulating. Each idle container is small, but they breed: every finished project and churned customer can leave one behind, and the bill quietly compounds. The defensible end state is that Advisor's idle-container finding is reviewed on a cadence, keepers are right-sized, and the rest are deleted.

This is a risk-free saving in the cost sense: lowering or removing throughput on a container nobody is using cannot degrade a live service, because by definition no live service is using it. The only care needed is around data retention, which is a governance question, not a budget one.

A short read for the leader who needs to know what an idle Cosmos DB container is costing, why acting on it is essentially risk-free in cost terms, and what an end state looks like where idle capacity is reviewed on a cadence rather than left to accumulate.

Fun fact

The load test that never went home

What it looks like when idle capacity stops accumulating

At a cost review the CFO noticed Cosmos DB spend had drifted up over three quarters without a matching rise in customers or traffic. The honest explanation was that nobody owned the housekeeping: every finished project, migration and churned customer could leave a provisioned container behind, and each one kept billing quietly because Cosmos DB charges for reserved capacity whether or not it is used.

The team's response was to make Advisor's idle-container recommendation a standing item rather than a one-off cleanup. They inventoried every flagged container, deleted the abandoned ones after confirming the data was no longer needed, lowered the over-provisioned keepers to the minimum floor, and put a monthly review of the recommendation on the platform team's calendar. The next quarter, Cosmos DB spend tracked usage again, and the answer to 'why is this line growing?' changed from 'we are not sure' to 'it is not, because idle capacity is now reviewed and removed every month.' That shift, from spend that drifts up unwatched to spend that tracks what the business actually uses, is the durable result, and it costs only the discipline of looking.

Why this belongs on the cost review, not the risk register

Idle capacity is the cloud equivalent of paying rent on an empty office. It does not threaten a service or expose data; it simply leaks money every hour for nothing in return. That makes it a pure efficiency item: the cost of acting is trivial, the saving is immediate and recurring, and there is no performance downside because nothing is using the capacity being trimmed.

The reason it is worth leadership attention is that it does not fix itself. Without an owner and a cadence, idle containers accumulate as projects finish and customers churn, and the bill drifts up out of step with the business. Making Advisor's idle-container finding a reviewed, owned item is the cheap governance move that keeps Cosmos DB spend honestly tracking usage.

The leadership move on idle Cosmos DB capacity

The executive handle is not to approve each deletion; it is to make Advisor's idle-container finding a reviewed, owned, recurring item so idle capacity stops accumulating in the first place.

1. Put the recommendation on a cadence

Ask for a monthly review of Advisor's idle Cosmos DB container recommendation with a named owner. The saving from a one-off cleanup is real but temporary; the durable result is a process that catches new idle containers as projects finish and customers churn, so the Cosmos DB line keeps tracking actual usage rather than drifting up.

2. Treat it as a saving, not a risk

Make clear that acting on idle containers cannot degrade a live service, because nothing live is using the capacity. This is a pure efficiency item with immediate, recurring payback and no performance trade-off, which makes it among the easiest cost decisions to approve. The only care needed is on data retention before deletion, which is a governance check, not a budget one.

3. Ask for the saving on the invoice, not in a slide

The proof that this is done is the next Cosmos DB bill, not a status update. Ask for the recovered spend to be reported against the actual invoice line, and for the Advisor recommendation to read clear or down to documented exceptions. That closes the loop between the finding and the money, and keeps the housekeeping honest.

Quick quiz

Question 1 of 5

Cosmos DB spend has drifted up over three quarters without more customers or traffic. What is the likely cause and the durable fix?

Keep learning

Go deeper on how Azure Cosmos DB provisions and bills throughput, and on the commands used in this lesson.

Two takeaways. Acting on idle Cosmos DB capacity is a pure efficiency saving with immediate, recurring payback and no performance downside, so it is among the easiest cost decisions to approve. And the durable result is not a one-off cleanup; it is making Advisor's idle-container finding a reviewed, owned, monthly item so Cosmos DB spend keeps tracking what the business actually uses, with the only care being data retention before any deletion.

Back to the library

Part of the learning path Kill idle Azure waste

Lower or delete idle Azure Cosmos DB containers

Idle Cosmos DB containers: the basics

The load test that never went home

Finding idle Cosmos DB throughput across an account

How Advisor decides a Cosmos DB container is idle, and what it costsdeep dive

What is the impact of leaving idle containers running?

How do you act on the idle-container recommendation safely?

1. Inventory every flagged container by its reservation

2. Separate leftovers from keepers

3. Right-size the keepers to the floor

4. Delete the confirmed leftovers

Quick quiz

Keep learning

Idle Cosmos DB containers: the savings view

The load test that never went home

How a finance partner sizes the Cosmos DB saving

Why idle containers are the easiest saving to bank

What finance can do about idle Cosmos DB spend

1. Convert the inventory into a forecast saving

2. Prioritise by reserved RU/s, not by finding count

3. Gate deletions on confirmed retention, not on cost

Quick quiz

Keep learning

Idle Cosmos DB containers: the headline

The load test that never went home

What it looks like when idle capacity stops accumulating

Why this belongs on the cost review, not the risk register

The leadership move on idle Cosmos DB capacity

1. Put the recommendation on a cadence

2. Treat it as a saving, not a risk

3. Ask for the saving on the invoice, not in a slide

Quick quiz

Keep learning

Related cost lessons