Cost

Cap transaction billing with Standard SSD disks

Standard HDD disks bill every I/O with no ceiling, so a high-throughput workload can run up an unbounded transaction charge. Moving it to Standard SSD caps the billable transactions per hour, turning a runaway line item into a predictable one and often a smaller one.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Standard SSD billing caps: the basics

Why a cheaper-looking HDD can cost more than the SSD next to it

An Azure managed disk bill has two parts: a fixed monthly charge for the provisioned capacity, and a variable charge for the transactions the disk actually serves. On a Standard HDD, every billable transaction is charged with no upper limit, so a disk that takes a lot of small reads and writes keeps accruing transaction cost hour after hour. On a Standard SSD, the same variable charge exists, but Microsoft caps the number of billable transactions per hour by disk size. Once an hour's transactions reach that cap, the rest of that hour's I/O is free. Same workload, two very different bills.

A transaction here is an I/O operation of up to 256 KiB. An operation larger than 256 KiB is counted as multiple transactions, one per 256 KiB block. A chatty workload, an OS disk under load, a transactional database, a log volume, generates a high transaction count, and that is exactly the shape where the HDD's uncapped billing hurts and the SSD's cap helps. The capacity rate on a Standard HDD is lower, which is what makes it look cheaper at a glance, but for a high-IO disk the uncapped transaction charge can more than make up the difference.

Azure Advisor surfaces this as a cost recommendation: it looks at your Standard HDD disks, spots the ones whose transaction profile would bill less under a Standard SSD's capped model, and recommends the upgrade. It is one of the rare cost levers that improves the workload at the same time, because Standard SSD also delivers lower and more consistent latency than HDD. The job is to find the high-IO HDDs, confirm the SSD would bill less or about the same, and convert them.

In this lesson you will learn how Azure prices managed disk transactions, why an uncapped Standard HDD can cost more than the Standard SSD beside it, how the Azure Advisor 'Standard SSD disks billing caps' recommendation finds the disks worth converting, and how to convert them in place with the az CLI or Bicep without a migration project.

Fun fact

The cheaper disk with the bigger bill

It feels backwards, but on Azure a Standard HDD can bill more than a Standard SSD for the same workload. The HDD has a lower capacity rate and a lower per-transaction rate, yet its transactions are uncapped, while the SSD caps billable transactions per hour by disk size. For a high-IO disk the uncapped HDD charge can run past the capped SSD charge, so the 'budget' tier ends up the expensive one. Microsoft introduced these Standard SSD billing caps in March 2023, and they apply automatically to every Standard SSD disk, OS or data, with no action needed once the disk is on that tier.

Finding the high-IO HDDs worth converting

Priya runs the platform team at a SaaS company whose Azure bill has been creeping up faster than its usage. Azure Advisor has raised a cost recommendation, 'Standard SSD disks billing caps', pointing at several Standard HDD disks attached to busy VMs.

Rather than convert everything Advisor lists on faith, Priya starts by pulling out the Standard HDD disks in the subscription so the team can line each one up against its transaction profile before changing anything.

List the Standard HDD managed disks and the VM each is attached to. These are the candidates Advisor is flagging.

$ az disk list --query "[?sku.name=='Standard_LRS'].{name:name, gb:diskSizeGb, attachedTo:managedBy}" -o table

Name Gb AttachedTo

---------------- ---- --------------------------------

db01-data 256 .../virtualMachines/db01

logs01-data 128 .../virtualMachines/logs01

archive99-data 1024 None

# db01 and logs01 are busy and attached. archive99 is idle: leave it on HDD.

Standard_LRS is the Standard HDD SKU. The high-IO attached disks are the conversion candidates; an idle archive disk with low transactions stays cheaper on HDD.

How Advisor decides a disk should move to Standard SSDdeep dive

The mechanism is the difference in how the two tiers bill transactions. On a Standard SSD, the number of billable transactions per hour is capped, and the cap scales with disk size: the larger the disk, the higher the hourly ceiling before transactions stop being charged. Microsoft publishes the cap per disk size; for example, an E4 disk has an hourly billable-transaction cap of 43,400. On a Standard HDD there is no such cap, so every transaction is billed for as long as the workload generates them.

A transaction is an I/O operation of up to 256 KiB. Anything larger is split and counted as multiple 256 KiB transactions for billing. Advisor models each Standard HDD disk's recent transaction profile against the SSD cap and capacity rate, and raises the 'Standard SSD disks billing caps' recommendation, recommendation ID 201fb2fe-989f-45c1-8533-785ee8a4a08f, on the disks where the capped SSD model would bill less, while delivering lower, more consistent latency at the same time.

Two operational facts shape the conversion. First, changing a managed disk's type is an in-place operation but requires the VM to be deallocated, so it needs a short maintenance window. Second, Azure limits you to changing a disk's type twice per day, which matters if you are scripting bulk conversions and want a safe rollback path. The billing caps themselves need no configuration: they apply automatically to every Standard SSD disk the moment it is on that tier.

What is the impact of leaving high-IO disks on Standard HDD?

The direct impact is an inflated, unpredictable disk bill. A high-IO Standard HDD keeps billing transactions with no ceiling, so its cost tracks workload volume and offers no protection when I/O spikes. The same disk on Standard SSD would stop accruing transaction charges once an hour's cap is reached, so the bill is both lower for a busy disk and far more predictable, which is what makes it forecastable.

The second-order impact is performance left on the table. Standard SSD delivers lower and more consistent latency than Standard HDD, so a transaction-heavy OS disk, database volume or log disk that stays on HDD is paying more and running slower than it needs to. Leaving the Advisor recommendation unactioned forfeits both the saving and the responsiveness.

There is also a hygiene cost to letting Advisor cost recommendations pile up. Each unworked flag is a small, known saving the organisation has chosen not to take, and a backlog of them is exactly the drift that makes a cloud bill creep up while usage looks flat. The cheapest and most defensible FinOps artefact is a cleared Advisor cost backlog with each decision, converted or deliberately left, recorded.

How do you convert the right disks safely?

Work the recommendation as a quantify-then-convert loop, not a blanket upgrade. The order matters: confirm a disk is genuinely transaction-heavy before converting it, because a low-IO disk can cost slightly more on Standard SSD.

1. Inventory the Standard HDD disks Advisor flagged

List the Standard_LRS managed disks in scope and note which VM each is attached to and its size. The attached, busy disks are the candidates; idle or archive disks with few transactions are usually cheaper left on HDD and should come off the list.

2. Quantify each candidate against its real I/O

For each flagged disk, pull the transaction metric over a representative week and compare the uncapped HDD transaction charge against the SSD's per-hour cap plus its higher capacity rate. Convert the disks where the SSD bills less or where the latency gain justifies a break-even cost. Leave the genuinely low-IO disks on HDD.

3. Convert in place during a short window

A disk type change is an in-place conversion but needs the VM deallocated, so schedule a brief maintenance window. Deallocate the VM, update the disk SKU to StandardSSD_LRS, then start the VM. The conversion itself is effectively instantaneous. Remember Azure allows only two disk-type changes per day, which preserves a same-day rollback.

4. Make Standard SSD the default for new high-IO disks

Stop the problem recurring by setting StandardSSD_LRS as the default disk SKU in your Bicep or Terraform modules for OS and high-IO data disks, so new workloads start on the capped tier rather than being flagged by Advisor later.

# Convert one quantified high-IO disk from Standard HDD to Standard SSD.
# A disk type change is in-place but needs the VM deallocated first.
rgName='yourResourceGroup'
diskName='db01-data'

# Find the VM the disk is attached to (empty if unattached).
vmId=$(az disk show --name "$diskName" --resource-group "$rgName" \
  --query managedBy --output tsv)

# Deallocate the VM, switch the disk to Standard SSD, then start it again.
az vm deallocate --ids "$vmId"
az disk update --name "$diskName" --resource-group "$rgName" \
  --sku StandardSSD_LRS
az vm start --ids "$vmId"
echo "$diskName converted to StandardSSD_LRS: transactions now capped per hour"

# Make new high-IO disks start on the capped tier (Bicep):
# resource dataDisk 'Microsoft.Compute/disks@2023-04-02' = {
#   name: diskName
#   location: location
#   sku: { name: 'StandardSSD_LRS' }
#   properties: {
#     creationData: { createOption: 'Empty' }
#     diskSizeGB: 256
#   }
# }

Quick quiz

Question 1 of 5

Why can a high-IO Standard HDD disk cost more than the equivalent Standard SSD disk?

Keep learning

Go deeper on how Azure prices managed disk transactions and how to convert disk types in place.

You can now read the Azure Advisor 'Standard SSD disks billing caps' recommendation for what it is: a cost lever that turns an uncapped HDD transaction charge into a capped SSD one, usually for less money and always for better latency. Inventory the flagged Standard HDD disks, quantify each against its real I/O, convert the high-IO ones in place with a short maintenance window, leave the genuinely idle ones on HDD, and default new high-IO disks to Standard SSD so the recommendation stops recurring.

Back to the library

Standard SSD billing caps: the savings view

Turning an uncapped, unforecastable line item into a capped one, usually for less money

This is a cost recommendation that can lower the bill, which is unusual: most posture work is neutral or adds spend. A high-IO Standard HDD bills transactions with no ceiling, so its monthly cost is both higher than it needs to be and hard to forecast, because it tracks I/O volume directly. Converting the disk to Standard SSD puts an hourly cap on billable transactions, so above a certain I/O level the disk stops accruing transaction charges for the rest of the hour. The capacity rate goes up a little; the transaction charge stops running away.

The saving is real but workload-specific, so treat each Advisor flag as a candidate to quantify rather than a guaranteed win. Microsoft documents the mechanism and the cap table; the actual saving depends on how many transactions the disk serves per hour. The finance move is to pull the transaction count for each flagged disk, compare the uncapped HDD charge against the capped SSD charge, and convert the ones where the SSD bills less. For a genuinely high-IO disk the gap can be large; Microsoft's own example shows a transaction-cost reduction of around 88% for a heavily exercised disk.

The payback is immediate and the downside is bounded. There is no migration project: a disk type change is a single command and an in-place conversion. The only cost of being wrong is a slightly higher capacity rate on a disk that turned out not to be transaction-heavy, which you can revert. Set against an uncapped charge that grows with the workload, that is a trade finance should be quick to take.

This lesson is for the finance partner who sees an Azure Advisor cost recommendation about Standard SSD billing caps and wants to know whether it actually saves money, how much, and how to size the win. It covers the transaction-billing mechanism, how to quantify the saving per disk from its real I/O, and how to treat the conversion as a fast-payback, low-risk change.

Fun fact

The cheaper disk with the bigger bill

How a finance partner sizes the disk saving

Priya is the finance partner working the FinOps backlog with the platform team. The Advisor cost recommendation lists five Standard HDD disks, and the instinct is not to wave through a blanket 'convert them all', because the saving is workload-specific. The capacity rate on a Standard SSD is a little higher than on HDD, so a low-IO disk could actually cost slightly more after conversion. The win sits entirely with the high-transaction disks, where the SSD's hourly cap stops the charge that the HDD lets run uncapped.

So Priya asks the team to pull the transaction metric for each flagged disk over a representative week and compare two numbers: what the uncapped HDD transactions are billing now, and what the same I/O would bill against the SSD's per-hour cap plus its capacity rate. Two disks, a database data disk and a log volume, are clearly transaction-heavy and convert to a lower bill; Microsoft's documented example puts the transaction-cost reduction near 88% for a heavily exercised disk. Two are middling and convert for roughly break-even but gain better latency, which is fine. One is an idle archive disk whose handful of transactions never approaches any cap, so it stays cheaper on HDD and comes off the list. The finance pack reads: 'Two clear savings with immediate payback, two performance-neutral-on-cost upgrades, one correctly left alone; no project, just in-place conversions.'

Why this belongs at the top of the FinOps backlog

The cost case here is unusually clean: this is a recommendation that can reduce the bill rather than merely avoid risk, and the payback is immediate because the change is an in-place conversion with no project around it. Each high-IO disk left on Standard HDD is billing uncapped transactions that the SSD cap would stop, so the saving recurs every month the disk stays misplaced.

The saving is workload-specific, so the finance discipline is to quantify rather than assume. Pull the transaction count per flagged disk, compare the uncapped HDD charge against the capped SSD charge plus the slightly higher capacity rate, and convert where the SSD bills less. Microsoft documents a transaction-cost reduction of roughly 88% on a heavily exercised disk, which sets the ceiling on what a genuinely busy disk can save; a low-IO disk saves little and should stay on HDD. The role is to put a number on each candidate so the conversions are ordered by real saving.

What finance can do about the disk-billing gap

Finance cannot run the disk conversion, but it owns the framing that turns a list of Advisor flags into a ranked set of quantified savings with immediate payback. Three levers.

1. Insist on a per-disk saving estimate before converting

The saving is workload-specific, so require a number per flagged disk: the uncapped HDD transaction charge today versus the capped SSD charge plus its capacity rate. This separates the genuine savings from the break-even upgrades and the low-IO disks that should stay on HDD, so the work is ordered by real money rather than by Advisor's flag count.

2. Treat the conversion as zero-project, immediate-payback

Make explicit that there is no migration programme to fund here: a disk type change is a single in-place conversion behind a short maintenance window, and the saving starts the same month. That framing keeps the item where it belongs, near the top of the backlog as a fast win, rather than getting parked behind larger cost initiatives.

3. Track the Advisor cost backlog as a standing metric

Put the count and estimated value of open Azure Advisor cost recommendations on the FinOps review, with each closed item recorded as converted or deliberately left on HDD. A shrinking, documented backlog is the evidence that small recurring savings like this are being taken rather than left to inflate the bill while usage looks flat.

Quick quiz

Question 1 of 5

Azure Advisor raises the Standard SSD billing-caps recommendation. As the finance partner, what is the right first move before approving any conversions?

Keep learning

Go deeper on how Azure prices managed disk transactions and how to convert disk types in place.

You have finished the finance view of Standard SSD billing caps. You know this is the rare recommendation that lowers the bill, that the saving is workload-specific and worth quantifying per disk, and that the payback is immediate because the change is a zero-project in-place conversion. Next time this Advisor flag appears, you will ask for a per-disk saving estimate, convert the ones that win, leave the low-IO disks alone, and track the open Advisor cost backlog as a standing metric.

Back to the library

Standard SSD billing caps: the headline

A no-project cost change that also makes the workload faster

Azure Advisor has flagged disks where the cheaper-looking storage tier is actually billing more, because its transaction charge has no ceiling. Switching those disks to Standard SSD caps the billable transactions per hour, so a cost that has been quietly tracking workload growth becomes a predictable line, and on a high-IO disk usually a smaller one.

The reason this is worth a moment of attention is that it is the rare cost lever with no trade-off against performance: Standard SSD is faster and more consistent than the HDD it replaces, so the change improves the workload and the bill at the same time. There is no migration programme behind it, just an in-place disk conversion.

The leadership question is simply whether the team is acting on the Advisor cost recommendations rather than letting them sit. This is a low-effort, fast-payback example, and the way to treat it is as a standing habit: quantify the flagged disks, convert the ones that save, and move on.

A short read for the leader who wants to know why a cheaper-looking disk tier can cost more, why this particular change improves cost and performance at once, and what good looks like: a team that acts on Advisor cost recommendations as a habit rather than letting them accumulate.

Fun fact

The cheaper disk with the bigger bill

What it looks like when Advisor cost flags get worked, not stockpiled

The CFO had been asking why the cloud bill kept drifting up while the team insisted usage was flat. Part of the answer was sitting unread in Azure Advisor: a stack of cost recommendations, including several Standard HDD disks that were billing uncapped transactions and would cost less under Standard SSD's hourly cap.

The team's response was to make acting on Advisor cost flags a standing habit rather than a once-a-year clean-up. They quantified the flagged disks against their real I/O, converted the high-IO ones to Standard SSD in place, left the genuinely idle disk on HDD because it was cheaper there, and recorded the before-and-after on each. The next time the CFO asked, the answer had changed from 'usage is flat, we are not sure' to 'we are working the Advisor cost backlog continuously; here are the disks we converted, the transactions we capped, and the ones we deliberately left alone.' That shift, from letting cost recommendations accumulate to clearing them on a cadence, is the real win, and on these particular disks it improved performance as well as the bill.

Why this is the easy yes on the cost agenda

Most cost decisions are trade-offs: spend less and accept some risk or some loss of performance. This one is not. Moving a high-IO disk to Standard SSD lowers a transaction bill that the HDD lets run uncapped and improves latency at the same time, with no migration project and an immediate payback. It is the rare item where doing the cost-conscious thing also does the performance-conscious thing.

The only real cost is inaction. A backlog of unworked Advisor cost recommendations is a stack of small, known savings the organisation has declined to take, and collectively that is how a bill drifts up while usage looks flat. Treating these flags as a standing cadence, quantify, convert what saves, record what you leave, is the cheapest reliable way to keep cloud spend honest.

The leadership move on disk cost

The executive handle is not to approve each disk conversion; it is to require that Advisor cost recommendations are worked on a cadence, quantified, and the decisions recorded.

1. Make working the Advisor cost backlog a standing cadence

Ask for the open Azure Advisor cost recommendations to be reviewed on a regular rhythm rather than once a year. This particular recommendation, Standard SSD billing caps, is a fast-payback example, but the value is the habit: small known savings get taken continuously instead of accumulating into bill drift.

2. Ask for the saving and the decision, not just the action

The proof this is being done well is not 'we converted some disks.' It is a per-disk before-and-after: the transaction charge that was uncapped, the capped charge after conversion, and an explicit note for any disk deliberately left on HDD because it was cheaper there. That record is what makes the cost discipline defensible.

3. Set the default so the problem stops recurring

The durable fix is to default new high-IO and OS disks to Standard SSD in the infrastructure templates, so workloads start on the capped tier and never get flagged later. Acting on today's recommendations is good; making them stop appearing is better, and it is the difference between cleaning up and not creating the mess.

Quick quiz

Question 1 of 5

Why is moving a high-IO disk to Standard SSD described as the easy yes on the cost agenda?

Keep learning

Go deeper on how Azure prices managed disk transactions and how to convert disk types in place.

Two takeaways. This is the easy yes on the cost agenda: it lowers an uncapped transaction bill and improves performance at once, with no project and immediate payback. And the lasting value is the habit, working the Advisor cost backlog on a cadence with the saving and the decision recorded, and defaulting new high-IO disks to Standard SSD so the flag stops appearing at all.

Back to the library

Part of the learning path Cut your Azure storage bill

Cap transaction billing with Standard SSD disks

Standard SSD billing caps: the basics

The cheaper disk with the bigger bill

Finding the high-IO HDDs worth converting

How Advisor decides a disk should move to Standard SSDdeep dive

What is the impact of leaving high-IO disks on Standard HDD?

How do you convert the right disks safely?

1. Inventory the Standard HDD disks Advisor flagged

2. Quantify each candidate against its real I/O

3. Convert in place during a short window

4. Make Standard SSD the default for new high-IO disks

Quick quiz

Keep learning

Standard SSD billing caps: the savings view

The cheaper disk with the bigger bill

How a finance partner sizes the disk saving

Why this belongs at the top of the FinOps backlog

What finance can do about the disk-billing gap

1. Insist on a per-disk saving estimate before converting

2. Treat the conversion as zero-project, immediate-payback

3. Track the Advisor cost backlog as a standing metric

Quick quiz

Keep learning

Standard SSD billing caps: the headline

The cheaper disk with the bigger bill

What it looks like when Advisor cost flags get worked, not stockpiled

Why this is the easy yes on the cost agenda

The leadership move on disk cost

1. Make working the Advisor cost backlog a standing cadence

2. Ask for the saving and the decision, not just the action

3. Set the default so the problem stops recurring

Quick quiz

Keep learning

Related cost lessons