Skip to main content
emnode
Cost

Buy reserved capacity for blob storage

Steady block blob and Data Lake Gen2 capacity is paying full pay-as-you-go rates by default. A one or three year reserved-capacity commitment discounts that same storage automatically, with no change to how the data is stored or served.

14 min·10 sections·AZURE

Last reviewed

Blob storage reserved capacity: the basics

What is Azure Advisor actually flagging when it recommends a blob reservation?

Block blob and Azure Data Lake Storage Gen2 capacity is billed by the gigabyte at pay-as-you-go rates by default. If a subscription holds a large, steady volume of blob data month after month, every one of those gigabytes is being charged at the full on-demand price even though the baseline never goes away. Azure Storage reserved capacity is the lever for that baseline: you commit to a fixed amount of capacity, 100 TiB or 1 PiB blocks, for a one or three year term, and the matching usage is billed at a discounted rate instead. The data does not move, the account does not change, only the price of the committed slice does.

Azure Advisor turns this into a specific cost recommendation: 'Consider Blob storage reserved instance to save on Blob v2 and Datalake storage Gen2 costs' (Recommendation ID 0169a2e1-c7bf-4c37-90b8-0714811c82d3). Advisor watches your recent capacity usage, spots the stable baseline that is always present, and works out the reservation size and term that would have covered it. It is the same engine that recommends VM and SQL reservations, pointed at storage. The recommendation is a savings opportunity, not a problem to fix: nothing is broken, you are simply paying retail for capacity you could pre-commit.

A reservation is a billing construct, not a resource. It applies automatically to any block blob or Data Lake Gen2 data in scope that matches its region, access tier and redundancy, and it covers only stored capacity. Operations, bandwidth, data transfer and early-deletion charges stay at pay-as-you-go rates. The job is to confirm the baseline is real and durable, choose the size and term that fit it, and let the discount land on storage you were going to keep anyway.

In this lesson you will learn what Azure Storage reserved capacity discounts, how Azure Advisor identifies a blob reservation opportunity, how to size and scope a reservation against your real baseline, and how to purchase one safely so the discount lands on the storage you keep without over-committing capacity you might shed.

Fun fact

The reservation that is not a resource

A blob storage reservation never appears in your resource group. It is purely a billing object: you commit to a fixed amount of capacity, and Azure quietly re-prices the matching block blob and Data Lake Gen2 usage at the discounted rate. The reservation cannot be pinned to a single storage account or container, it floats across all matching usage in its scope. That is why a reservation purchased for one project can keep delivering savings even after that project's data is deleted, as long as other accounts in scope are storing data with the same region, tier and redundancy to absorb it.

Finding and sizing a blob reservation opportunity

Priya runs the platform team at a data-heavy SaaS company. Azure Advisor has surfaced the blob reserved-capacity recommendation, estimating a meaningful annual saving on a data lake that has held a steady multi-hundred-terabyte baseline for over a year.

Before committing, Priya pulls the cost recommendations from the CLI to read the exact estimate and the attributes Advisor is suggesting, so the reservation can be sized against the real, durable baseline rather than a recent spike.

List the cost recommendations and pick out the blob reserved-capacity one. The --refresh flag asks Advisor to recompute against current usage first.

$ az advisor recommendation list --category Cost --refresh \ --query "[?contains(shortDescription.problem, 'Blob storage reserved')]" -o table
Category Impact Problem
---------- -------- -------------------------------------------------------
Cost Medium Consider Blob storage reserved instance to save on Blob
v2 and Datalake storage Gen2 costs
# Read the full recommendation for the suggested region, tier, redundancy and term.

Advisor recommends the reservation attributes from your usage. Confirm the baseline is durable before committing: a reservation discounts steady capacity, not a recent spike.

How a blob reservation discount actually appliesdeep dive

A reservation is matched against usage by four attributes: region, access tier (Hot, Cool or Archive), redundancy (LRS, ZRS, GRS, GZRS, RA-GRS or RA-GZRS), and scope. The discount only lands on block blob and Data Lake Gen2 capacity that matches all of them. A reservation bought for Hot ZRS in UK South does nothing for Cool LRS data in West Europe. This is why sizing is per attribute combination: if your footprint spans tiers or regions, you may need more than one reservation, each covering its own slice.

Reserved capacity covers stored bytes only. Operations (reads, writes, list calls), bandwidth, data transfer and early-deletion charges continue at pay-as-you-go rates regardless of any reservation. So the saving is on the capacity component of the bill, not the whole storage line, and a transaction-heavy account with little stored data is a poor reservation candidate while a large, quiet archive is an excellent one.

Scope decides which subscriptions the discount can float across. Single-subscription scope keeps it to one subscription; shared scope spreads it across all subscriptions in the billing context; management-group scope spreads it across the subscriptions under a given management group. Reserved capacity also only applies to standard general-purpose v2 and Blob storage accounts: premium accounts, general-purpose v1, page blobs, Azure Queue and Azure Table storage are all excluded. The discount is applied automatically to matching usage from the moment of purchase, with no change to the accounts themselves.

What is the impact of not reserving steady blob capacity?

The direct impact is recurring overspend. Every gigabyte of durable baseline left on pay-as-you-go is billed at the full on-demand rate, month after month, when a reservation would discount that exact same storage automatically. For a large data lake or a long-lived archive this is one of the most predictable line items on the bill, which makes it one of the easiest to discount: the capacity is steady, present and certain to remain.

The second-order impact is that the saving compounds with the term. A one year reservation captures a smaller discount; a three year reservation captures a deeper one for the same capacity. Leaving steady storage unreserved does not just forgo this month's discount, it forgoes the deeper multi-year rate on capacity you were always going to hold, and that gap recurs for the full life of the data.

The trade-off is genuinely small. A reservation is a billing-only construct: it does not change durability, performance, availability or how the data is accessed. The only real risk is over-committing capacity you later shed, and that is bounded because reservations can be exchanged for another storage reservation at no fee and refunded for a prorated credit on the unused term, subject to a documented annual refund cap. The cost of inaction is steady, recurring and certain; the cost of action is a bounded, reversible commitment.

How do you capture the reservation saving safely?

Treat this as a sizing exercise, not a switch to flip. The order matters: prove the durable baseline first, then commit only that slice, so the discount lands on storage you keep without stranding spend on capacity you might shed.

1. Read the Advisor recommendation in full

Pull the blob reserved-capacity recommendation and read the suggested region, access tier, redundancy and term, plus its estimated saving. Advisor bases this on recent usage, so treat it as a starting point to validate, not a number to approve blind. Confirm the suggested attributes match where your steady data actually lives.

2. Separate the durable baseline from volatile growth

A reservation discounts steady capacity, so commit only the slice that has been present continuously and is certain to remain. Use your own usage history to find the floor the footprint never drops below, and leave recent or churn-prone data on pay-as-you-go. Size to the baseline, not to peak or to a recent spike.

3. Choose term, scope and payment to match confidence

Pick one year for a younger workload and three years for storage you know is permanent, since the longer term carries the deeper discount. Choose single, shared or management-group scope so the discount can float across the subscriptions that hold matching data. Pay upfront or monthly at no extra cost, whichever suits cash flow. Confirm you have the owner or reservation purchaser role before buying.

4. Purchase, then verify and revisit

Calculate the price first, purchase the reservation, and confirm the discount is applying to matching usage. Reservations do not auto-renew, so diarise the expiry: Azure emails 30 days before and again on the day. Revisit sizing each term as the baseline grows, topping up with additional reservations rather than over-committing in one go.

# 1. Confirm the attributes Advisor suggests, then price the reservation BEFORE buying.
#    --reserved-resource-type BlockBlob covers block blob AND Data Lake Gen2 capacity.
#    Replace the SKU/quantity/location with the values that match your baseline.
az reservations reservation-order calculate \
  --reserved-resource-type BlockBlob \
  --sku "<blob-reservation-sku>" \
  --location uksouth \
  --term P3Y \
  --billing-plan Monthly \
  --quantity 1 \
  --applied-scope-type Single \
  --applied-scope "/subscriptions/<subscription-id>" \
  --billing-scope "<subscription-id>" \
  --display-name datalake-baseline-uksouth

# 2. Purchase the reservation. Generate a GUID for --reservation-order-id yourself
#    (the calculate step also returns one you can reuse): it identifies the order you place.
az reservations reservation-order purchase \
  --reservation-order-id "<reservation-order-guid>" \
  --reserved-resource-type BlockBlob \
  --sku "<blob-reservation-sku>" \
  --location uksouth \
  --term P3Y \
  --billing-plan Monthly \
  --quantity 1 \
  --applied-scope-type Single \
  --applied-scope "/subscriptions/<subscription-id>" \
  --billing-scope "<subscription-id>" \
  --display-name datalake-baseline-uksouth

Quick quiz

Question 1 of 5

Azure Advisor recommends 'Consider Blob storage reserved instance to save on Blob v2 and Datalake storage Gen2 costs'. What is it telling you?

You can now treat the blob reserved-capacity recommendation as a savings lever rather than a chore: confirm the durable baseline of block blob and Data Lake Gen2 capacity, size a reservation to that proven floor, choose the term and scope that match your confidence, and let the discount land automatically on storage you keep. The data does not move, the service does not change, and the commitment is bounded and reversible.

Back to the library