Cost

Buy Azure Synapse Analytics reserved capacity

One cost capability for the dedicated SQL pool: when a Synapse data warehouse runs at a steady cDWU level around the clock, commit that baseline to a one or three-year reservation so the compute stops being billed at the pay-as-you-go rate, and pocket the difference on the Azure bill.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Synapse reserved capacity: the basics

What does Azure Advisor mean by 'consider a Synapse reservation to save over pay-as-you-go'?

An Azure Synapse Analytics dedicated SQL pool (formerly SQL DW) is billed on compute data warehouse units, the cDWU level you provision, charged by the hour at the pay-as-you-go rate whenever the pool is online. If that pool runs at a steady level around the clock, you are paying the on-demand rate for capacity you use predictably, which is exactly the pattern a reservation is built to discount. Azure Advisor watches the cDWU meter and, when it sees a consistent baseline, raises the Cost recommendation 'Consider Azure Synapse Analytics (formerly SQL DW) reservation to save over the pay-as-you-go costs' (recommendation ID 680a5388-28aa-44e8-88af-32e3598dc869).

A reservation is a billing instrument, not a resource change. You commit to a quantity of cDWU for a one or three-year term, paid upfront or monthly, and Azure applies the reservation discount automatically to any matching running warehouse in scope. Nothing about the pool itself changes: same region, same performance level, same connection strings. The only difference is the rate the compute meter is billed at. The reservation covers the cDWU compute meter only; storage and networking stay at pay-as-you-go rates.

The recommendation surfaces because Advisor has analysed your recent hourly usage and concluded that a reservation would have cost less than what you actually paid on demand over that window. Each recommendation carries Advisor's own estimate of the saving and the cDWU quantity that maximises it. The work is to confirm the baseline is genuinely steady, pick the term and scope that match how the workload runs, and buy the right number of 100-cDWU units, no more than the floor the pool reliably sits at.

In this lesson you will learn how Azure Synapse dedicated SQL pool compute is billed, why a steady cDWU baseline is the signal that a reservation will save money, and how to size, scope and buy reserved capacity without over-committing. You will see the exact Advisor recommendation, the az CLI to model and purchase a reservation, and a Bicep definition for buying one as code.

Fun fact

A reservation buys a price, not a machine

It is a common surprise that an Azure reservation does not provision anything. Buy a Synapse reservation and no new warehouse appears, no capacity is set aside, nothing is pinned to your name. What you have bought is purely a billing discount: a promise from Azure to charge the lower committed rate on the first matching cDWU it sees running each hour, anywhere in your chosen scope and region. Pause the pool and the discount for that hour simply evaporates, because there was no matching usage to apply it to. That is why the reservation only ever pays off against capacity that is genuinely, predictably on.

Finding the steady baseline before you commit

Priya runs the data platform at a retailer whose Synapse dedicated SQL pool powers the nightly batch and the daytime BI layer. Azure Advisor has raised the Synapse reservation recommendation, estimating a saving against the pay-as-you-go rate the pool is currently billed at.

Before buying anything, Priya wants to see the recommendation Advisor actually raised and the cDWU quantity it suggests, so the commitment is sized to a baseline the pool genuinely sits at rather than to its busiest hour.

Pull the Cost recommendations and isolate the Synapse reservation one. Advisor has already done the usage analysis and attached the quantity that maximises the saving.

$ az advisor recommendation list --category Cost \ --query "[?contains(shortDescription.solution, 'SQL DW') || contains(shortDescription.solution, 'Synapse')].{problem:shortDescription.problem, solution:shortDescription.solution}" -o table

Problem Solution

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

You could save by using reservations Consider Azure Synapse Analytics (formerly SQL DW)

reservation to save over the pay-as-you-go costs

# Recommendation 680a5388-28aa-44e8-88af-32e3598dc869. Now confirm the baseline is steady.

Advisor raises the recommendation only after analysing recent hourly usage, so it already reflects a baseline. Confirm the pool runs that level around the clock before committing to a term.

How the Synapse reservation discount actually appliesdeep dive

A reservation is matched to usage on the cDWU meter, hour by hour. After purchase, Azure applies the reserved capacity discount automatically to any running dedicated SQL pool that matches the reservation's region and scope, charging the committed rate instead of the pay-as-you-go rate on the cDWU it covers. The discount applies to the compute meter only: storage and networking on the warehouse continue to bill at pay-as-you-go rates. Purchases are made in 100-cDWU units, so a quantity of ten covers a DW1000c baseline.

The matching is hourly and does not carry over. If you reserve five units of 100 cDWU and the pool runs at DW1500c for an hour, the discount covers the five reserved units and the remaining ten units of that hour are billed at pay-as-you-go. If the pool runs below the reserved level, or is paused, the unused reservation for that hour is simply wasted: it does not bank, roll forward or refund. This is the entire reason sizing matters. A reservation set to the pool's floor is almost always covered and almost never wasted; one set to its peak is wasted every hour the pool is quieter than peak.

Scope decides which warehouses the discount can match. Single subscription or single resource-group scope confines it to one place; shared scope lets it apply to matching warehouses across the eligible subscriptions in the billing context; management-group scope spreads it across the subscriptions in that group. Wider scope makes the reservation easier to keep fully utilised, because if one pool pauses the discount can flow to another matching pool, which is the practical lever for avoiding wasted hours when more than one warehouse exists.

What is the impact of leaving steady compute on pay-as-you-go?

The direct impact is a recurring overpayment. Every hour a steady dedicated SQL pool runs without a reservation, its compute is billed at the pay-as-you-go rate when the committed rate was available for the same capacity. The gap is not dramatic in any single hour, but a warehouse that runs around the clock multiplies that gap by thousands of hours a year, which is precisely why Advisor's estimated saving on the recommendation is material rather than rounding error.

The second-order impact is that the overpayment is invisible and compounding. There is no error, no failed check and no alert: the pool works perfectly and the bill is simply higher than it needs to be, month after month, for as long as the recommendation sits unactioned. Because nothing breaks, this is the kind of saving that drifts to the bottom of the list, even though it is one of the lowest-effort, lowest-risk reductions available on the Azure bill.

The cost of acting is small and bounded: the time to confirm the baseline, choose a term and scope, and buy the right number of units. The only way to turn the saving into a loss is to over-commit, reserving above the level the pool reliably holds, so the discipline is to size to the floor. Done that way, the impact is a clean reduction in the compute line with no change to the workload and no operational risk.

How do you buy Synapse reserved capacity safely?

Work the recommendation as a sizing exercise, not just a purchase. The order matters: confirm the baseline and model the price before you commit, so you reserve the floor the pool reliably holds rather than a level it only touches at peak.

1. Confirm the steady cDWU baseline

Look at the pool's hourly cDWU over the last 30 to 60 days and find the level it reliably sits at or above. That floor, not the average and never the peak, is what you reserve. If the pool pauses overnight or at weekends, factor those idle hours in, because the reservation discount is wasted for any hour the pool is below the reserved quantity.

2. Model the price before committing

Use the reservation calculate command to price the exact quantity, term and scope you intend to buy, so the saving and payback are confirmed numbers rather than the headline estimate. Compare the one-year and three-year terms explicitly: a longer term gives a larger discount in exchange for a longer commitment to the same workload at the same level.

3. Choose the scope that keeps it utilised

Single-subscription scope is simplest when one pool owns the baseline. If you run more than one matching warehouse, shared or management-group scope lets the discount flow to whichever pool is running, so the reservation stays utilised even if one pool pauses. Wider scope is the practical defence against wasted hours.

4. Buy the floor and revisit on a schedule

Purchase the reservation for the confirmed baseline, leave the variable top slice on demand, and set a reminder to review utilisation and the expiry date. Reservations do not auto-renew, and a workload's floor shifts over time, so a standing review is what keeps the commitment matched to the saving rather than drifting into waste.

# 1. Model the price first: a one-year reservation for a DW1000c baseline.
#    Quantity is in units of 100 cDWU, so 10 units = DW1000c. SKU is the cDWU SKU.
sub="00000000-0000-0000-0000-000000000000"
az extension add --name reservation --only-show-errors

az reservations reservation-order calculate \
  --reserved-resource-type SqlDataWarehouse \
  --sku DWU \
  --location westeurope \
  --quantity 10 \
  --term P1Y \
  --billing-plan Monthly \
  --applied-scope-type Single \
  --applied-scope "/subscriptions/$sub" \
  --billing-scope "$sub" \
  --display-name synapse-baseline-dw1000c

# 2. Inspect the returned billingCurrencyTotal and savings, confirm the payback,
#    then purchase against the reservationOrderId the calculate step returned.
orderId=$(cat /proc/sys/kernel/random/uuid)
az reservations reservation-order purchase \
  --reservation-order-id "$orderId" \
  --reserved-resource-type SqlDataWarehouse \
  --sku DWU \
  --location westeurope \
  --quantity 10 \
  --term P1Y \
  --billing-plan Monthly \
  --applied-scope-type Single \
  --applied-scope "/subscriptions/$sub" \
  --billing-scope "$sub" \
  --display-name synapse-baseline-dw1000c

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider Azure Synapse Analytics (formerly SQL DW) reservation to save over the pay-as-you-go costs'. What does buying that reservation actually change?

Keep learning

Go deeper on how Azure Synapse reservations are priced, applied and sized so the commitment captures the saving without drifting into waste.

You can now treat a Synapse reservation as one cost capability rather than a one-off purchase: confirm the dedicated SQL pool's steady cDWU floor, model the price with the calculate command, choose the scope that keeps the discount utilised, buy the baseline in 100-cDWU units, and revisit utilisation and expiry on a schedule. The recommendation is Advisor telling you predictable compute is still on the on-demand rate; sizing to the floor is what turns it into a clean saving.

Back to the library

Synapse reserved capacity: the savings view

Turning a steady on-demand compute line into a committed, discounted one with a clear payback

This is a pure savings lever, not a risk control. The dedicated SQL pool compute is already running and already paid for at the pay-as-you-go rate. A reservation does not add capability or change the workload; it re-prices a baseline you are committed to running anyway, so the saving falls straight to the bottom line of the Azure bill. Advisor has done the first pass of the maths and attached an estimated saving to the recommendation.

The decision is a commitment trade. You exchange flexibility for a lower rate: a one-year term gives a smaller discount with a shorter lock-in, a three-year term gives a larger discount for a longer commitment. The right answer depends on how confident you are that this warehouse, at roughly this cDWU level, will still be running for the length of the term. The reservation can be cancelled, exchanged or refunded within Microsoft's limits, so the commitment is real but not absolute.

The only genuine cost risk is over-committing. The reservation discount is wasted for any hour the warehouse is not running, and it does not carry over. So the unit of analysis is the floor the pool reliably sits at, not its peak. Buy the steady baseline, leave the variable top slice on demand, and the payback is straightforward arithmetic that you can put on a single line of the savings pack.

This lesson is for the finance partner who sees a Synapse reservation recommendation in Azure Advisor and wants to know what it saves, how the payback works, and where the only real risk, over-committing to capacity that is not steady, actually sits. It covers how to size the reservation to the workload's floor and how to frame the one-year versus three-year term as a commitment trade.

Fun fact

A reservation buys a price, not a machine

How a finance partner frames the reservation decision

Priya is the finance partner for the data platform. The Advisor recommendation lands with an estimated saving attached, and the instinct is not to approve the purchase on the headline figure alone; it is to ask what baseline the saving rests on. Advisor calculates the recommendation from recent hourly usage and suggests the cDWU quantity that would have maximised the saving, so the first question is whether that quantity is a floor the pool reliably sits at or a level it only touches at peak. The reservation discount is wasted for any hour the warehouse is below the reserved quantity, so over-buying quietly erodes the very saving the recommendation promises.

Priya reframes the recommendation as a commitment line rather than a one-off win. The pool runs a steady DW1000c overnight and through the working day, dropping only on weekends, so the defensible commitment is the level it holds almost every hour, not the DW1500c it peaks to during month-end. The savings pack reads: 'The pool's reliable floor is DW1000c; reserving that for one year captures Advisor's estimated saving with a payback of a few months, the weekend dip and the month-end peak stay on demand, and the only number we need to watch is the pool's hourly minimum so we never reserve above it.' The one-year versus three-year choice becomes an explicit trade: a larger discount for three years against the confidence that this warehouse, at this level, is still here in year three.

Why an unactioned reservation recommendation is money on the table

The cost model here is the inverse of most security work: the saving is concrete and recurring, and the risk of acting is small and entirely within your control. Each month the recommendation sits open, the steady compute keeps billing at the pay-as-you-go rate, and the difference against the committed rate is a real, quantifiable overpayment that Advisor has already estimated for you. There is no breach scenario to weigh, just an arithmetic gap between two prices for the same capacity.

The single risk to manage is over-commitment. A reservation sized above the pool's reliable floor wastes its discount in every hour the pool runs quieter, which erodes the saving. So the finance role is to anchor the commitment to the workload's hourly minimum, not its average or peak, and to treat the one-year versus three-year choice as a confidence trade: more discount for three years against the certainty that this warehouse, at this level, is still running in year three. The reservation can be exchanged or refunded within Microsoft's limits, so a sizing mistake is recoverable rather than terminal, but the cleaner discipline is to size conservatively and top up later.

What finance can do about the reservation gap

Finance cannot run the purchase command, but it owns the framing that turns an Advisor estimate into a sized, defensible commitment with a known payback. Three levers.

1. Anchor the commitment to the floor, not the average

Make explicit that the reservation should be sized to the cDWU level the pool reliably holds in almost every hour, not its average and never its peak. The discount is wasted for any hour the pool runs below the reserved quantity, so the floor is the only number that protects the saving. Ask the team for the pool's hourly minimum over the last 30 to 60 days and reserve at or just below it.

2. Treat the term length as an explicit confidence trade

The one-year versus three-year choice is a finance decision, not a technical one. A three-year term gives a larger discount in exchange for committing to this workload at this level for three years. Tie the term to how confident the business is that the warehouse, at roughly this size, is still running that far out, and prefer the shorter term where the roadmap is uncertain. The reservation can be exchanged or refunded within limits, so the choice is recoverable but not free to churn.

3. Confirm the payback with calculate, not the headline

Before approving, ask for the output of the reservation calculate command for the exact quantity, term and scope, so the saving and break-even are confirmed figures rather than Advisor's first-pass estimate. Put the modelled saving, the payback in months and the reserved baseline on a single line of the savings pack, and schedule a utilisation review so the commitment is revisited before expiry and whenever the floor shifts.

Quick quiz

Question 1 of 5

The Advisor recommendation shows an estimated saving. As the finance partner, what is the right first question before approving the purchase?

Keep learning

Go deeper on how Azure Synapse reservations are priced, applied and sized so the commitment captures the saving without drifting into waste.

You have finished the finance view of buying Synapse reserved capacity. You know the saving is concrete and recurring, that the only real risk is over-committing above the pool's reliable floor, and that the one-year versus three-year term is a confidence trade rather than a pure discount grab. Next time an Advisor reservation recommendation lands, you will anchor the commitment to the hourly minimum, confirm the payback with the calculate step, and put the modelled saving and reserved baseline on a single line rather than approving on the headline estimate.

Back to the library

Synapse reserved capacity: the headline

Whether predictable analytics compute is being bought at the committed rate or the list rate

Azure bills cloud compute two ways: a higher pay-as-you-go rate for capacity you might switch off at any moment, and a lower committed rate for capacity you promise to keep running. A data warehouse that runs around the clock at a steady level is, by definition, the second kind, and Advisor is flagging that it is still being charged at the first.

The leadership question is not technical. It is simply: are we paying the on-demand premium on compute we are committed to running anyway? Where the answer is yes, a reservation closes the gap with no change to the service and a payback that is usually measured in months, not years.

This is the rare cost decision with very little downside. The only way it goes wrong is buying more commitment than the workload reliably uses, which is a sizing discipline, not a reason to avoid the saving. The defensible position is that every steady, long-lived workload is reviewed for a reservation, sized to its baseline, and revisited when usage changes.

A short read for the leader who needs to know why predictable analytics compute should be bought at the committed rate, why a reservation is a near-risk-free saving when sized correctly, and what a defensible reservation discipline looks like across the estate.

Fun fact

A reservation buys a price, not a machine

What it looks like when predictable compute is bought at the committed rate

At a cost review the CFO noticed that the analytics platform was one of the larger steady lines on the Azure bill and asked the obvious question: if it runs all the time, why are we paying the on-demand rate for it? The honest answer was that nobody had converted the predictable part of the workload to a reservation, so the pool had been billed at the pay-as-you-go rate since it went live.

The team's response was to treat the reservation as a standing discipline rather than a one-off purchase. They took the Advisor recommendation, sized the commitment to the cDWU level the pool reliably holds, bought a reservation for that baseline, and left the variable top slice on demand. The next cost review showed the steady compute line drop to the committed rate with no change to the service, a payback measured in months, and a note that the reservation would be revisited before it expired and whenever the workload's baseline shifted. The shift, from paying the on-demand premium on capacity that never switches off to paying the committed rate for it, is the saving this capability delivers, and it carries almost no risk when the commitment is sized to the floor.

Why this is a straightforward savings decision

Almost every estate running a long-lived analytics warehouse is paying the on-demand premium on compute it never intends to switch off. Converting that predictable baseline to a reservation is one of the highest-certainty savings in cloud finance: the workload does not change, the payback is usually measured in months, and Advisor has already quantified the gain.

The downside is limited to a sizing discipline. Buy more commitment than the workload reliably uses and the surplus discount is wasted, so the rule is to reserve the floor and leave the variable slice on demand. Get that right and this is the rare cost decision where the saving is concrete, the effort is small, and the operational risk is essentially nil, which makes it exactly the kind of saving leadership should expect to see actioned, not deferred.

The leadership move on reservations

The executive handle is not to approve each reservation individually; it is to require that every steady, long-lived workload is reviewed for a reservation, sized to its baseline, and revisited on a schedule.

1. Make reservation review a standing discipline

Ask that any workload running predictably for months, the analytics warehouse being the clearest example, is routinely checked against its Advisor reservation recommendation rather than left on the on-demand rate by default. The goal is that paying the committed rate for predictable compute is the norm, not a saving someone has to remember to chase.

2. Insist the commitment is sized to the floor

The one way this saving turns into waste is over-committing. Require that every reservation is sized to the level the workload reliably holds, with the variable slice left on demand, and that the modelled saving and payback are confirmed with the calculate step before purchase. That single discipline is the difference between a clean saving and a wasted commitment.

3. Track expiry and utilisation, not just the purchase

Reservations do not auto-renew and workloads change, so a buy-and-forget reservation can quietly drift into either waste or an unbilled lapse back to pay-as-you-go. Ask for a standing view of reservation utilisation and upcoming expiries, so each commitment is revisited deliberately rather than rediscovered when the bill jumps.

Quick quiz

Question 1 of 5

At a cost review you ask why a steady analytics warehouse is on the on-demand rate. What end state should you be looking for?

Keep learning

Go deeper on how Azure Synapse reservations are priced, applied and sized so the commitment captures the saving without drifting into waste.

Two takeaways. Converting predictable analytics compute from the on-demand rate to a reservation is one of the highest-certainty, lowest-effort savings on the Azure bill, with a payback usually measured in months and almost no operational risk. And the only way it goes wrong is over-committing, so the discipline is simple: review every steady, long-lived workload for a reservation, size it to the floor, and revisit utilisation and expiry on a schedule rather than buying and forgetting.

Back to the library

Part of the learning path Lock in Azure commitments

Buy Azure Synapse Analytics reserved capacity

Synapse reserved capacity: the basics

A reservation buys a price, not a machine

Finding the steady baseline before you commit

How the Synapse reservation discount actually appliesdeep dive

What is the impact of leaving steady compute on pay-as-you-go?

How do you buy Synapse reserved capacity safely?

1. Confirm the steady cDWU baseline

2. Model the price before committing

3. Choose the scope that keeps it utilised

4. Buy the floor and revisit on a schedule

Quick quiz

Keep learning

Synapse reserved capacity: the savings view

A reservation buys a price, not a machine

How a finance partner frames the reservation decision

Why an unactioned reservation recommendation is money on the table

What finance can do about the reservation gap

1. Anchor the commitment to the floor, not the average

2. Treat the term length as an explicit confidence trade

3. Confirm the payback with calculate, not the headline

Quick quiz

Keep learning

Synapse reserved capacity: the headline

A reservation buys a price, not a machine

What it looks like when predictable compute is bought at the committed rate

Why this is a straightforward savings decision

The leadership move on reservations

1. Make reservation review a standing discipline

2. Insist the commitment is sized to the floor

3. Track expiry and utilisation, not just the purchase

Quick quiz

Keep learning

Related cost lessons