.png)
Key takeaways
1
Reserved Capacity is no longer the only commitment option for databases, the newer Savings Plan for Databases covers SQL Database and Cosmos DB. Blob Storage capacity still requires a reservation for any discount.
2
SQL Database has the deepest discount stack: reservation on compute plus Azure Hybrid Benefit on the license pushes savings up to 80%. Teams with Software Assurance who haven't enabled it are leaving the biggest savings on the table.
3
Reservations are billing constructs, they don't change how resources perform or scale. Cancellation gets a prorated refund, with no early-termination fee currently charged.
Azure Reserved Capacity is Microsoft’s commitment discount for data services: SQL Database, Cosmos DB, Blob Storage, and Synapse Analytics. What each reservation actually discounts is narrower than most teams assume and buying the wrong instrument, or the wrong size, turns the discount into a sunk cost.
The short answer
Azure SQL Database reservations discount vCore compute only, Cosmos DB reservations discount provisioned throughput at up to 63%, and Blob Storage reservations discount stored capacity in 100 TiB or 1 PiB blocks. Everything else storage, networking, licenses still bills pay-as-you-go.
A reservation only pays off on resources running at a stable level every hour, because unused reserved hours are simply lost. Size to that stable floor and leave the rest on pay-as-you-go.
A reservation only pays off on resources running at a stable level every hour, because unused reserved hours are simply lost. Size to that stable floor and leave the rest on pay-as-you-go.
Azure Reserved Capacity vs Reservations vs Savings Plans
Microsoft uses the terms Azure Reservations, Reserved Instances, and Reserved Capacity in ways that overlap, and most third-party guides don’t clean this up. The practical distinction matters for knowing which discount instrument to buy.
Azure Reservations is the umbrella term for resource-specific commitments: Reserved VM Instances and Reserved Capacity. Savings Plans sit alongside them as a separate, spend-based commitment type.
Four instruments in total:
Azure Reservations is the umbrella term for resource-specific commitments: Reserved VM Instances and Reserved Capacity. Savings Plans sit alongside them as a separate, spend-based commitment type.
Four instruments in total:
- Reserved VM Instances: commit to a specific VM family and size in a specific region.
- Azure Reserved Capacity: commits to specific data service resources: SQL Database vCores, Cosmos DB RU/s, Blob Storage capacity, Synapse commit units, and others.
- Azure Savings Plan for Compute: a fixed hourly dollar commitment across eligible compute services (VMs, AKS, App Service, Azure Functions Premium, Azure Container Instances), on a 1-year or 3-year term.
- Azure Savings Plan for Databases: launched in March 2026 as a separate 1-year-only plan. Covers compute for Azure SQL Database (including serverless and Hyperscale), SQL Managed Instance, Azure Database for PostgreSQL and MySQL, Cosmos DB, and DocumentDB, at savings of 0–35%.
The critical boundary:
Savings Plans now reach most database compute, but they still do not cover Blob Storage capacity, Synapse commit units, or most storage and analytics resource consumption. Those still require Reserved Capacity as the discount mechanism.
If your bill carries significant storage or Synapse spend, a Savings Plan alone will not address those costs. Verify your specific configuration on the official Azure Savings Plans eligibility page before purchasing either commitment instrument.
For a deeper comparison of the spend-based instruments, see [Azure Savings Plans vs Reserved Instances: Which One to Choose for Your Azure Environment].
For a deeper comparison of the spend-based instruments, see [Azure Savings Plans vs Reserved Instances: Which One to Choose for Your Azure Environment].
Which Instrument Covers Which Service
| Azure Service | Reserved Capacity | Savings Plan | Neither (PAYG only) |
|---|---|---|---|
| SQL Database vCores (vCore model) | Yes, up to ~33%; up to 80% stacked with AHB* | Yes, Savings Plan for Databases | DTU-based configs (reservations); serverless: Savings Plan for Databases only** |
| SQL Managed Instance vCores | Yes | Yes, Savings Plan for Databases | — |
| Cosmos DB provisioned RU/s | Yes, up to 63% | Yes, Savings Plan for Databases | Serverless Cosmos DB (reservations) |
| Cosmos DB storage | No | No | Yes, always PAYG |
| Blob Storage capacity (block blob / ADLS Gen2) | Yes, units of 100 TiB or 1 PiB | No | Sub-100 TiB footprints |
| Blob Storage egress / operations | No | No | Yes, always PAYG |
| Synapse Analytics | Yes, via SCU Pre-Purchase (1-yr, no cancellation) | No | Ad-hoc or short-term use |
| Synapse storage / networking | No | No | Yes, always PAYG |
| SQL Database storage / networking / license | No | No | Yes, use Azure Hybrid Benefit for license |
| Azure Cache for Redis | Yes | No | Low-volume or unpredictable Redis |
| VMs / AKS / App Service / Functions Premium | No (use Reserved VM Instances) | Yes, Savings Plan for Compute | Highly variable compute |
*Reservation and Savings Plan rates vary by configuration, verify eligibility and current rates at azure.microsoft.com before purchasing. **Serverless SQL Database compute is covered by the Savings Plan for Databases, not by reservations.
Azure Database for PostgreSQL, MySQL, and Azure Cache for Redis also carry their own reserved capacity offerings under the same compute-only coverage rule.
Azure Database for PostgreSQL, MySQL, and Azure Cache for Redis also carry their own reserved capacity offerings under the same compute-only coverage rule.
Choosing the right Azure commitment
Work down the table in three steps.
- First, check whether the Savings Plan for Databases already covers the service for SQL Database, SQL Managed Instance, and Cosmos DB compute, the 1-year plan is the flexible default when configurations may change.
- Second, if the resource will run at a stable level for the full term, a fixed vCore count, a constant RU/s floor, or 100 TiB+ of storage, a reservation earns the deeper discount.
- Third, anything variable, serverless Cosmos DB, or below the purchase minimums stays on pay-as-you-go.
The Use-It-or-Lose-It Billing Rule
A reservation discount is use-it-or-lose-it. If you do not have matching resources consuming the reserved quantity in a given hour, that hour’s reservation benefit is lost. Unused reserved hours cannot be carried forward.
When a resource is shut down, Azure automatically applies the reservation discount to another matching resource within the reservation’s scope. If no matching resource exists in scope, the reserved hours are lost for that hour.
This has one direct sizing implication: always reserve to the stable floor, not the average.
The stable floor is the resource level vCores, RU/s, or storage capacity, that will be present and consuming every single hour for the full reservation term.
Anything above the floor is better served by pay-as-you-go pricing than by a reservation that will periodically go unused. Every percentage point above your stable floor that you commit to is a percentage point you are paying for without receiving a discount benefit.
Scope selection amplifies this rule. Reservations can be scoped to:
Two purchase mechanics worth knowing:
When a resource is shut down, Azure automatically applies the reservation discount to another matching resource within the reservation’s scope. If no matching resource exists in scope, the reserved hours are lost for that hour.
This has one direct sizing implication: always reserve to the stable floor, not the average.
The stable floor is the resource level vCores, RU/s, or storage capacity, that will be present and consuming every single hour for the full reservation term.
Anything above the floor is better served by pay-as-you-go pricing than by a reservation that will periodically go unused. Every percentage point above your stable floor that you commit to is a percentage point you are paying for without receiving a discount benefit.
Scope selection amplifies this rule. Reservations can be scoped to:
- a shared billing context
- a management group
- a single subscription
- a single resource group
Two purchase mechanics worth knowing:
- You can pay upfront or in monthly installments at no extra cost.
- When a reservation expires your resources keep running billed at pay-as-you-go rates, since reservations don’t renew automatically.
Azure SQL Database Reserved Capacity
An Azure SQL Database reservation covers the compute costs only. It does not cover software license costs, networking, or storage charges, per Microsoft’s reservation coverage documentation.
This is the most important thing to know about SQL Database reservations. The reservation discount applies specifically to the vCore compute component of your bill; storage (per-GB for data and backup), networking, and the software license fee (if you are not using Azure Hybrid Benefit) continue at pay-as-you-go rates regardless of coverage.
For the General Purpose service tier, reservations are also available to cover compute costs associated with the zone-redundancy add-on.
SQL Database reservations are available for the vCore purchasing model only. DTU-based configurations are not eligible, and neither is the serverless compute tier; serverless is instead covered by the Savings Plan for Databases.
If you are running DTU-based configurations and want reserved capacity, migration to the vCore model is required first.
This is the most important thing to know about SQL Database reservations. The reservation discount applies specifically to the vCore compute component of your bill; storage (per-GB for data and backup), networking, and the software license fee (if you are not using Azure Hybrid Benefit) continue at pay-as-you-go rates regardless of coverage.
For the General Purpose service tier, reservations are also available to cover compute costs associated with the zone-redundancy add-on.
SQL Database reservations are available for the vCore purchasing model only. DTU-based configurations are not eligible, and neither is the serverless compute tier; serverless is instead covered by the Savings Plan for Databases.
If you are running DTU-based configurations and want reserved capacity, migration to the vCore model is required first.
Stacking with Azure Hybrid Benefit
Azure Hybrid Benefit removes the software license cost from the hourly rate; reserved capacity then applies to the reduced compute-only rate.
For eligible provisioned vCore SQL Database configurations using SQL Server licenses with active Software Assurance, Azure Hybrid Benefit and an Azure Reservation can reduce costs by up to 80% versus pay-as-you-go per the Azure SQL Database pricing page. Actual savings vary by configuration, and Azure Hybrid Benefit is not available for new Hyperscale databases.
Also read: [Azure Hybrid Benefit: How It Works, What It Actually Saves, and the SA Expiration Risk Most Teams Ignore]
Azure SQL Managed Instance reservations follow the same compute-only rule, in 1-year and 3-year terms, with the zone-redundancy add-on also coverable.
For eligible provisioned vCore SQL Database configurations using SQL Server licenses with active Software Assurance, Azure Hybrid Benefit and an Azure Reservation can reduce costs by up to 80% versus pay-as-you-go per the Azure SQL Database pricing page. Actual savings vary by configuration, and Azure Hybrid Benefit is not available for new Hyperscale databases.
Also read: [Azure Hybrid Benefit: How It Works, What It Actually Saves, and the SA Expiration Risk Most Teams Ignore]
Azure SQL Managed Instance reservations follow the same compute-only rule, in 1-year and 3-year terms, with the zone-redundancy add-on also coverable.
Azure Cosmos DB Reserved Capacity
An Azure Cosmos DB reservation covers throughput provisioned for your resources. It does not cover storage or networking charges.
Cosmos DB bills on two dimensions: provisioned throughput (Request Units per second, or RU/s) and storage (GB per month). A reservation covers the RU/s dimension only for multi-TB Cosmos DB databases, the storage component bills at pay-as-you-go rates and can be substantial.
The discount is tiered. Per Microsoft’s Cosmos DB reserved capacity documentation, reservations below 1 million RU/s carry fixed discounts of 20% (1-year) or 30% (3-year). Progressive discounts start at 1 million RU/s, and the headline up-to-63% figure applies only at the largest multi-master tiers on a 3-year term. Check the Azure portal for current tier-specific rates.
Cosmos DB bills on two dimensions: provisioned throughput (Request Units per second, or RU/s) and storage (GB per month). A reservation covers the RU/s dimension only for multi-TB Cosmos DB databases, the storage component bills at pay-as-you-go rates and can be substantial.
The discount is tiered. Per Microsoft’s Cosmos DB reserved capacity documentation, reservations below 1 million RU/s carry fixed discounts of 20% (1-year) or 30% (3-year). Progressive discounts start at 1 million RU/s, and the headline up-to-63% figure applies only at the largest multi-master tiers on a 3-year term. Check the Azure portal for current tier-specific rates.
RU/s sizing: the key challenge
Cosmos DB supports two provisioning models. Standard provisioned throughput is a fixed RU/s you set manually constant and easy to reserve.
Autoscale throughput scales between 10% and 100% of a maximum RU/s you configure. Reserving at the maximum would waste the reservation during low-traffic hours and autoscale consumes reservations at 1.5× the provisioned RU/s, so a 50,000 RU/s autoscale floor draws 75,000 RU/s from your reservation each hour.
The practical recommendation: reserve at the minimum provisioned throughput that will be present continuously across all containers in scope.
For autoscale databases, that is 10% of the maximum autoscale RU/s, multiplied by the 1.5× autoscale consumption factor. For standard provisioned databases, it is the manual RU/s setting for each container.
Autoscale throughput scales between 10% and 100% of a maximum RU/s you configure. Reserving at the maximum would waste the reservation during low-traffic hours and autoscale consumes reservations at 1.5× the provisioned RU/s, so a 50,000 RU/s autoscale floor draws 75,000 RU/s from your reservation each hour.
The practical recommendation: reserve at the minimum provisioned throughput that will be present continuously across all containers in scope.
For autoscale databases, that is 10% of the maximum autoscale RU/s, multiplied by the 1.5× autoscale consumption factor. For standard provisioned databases, it is the manual RU/s setting for each container.
A worked example at published rates: a standard provisioned account running 50,000 RU/s continuously at ~$0.008 per 100 RU/s per hour costs roughly $2,880 per month on pay-as-you-go.
At the published fixed tiers, a 1-year reservation (20% off) brings that to ~$2,304, and a 3-year reservation (30% off) to ~$2,016 around $31,000 saved over a 3-year term. The account’s storage (~$0.25/GB/month in US East) is unaffected by any reservation. Prices are illustrative; model against your portal rates before committing.
At the published fixed tiers, a 1-year reservation (20% off) brings that to ~$2,304, and a 3-year reservation (30% off) to ~$2,016 around $31,000 saved over a 3-year term. The account’s storage (~$0.25/GB/month in US East) is unaffected by any reservation. Prices are illustrative; model against your portal rates before committing.
Azure Blob Storage Reserved Capacity
Azure Blob Storage reserved capacity covers storage capacity only. Egress charges, PUT/GET/LIST operation charges, and data retrieval fees for cool and archive tiers continue at pay-as-you-go rates for large accounts with frequent API calls or cold-data retrieval, a meaningful share of the bill sits outside the reservation.
You can purchase reserved capacity in units of 100 TiB and 1 PiB per month, for one-year or three-year terms, across hot, cool, and archive tiers and all redundancy options, per Microsoft’s Blob Storage reserved capacity documentation.
Each reservation is locked at purchase to one region, one access tier, and one redundancy configuration; a hot-tier ZRS reservation in one region cannot cover archive data, GRS data, or another region. When you purchase a Blob Storage reservation, it applies to both block blob and Azure Data Lake Storage Gen2 data within the purchased scope.
The 100 TiB minimum matters for smaller footprints. If your stable storage is 50 TB, the minimum purchase reserves double your capacity, and the excess is wasted under the use-it-or-lose-it rule.
Reservations apply across the purchased scope down to a single resource group but cannot be targeted to a specific storage account, container, or object. Teams running chargeback or showback models will need to allocate the reservation benefit manually across projects.
You can purchase reserved capacity in units of 100 TiB and 1 PiB per month, for one-year or three-year terms, across hot, cool, and archive tiers and all redundancy options, per Microsoft’s Blob Storage reserved capacity documentation.
Each reservation is locked at purchase to one region, one access tier, and one redundancy configuration; a hot-tier ZRS reservation in one region cannot cover archive data, GRS data, or another region. When you purchase a Blob Storage reservation, it applies to both block blob and Azure Data Lake Storage Gen2 data within the purchased scope.
The 100 TiB minimum matters for smaller footprints. If your stable storage is 50 TB, the minimum purchase reserves double your capacity, and the excess is wasted under the use-it-or-lose-it rule.
Reservations apply across the purchased scope down to a single resource group but cannot be targeted to a specific storage account, container, or object. Teams running chargeback or showback models will need to allocate the reservation benefit manually across projects.
Work out your breakeven.
Breakeven capacity (GB)
=
Monthly reservation cost
PAYG rate per GB/month
If your stable storage sits below breakeven — or below the 100 TiB minimum
unit — pay-as-you-go is cheaper than reserving.
Azure Files has its own separate reservations in 10 TiB and 100 TiB units, under the same capacity-only coverage rule.
The Layered Savings Strategy
For organizations running a full Azure data stack, complete coverage layers the instruments:
- Savings Plans: for dynamic compute and the database services now covered by the Savings Plan for Databases, where resource types change over time.
- Reserved VM Instances: for stable, fixed-type VM pools where the deeper discount justifies the narrower commitment.
- Reserved Capacity: for stable data service consumption: SQL vCores (stacked with Azure Hybrid Benefit), Cosmos DB RU/s sized to the stable floor, and Blob Storage above the 100 TiB threshold.
Before You Buy a Data Service Reservation.
Savings Plan checked first
Confirm whether the Savings Plan for Databases already covers your service before committing to a reservation.
Stable floor identified
Size to the resource level present every hour of the term, not the average or peak.
Purchase attributes locked
For Blob, region, access tier, and redundancy are fixed per reservation; verify before buying.
Scope decided
Shared scope absorbs unused hours across subscriptions; narrower scopes strand them.
How Usage.ai Handles Azure Commitments
The data-service reservations in this guide SQL Database, Cosmos DB, and Blob Storage are purchased and managed directly in the Azure portal, using the stable-floor sizing covered above.
But as the layered strategy shows, Reserved Capacity is only one layer of complete Azure coverage: the compute layer VM reservations and Savings Plans carries the same use-it-or-lose-it risk, and that’s the layer we manage.
Through our Flex Commitment Program, we analyze utilization daily, size Azure compute commitments to your stable floor, and back every Flex Commitment with cashback protection: if a Flex Commitment ends up costing more than the on-demand equivalent for the same usage, that difference is returned as cashback in real money.
Get the 65–72% savings of Azure compute commitments with none of the commitment risk. See how the platform works
But as the layered strategy shows, Reserved Capacity is only one layer of complete Azure coverage: the compute layer VM reservations and Savings Plans carries the same use-it-or-lose-it risk, and that’s the layer we manage.
Through our Flex Commitment Program, we analyze utilization daily, size Azure compute commitments to your stable floor, and back every Flex Commitment with cashback protection: if a Flex Commitment ends up costing more than the on-demand equivalent for the same usage, that difference is returned as cashback in real money.
Get the 65–72% savings of Azure compute commitments with none of the commitment risk. See how the platform works
Frequently asked questions
Can I cancel or exchange a data service reservation after purchase?
Yes, with limits. Cancellation returns a prorated refund Microsoft is not currently charging the 12% early termination fee it reserves the right to apply and refunds are capped at $50,000 per rolling 12-month window, per Microsoft's exchange and refund policy. Exchanges are self-service within the same product family; note that reservations purchased after February 1, 2027 for services covered by Savings Plans will no longer be exchangeable.
Synapse Pre-Purchase Plans are the exception: cancel and exchange are not supported at all, and every SCU purchase is final.
Does reserved capacity affect my resource's performance or availability?
No. Reserved capacity is a billing construct only. It does not change how your SQL Database, Cosmos DB, Blob Storage, or Synapse resources operate, perform, or scale. Your resources behave identically whether covered by a reservation or billed at pay-as-you-go rates.
Share
Facebook
X
LinkedIn
Reddit
