Cost

Buy Azure Data Factory reserved capacity

Azure Advisor has spotted that your Data Factory data flows run a steady baseline of compute at the pay-as-you-go rate. A reserved-capacity commitment buys the same cores up front for a one or three year term at a discount, and the saving lands on the bill automatically without touching a single pipeline.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Data Factory reserved capacity: the basics

What is Advisor actually recommending when it says 'consider Data Factory reserved instance'?

Azure Data Factory bills its data flow compute by the vCore-hour. Every time a mapping data flow runs, or a debug session spins up an Azure integration runtime cluster, you pay the pay-as-you-go rate for the cores it uses while it runs. If you run data flows on any kind of regular schedule, hourly loads, nightly transforms, an always-on debug cluster, that adds up to a predictable baseline of compute that you pay full price for, month after month.

Azure Advisor watches that baseline. When it sees enough steady data flow usage over its look-back period, it raises the Cost recommendation 'Consider Data Factory reserved instance to save over the on-demand costs' (recommendation ID 0d524e8d-4cfd-4db5-9f91-8b4bb5235a8e). The recommendation is simple: instead of paying the on-demand rate for those cores, commit to them for a one or three year term and Microsoft gives you a discount on the matching usage. The Advisor text itself reads: 'we recommend reservations to maximize savings. Reservations apply automatically to matching deployments.'

A Data Factory reservation is bought by region, compute type (general purpose or memory optimised) and core count, for a one or three year term. You do not assign it to a specific factory or integration runtime. Once purchased, the reservation discount applies automatically to any matching data flow usage across the scope you chose, and the matching cores stop being charged at the pay-as-you-go rate. Nothing in your pipelines changes. The only thing that changes is the price you pay for compute you were already going to run.

In this lesson you will learn how Azure Data Factory charges for data flow compute, why a steady workload triggers the Advisor reserved-capacity recommendation, how to read what Advisor is offering, and how to size and buy a Data Factory reservation so the discount applies automatically without changing a single pipeline. It is a cost lesson, so the framing throughout is savings and payback, not risk.

Fun fact

The reservation you never have to plug in

A Data Factory reservation is one of the few Azure purchases that buys a discount rather than a thing. Microsoft is explicit that buying reserved capacity does not pre-allocate or reserve any virtual machines or clusters for you, and you never attach the reservation to a factory or an integration runtime. It is purely a billing construct: you commit to a number of cores for a term, and any matching data flow usage anywhere in your chosen scope simply stops being billed at the on-demand rate. The compute you already run quietly gets cheaper, and the only sign anything happened is a smaller line on the invoice.

Reading the Advisor recommendation before you commit

Priya runs the data platform at a retailer whose nightly ETL is built on Azure Data Factory mapping data flows. The pipelines have been stable for months, and the Azure Advisor cost tab now shows 'Consider Data Factory reserved instance to save over the on-demand costs' with a High impact flag.

Before anyone commits money, Priya pulls the recommendation from the command line to see exactly what Advisor is proposing, the term, the quantity and the estimated saving, so the team is sizing a reservation to real baseline usage rather than guessing.

Start by listing the Advisor cost recommendations and filtering to the Data Factory reservation one. This shows the term and savings Advisor has modelled from your actual usage.

$ az advisor recommendation list --category Cost --query "[?contains(shortDescription.solution, 'Data Factory')]" -o table

Category Impact Resource Group Short Description

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

Cost High - Consider Data Factory reserved instance to save ...

# High impact: Advisor sees a steady data flow baseline worth reserving.

# Next: check the reservation catalogue for the matching SKU and price before buying.

Advisor sizes the recommendation from your real look-back usage. Read the term and quantity it suggests first; that is your baseline, and it is what you size the commitment to, not your peak.

How a Data Factory reservation actually discounts your billdeep dive

A Data Factory reservation is defined by four attributes: the Azure region, the compute type (general purpose or memory optimised), the core count quantity, and the term (one or three years). When you buy it, you are not buying capacity, you are buying a discounted rate. Microsoft states plainly that purchasing reserved capacity does not pre-allocate or reserve any specific virtual machines or clusters. The reservation is a billing entitlement, nothing more.

The discount applies hour by hour against matching usage. Microsoft's own worked example: if you buy a reservation for one hour of 80 cores of memory optimised compute and run a data flow using 144 memory optimised cores for that hour, the reservation discount covers 80 cores and you pay the pay-as-you-go price for the remaining 64. Conversely, if you buy 32 general purpose cores and only use 16 in an hour, the discount covers what you used and the unused reserved core-hours for that hour are gone. This is the use-it-or-lose-it nature of reservations, and it is why sizing to baseline matters: you cannot carry forward unused reserved hours.

Because the entitlement matches on attributes rather than on a named resource, existing factories and newly deployed factories automatically get the benefit, with no assignment step. You choose a scope at purchase, single subscription or shared across the billing account, and any matching data flow usage in that scope is discounted. The reservation is also not locked in for life: within Microsoft's documented limits you can cancel, exchange or refund it through the self-service reservations experience if your usage changes.

What is the impact of leaving the recommendation unactioned?

The direct impact is straightforward: you keep paying the on-demand rate on compute you were always going to run. Every hour your baseline data flows execute at full price is a chunk of discount you could have captured and did not. Unlike a one-off waste, this is a recurring overpayment that compounds for as long as the workload runs unreserved, which for a stable ETL platform can be years.

There is no operational downside to leaving it, which is exactly why it is easy to ignore. Nothing breaks, no pipeline slows down, no alert fires. The cost is purely financial and entirely silent: a steadily higher invoice than the same workload needs to produce. That silence is what lets the overpayment persist quarter after quarter unless someone owns the decision.

The flip side is that the recommendation is cheap to act on and reversible within limits. The discount applies automatically with no engineering change, the saving appears on the next billing cycle, and reservations can be exchanged or refunded under Microsoft's self-service rules if the workload genuinely moves. The asymmetry runs the opposite way to a security finding: here the cost of inaction is a quiet, recurring overpayment, and the cost of action is a single sizing decision.

How do you buy the reservation safely?

Treat this as a sizing decision followed by a purchase, not a configuration change. The order matters: size to baseline, price the exact SKU, then buy at the scope and term you have decided on. Nothing here touches your pipelines.

1. Read what Advisor is actually recommending

Open the Advisor cost recommendation 'Consider Data Factory reserved instance to save over the on-demand costs' and note the term, quantity and estimated saving it has modelled from your look-back usage. This is your starting point: Advisor has already done the baseline analysis, so use its quantity as the anchor rather than guessing.

2. Separate the steady baseline from the spikes

Confirm how many cores, of which compute type, your data flows run every hour versus only at peaks such as month-end. Reserve the floor, not the peak. Because reservations are use-it-or-lose-it per hour, any reserved core-hour you do not consume is forfeited, so leaving the spiky usage on pay-as-you-go is the cheaper choice for that portion.

3. Choose term and scope to match your confidence

Pick a one year term where the forecast is less certain and a three year term only where the baseline is solid, since the longer term carries the deeper discount but the bigger commitment. Choose single-subscription scope to ring-fence the benefit, or shared scope to let any matching usage across the billing account absorb the discount. You can pay upfront or in fixed monthly instalments at the same effective price.

4. Price it, then purchase

Use the reservation catalogue to find the exact SKU for your region and compute type, calculate the price to confirm the saving before you commit, then purchase. The discount applies automatically to matching usage from that point, with no assignment and no pipeline change. Track the realised saving against on-demand on the next bill to confirm the discount is landing.

# Requires the reservations CLI extension (auto-installs on first use) and
# Owner or Reservation purchaser role on the billing subscription.
SUB="00000000-0000-0000-0000-000000000000"   # subscription billed for the reservation
LOC="westeurope"                              # region your data flows run in

# 1. Confirm Advisor is recommending the Data Factory reservation.
az advisor recommendation list --category Cost \
  --query "[?contains(shortDescription.solution, 'Data Factory')].{impact:impact, solution:shortDescription.solution}" \
  -o table

# 2. Find the matching Data Factory reservation SKU in your region.
az reservations catalog show \
  --subscription-id "$SUB" \
  --reserved-resource-type DataFactory \
  --location "$LOC" \
  --query "[].{sku:skuName, term:terms[].termUnit}" -o table

# 3. Price the commitment BEFORE buying (size --quantity to your baseline cores).
az reservations reservation-order calculate \
  --reserved-resource-type DataFactory \
  --sku <skuName-from-step-2> \
  --location "$LOC" \
  --billing-scope "$SUB" \
  --applied-scope-type Single \
  --applied-scope "$SUB" \
  --term P3Y \
  --billing-plan Monthly \
  --quantity <baseline-cores> \
  --display-name adf-dataflow-baseline

# 4. Purchase once the price checks out. The order id is a new GUID you supply.
az reservations reservation-order purchase \
  --reservation-order-id "$(uuidgen)" \
  --reserved-resource-type DataFactory \
  --sku <skuName-from-step-2> \
  --location "$LOC" \
  --billing-scope "$SUB" \
  --applied-scope-type Single \
  --applied-scope "$SUB" \
  --term P3Y \
  --billing-plan Monthly \
  --quantity <baseline-cores> \
  --display-name adf-dataflow-baseline

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider Data Factory reserved instance to save over the on-demand costs'. What is it actually recommending?

Keep learning

Go deeper on how Data Factory reserved capacity is priced, purchased and discounted against your data flow usage.

You can now read the 'Consider Data Factory reserved instance' recommendation for what it is: an offer to pay a discounted rate on data flow compute you already run at full price. You know it is a billing entitlement, not capacity, that the discount applies automatically with no pipeline change, that reservations are use-it-or-lose-it per hour so sizing to baseline matters, and how to price and buy one from the command line.

Back to the library

Data Factory reserved capacity: the savings view

Converting a predictable on-demand line into a discounted commitment, with a knowable payback

This is a pure cost-optimisation recommendation, not a security or reliability one. The question it asks finance is narrow and answerable: you are already spending a steady amount on Data Factory data flow compute at full price, so should you pre-commit to a chunk of it for a one or three year term in exchange for a discount? The compute runs either way. The only variable is the rate.

The economics are a commitment trade, not a free win. Unlike turning off an idle resource, a reservation is money committed up front (or in fixed monthly instalments) for the whole term. The saving is real and applies automatically, but it is conditional on actually using the cores you reserved: a reservation is use-it-or-lose-it per hour, so any reserved core-hour you do not consume is forfeited. The finance job is to size the commitment to the baseline you are confident you will run, not to your peak, so the discount lands without paying for idle reservation.

Because the discount applies automatically to matching usage and requires no engineering change, the payback is unusually clean to model: take the steady baseline core-hours, apply the reserved rate against the on-demand rate Advisor shows, and you have the saving over the term. The realised saving, the discount actually captured against on-demand, is the number that belongs on the bill review, not the headline list price of the reservation.

This lesson is for the finance partner who sees 'Consider Data Factory reserved instance to save over the on-demand costs' on the Advisor cost tab and wants to know whether to act, how big the commitment should be, and how to model the payback. It covers why the saving is real but conditional, how to size to baseline rather than peak, and which number, realised saving against on-demand, belongs on the review.

Fun fact

The reservation you never have to plug in

How a finance partner frames the reservation decision

Priya is the finance partner for the data platform. The Advisor recommendation lands flagged High impact, and the instinct is not to wave through the largest commitment that captures the biggest headline saving. It is to ask what baseline the saving actually rests on. A reservation is money committed for one or three years, so the relevant question is not 'how much could we save at peak?' but 'how many core-hours will we genuinely run, every hour, for the whole term?'

Priya asks the team to separate the steady baseline from the spiky top. The nightly ETL and the always-on debug cluster are a dependable floor of general purpose cores that runs every day; the month-end reprocessing is a spike that comes and goes. The reservation is sized to the floor, because a reservation is use-it-or-lose-it per hour and any reserved core-hour the workload does not consume is simply forfeited. The finance pack reads: 'We commit to the baseline cores we run every hour for a three year term, capture the discount automatically against on-demand, and leave the spiky reprocessing on pay-as-you-go where flexibility is worth more than the discount. Modelled payback is the reserved rate against the on-demand rate Advisor quotes, over the term, and the realised saving is what we will track on the monthly bill.'

Why the reservation belongs on the savings register

The cost model here is a commitment trade with a clean payback, which is rare and worth treating carefully. The saving is the difference between the on-demand rate and the reserved rate, applied to the baseline core-hours you actually run, across the term. Because the discount applies automatically, there is no implementation cost to net off: the modelled saving and the realised saving should track closely as long as the baseline holds.

The risk is not overspend on a service, it is over-commitment. A reservation sized above the baseline forfeits the unused reserved core-hours every hour they go unused, quietly eroding the very saving it was meant to deliver. The finance role is to anchor the commitment to the floor of usage the team is confident about, to favour a one year term where the forecast is less certain and a three year term only where it is solid, and to track realised saving against on-demand on the monthly bill so the captured discount is visible rather than assumed.

What finance owns on the reservation decision

Finance cannot run the purchase command, but it owns the sizing and term call that determines whether the commitment is a clean saving or a partly forfeited one. Three levers.

1. Size to the baseline, not the headline

Anchor the commitment to the floor of usage the team is confident runs every hour, using Advisor's quantity as the starting point. The biggest headline saving comes from the biggest commitment, but any reserved core-hour the workload does not consume is forfeited, so over-sizing buys discount you then throw away. The right number is the dependable baseline, with spiky usage deliberately left on pay-as-you-go.

2. Match the term to forecast confidence

A three year term carries the deeper discount but locks in the commitment for longer; a one year term costs more per core but de-risks an uncertain forecast. Treat the term as a confidence dial: three years where the baseline is solid and unlikely to move, one year where the workload is newer or the roadmap is unsettled. The discount is real either way; the choice is how much certainty you are buying against.

3. Track realised saving, not list price

The number that belongs on the monthly review is the discount actually captured against on-demand, not the sticker price of the reservation. Confirm the reservation is being fully utilised each period; if utilisation drops, the workload has shifted and the reservation should be re-sized, exchanged or refunded within Microsoft's limits rather than left to forfeit hours quietly. Realised saving is the honest measure of whether the commitment is working.

Quick quiz

Question 1 of 5

Advisor flags the Data Factory reservation as High impact with a large headline saving. As the finance partner, what should you size the commitment to?

Keep learning

Go deeper on how Data Factory reserved capacity is priced, purchased and discounted against your data flow usage.

You have finished the finance view of Data Factory reserved capacity. You know the saving is real but conditional: size to the dependable baseline rather than the peak, match the term to forecast confidence, and track the realised discount against on-demand on the monthly bill. Next time an Advisor reservation recommendation lands, you will anchor on the baseline, choose the term as a confidence dial, and watch utilisation so the commitment keeps paying back rather than forfeiting hours.

Back to the library

Data Factory reserved capacity: the headline

A low-risk commitment that lowers the unit price on compute you are already running

Azure Advisor has flagged that a portion of the data integration bill is being paid at the most expensive rate available, the on-demand rate, for compute that runs on a predictable schedule. The recommendation is to commit to that baseline for one or three years in exchange for a discount, exactly the way an organisation negotiates a better unit price for a supply it knows it will keep buying.

The decision is a commitment one, not a technical one. Buying the reservation does not change any pipeline, does not need a release, and the discount applies automatically to matching usage. The risk is the commitment itself: the saving only fully materialises if the workload keeps running at the reserved level for the term, so the call is about confidence in the forecast, not about engineering effort.

Framed correctly this is one of the lower-risk savings on the table. The cores are already being consumed, the discount is automatic, and reservations can be exchanged or refunded within Microsoft's limits if the workload genuinely shifts. The leadership question is simply: how much of this baseline are we confident enough to commit to, for how long?

A short read for the leader deciding whether to approve a one or three year compute commitment. It covers what the reservation actually buys, why it is a low-risk way to lower the unit price on spend you are already incurring, and where the only real risk, committing to a baseline the workload might not sustain, actually sits.

Fun fact

The reservation you never have to plug in

What it looks like when a reservation is sized to confidence, not to the headline number

After a finance review where the cloud bill was flagged as creeping upward, the CFO asked the data platform a direct question: are we paying full price for anything we could pre-buy more cheaply? Azure Advisor had already answered part of it. The Data Factory data flow compute, a steady cost driven by pipelines that had not changed in months, was being paid entirely at the on-demand rate, and Advisor was recommending a reservation against it.

The team's response was not to buy the biggest reservation on offer. They sized the commitment to the baseline they were confident would still be running in three years, the core nightly load, and left the variable reprocessing on pay-as-you-go. The reservation was purchased once, applied automatically, and showed up as a lower compute line the very next billing cycle with no pipeline change and no release. When the CFO asked what the risk was, the honest answer was: only that the baseline workload disappears, in which case the reservation can be exchanged or refunded within Microsoft's limits. That shift, from paying the most expensive rate on predictable spend to pre-buying it at a discount sized to real confidence, is the saving this recommendation delivers.

Why this is a straightforward financial decision

This is the rare cost recommendation with no operational risk and a clear payback. The compute is already running, the discount is automatic, and the only judgement required is how much of a predictable baseline the organisation is confident enough to pre-buy, and for how long. Sized sensibly, it lowers the unit price on existing spend with no change to how anything works.

The cost of getting it wrong is bounded and recoverable: an over-sized reservation forfeits some unused capacity, and reservations can be exchanged or refunded within limits if the workload shifts. The cost of doing nothing is an open-ended overpayment on stable spend. For a workload leadership expects to keep running, approving a baseline-sized reservation is one of the easier savings to sign off.

The leadership move on the reservation

The executive handle is not to approve a number; it is to set the policy that predictable, stable cloud spend should be on commitment pricing rather than on-demand, and to make the sizing a deliberate, owned decision.

1. Make commitment pricing the default for stable workloads

Direct that any predictable, long-running baseline of cloud compute, of which Data Factory data flows are one example, should be reviewed for reservation or savings-plan coverage rather than left on the on-demand rate. The standing question at the cost review becomes: what stable spend are we still paying full price for, and why have we not committed it?

2. Approve to confidence, with a term to match

Approve a commitment sized to the baseline the team is genuinely confident about, and let the term reflect that confidence: longer for solid forecasts, shorter where the workload is newer. The goal is not to maximise the headline discount; it is to capture the saving on spend you are sure about while keeping flexibility where you are not.

3. Ask for realised saving as the proof

The proof the decision worked is not the projected saving at purchase; it is the realised discount on the bill and a healthy reservation utilisation figure each period. Ask for both at the cost review, and treat a falling utilisation as the signal to re-size, exchange or refund within Microsoft's limits rather than keep forfeiting unused hours.

Quick quiz

Question 1 of 5

At a cost review you ask why a stable workload is paid at the on-demand rate. What end state are you steering towards?

Keep learning

Go deeper on how Data Factory reserved capacity is priced, purchased and discounted against your data flow usage.

Two takeaways. Predictable, long-running compute like Data Factory data flows should be on commitment pricing, not the on-demand rate, and reviewing for that should be routine rather than reactive. And this is a low-risk saving: the compute already runs, the discount is automatic, the only real risk is over-committing beyond a baseline you are confident about, and that is bounded and recoverable within Microsoft's exchange and refund limits.

Back to the library

Part of the learning path Lock in Azure commitments

Buy Azure Data Factory reserved capacity

Data Factory reserved capacity: the basics

The reservation you never have to plug in

Reading the Advisor recommendation before you commit

How a Data Factory reservation actually discounts your billdeep dive

What is the impact of leaving the recommendation unactioned?

How do you buy the reservation safely?

1. Read what Advisor is actually recommending

2. Separate the steady baseline from the spikes

3. Choose term and scope to match your confidence

4. Price it, then purchase

Quick quiz

Keep learning

Data Factory reserved capacity: the savings view

The reservation you never have to plug in

How a finance partner frames the reservation decision

Why the reservation belongs on the savings register

What finance owns on the reservation decision

1. Size to the baseline, not the headline

2. Match the term to forecast confidence

3. Track realised saving, not list price

Quick quiz

Keep learning

Data Factory reserved capacity: the headline

The reservation you never have to plug in

What it looks like when a reservation is sized to confidence, not to the headline number

Why this is a straightforward financial decision

The leadership move on the reservation

1. Make commitment pricing the default for stable workloads

2. Approve to confidence, with a term to match

3. Ask for realised saving as the proof

Quick quiz

Keep learning

Related cost lessons