57% increase in Synapse SQL Pool costs after enabling Private Links

Question

57% increase in Synapse SQL Pool costs after enabling Private Links

Michael Clemans 0

Hello,

I would like to ask for advice on how to optimize the costs of our Azure Synapse SQL Pool.

We recently migrated our pipelines, connectors, and other components from an old Azure Synapse Workspace to a new one in order to use Private Links. Since completing this migration, we have observed a significant increase in the SQL Pool costs.

The cost has increased by approximately 57% compared to the previous workspace, even though our workload and expected usage have remained essentially the same.

I have attached screenshots showing the cost values (daily) before and after the migration.

Is there any configurations, metrics, or best practices that we should review to identify the cause of this increase and optimize the SQL Pool costs in the new workspace?

Any suggestions or recommendations would be greatly appreciated. Thank you!

Before: User's image

After: User's image

Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-20T21:05:58.91+00:00

Hi @Michael Clemans ,

Compute rate for a Synapse dedicated SQL Pool (DWU-hours) does not change when you enable Private Link the network path is free, the compute price is identical between the two workspaces. A 57% jump on the SQL Pool line item almost always comes from one of these, in order of likelihood:

New workspace is running at a higher DWU than the old one. Check: Synapse Studio → Manage → SQL pools → open the pool → confirm current Performance level (DW100c, DW500c, DW1000c…). Compare to old workspace's setting. Even one step up (DW500c → DW1000c) is a ~2x cost jump.

Auto-pause was on before, off now (or pause schedule not migrated). Check: SQL pool → Overview → Status (Online/Paused history) and scale/pause automation (Runbook, Logic App, Data Factory pipeline). If the old workspace paused the pool overnight/weekends and the new one runs 24×7, that alone explains ~50–60% more DWU-hours.

Both old and new pools were live during migration overlap and both got billed for that window. Filter Cost Analysis by resource name to confirm the old pool is fully paused/deleted after the cutover date.

Reservation / savings plan didn't carry over to the new pool's resource ID. Check: Cost Management → Reservations → Utilization. A reserved-capacity discount is scoped to the specific SQL pool resource ID; a new workspace = new resource ID = discount doesn't apply until you re-scope or exchange.

Storage / geo-redundant backup grew. Not usually a 57% mover, but worth ruling out in Cost analysis (filter Meter category = Storage vs Compute).

Do this to pinpoint :

Cost Management + Billing → Cost analysis → scope to the subscription → Group by = Meter (not Service). You'll see exact SKU lines (e.g., "DW1000c" vs "DW500c") and hours consumed. That instantly tells you if it's a DWU-level change or a runtime-hours change.

If the meter name is higher → DWU was scaled up → scale back down.

If the meter name is same but hours are higher → auto-pause is off → re-enable pause schedule.

Private Link itself is not the cause. It changes networking, not compute pricing.

If you share the meter name + hours from both months (Cost analysis → Group by Meter), I can point at the exact difference.
Michael Clemans 0 Reputation points

2026-07-21T18:18:37.6333333+00:00

Thank you for the detailed suggestions.

I can confirm the following:

We have not increased the DWU level. The dedicated SQL Pool remains configured at DW500c, exactly the same as in the previous Synapse workspace.

The SQL Pool has always been running 24/7. There was no auto-pause before the migration, and there is no auto-pause now. We also have 500 DWUs reserved, so we are not paying Pay-As-You-Go compute charges. We pay the fixed monthly cost associated with the 500 DWU reservation.

The cost figures I shared are daily costs, not monthly totals. It has now been almost two months since the migration, and the daily SQL Pool cost has remained consistently higher. Because of this, it does not appear to be a temporary overlap where both the old and new SQL Pools were running simultaneously.

The Reserved Capacity is correctly applied to the new SQL Pool. We have already verified this, and the reservation shows 100% utilization, so the reservation is being fully consumed by the new pool.

We did experience geo-redundant storage cost issues shortly after the migration, but those have already been resolved. The daily cost increase shown in my screenshots is not related to geo-redundant storage, but specifically to the SQL Pool compute costs.

Given the above, we are still trying to understand what could explain the approximately 57% increase in the daily SQL Pool costs after migrating to the new Synapse workspace, even though the DWU level, reservation, and workload remain unchanged.

3 answers

Your answer

Michael Clemans 0 Reputation points

2026-07-21T18:18:37.6333333+00:00

Thank you for the detailed suggestions.

I can confirm the following:

We have not increased the DWU level. The dedicated SQL Pool remains configured at DW500c, exactly the same as in the previous Synapse workspace.

The SQL Pool has always been running 24/7. There was no auto-pause before the migration, and there is no auto-pause now. We also have 500 DWUs reserved, so we are not paying Pay-As-You-Go compute charges. We pay the fixed monthly cost associated with the 500 DWU reservation.

The cost figures I shared are daily costs, not monthly totals. It has now been almost two months since the migration, and the daily SQL Pool cost has remained consistently higher. Because of this, it does not appear to be a temporary overlap where both the old and new SQL Pools were running simultaneously.

The Reserved Capacity is correctly applied to the new SQL Pool. We have already verified this, and the reservation shows 100% utilization, so the reservation is being fully consumed by the new pool.

We did experience geo-redundant storage cost issues shortly after the migration, but those have already been resolved. The daily cost increase shown in my screenshots is not related to geo-redundant storage, but specifically to the SQL Pool compute costs.

Given the above, we are still trying to understand what could explain the approximately 57% increase in the daily SQL Pool costs after migrating to the new Synapse workspace, even though the DWU level, reservation, and workload remain unchanged.

Answer 1

Hi, @Ganesh Chelluri

Thank you for the detailed explanation. That makes things much clearer.

Based on your explanation, I now understand that the increases in Data Movement, Pipeline Activity, and External Pipeline Activity are expected as a consequence of moving to Private Link and the Managed VNet Integration Runtime.

I have now gathered the monthly cost data around the migration to perform a more thorough comparison. From what I found:

Data Movement costs approximately doubled.
Activity Orchestration remained the same
Pipeline Activity and External Pipeline Activity both increased dramatically, going from almost negligible costs before the migration to around USD 600 each afterward.

Given these results, is there any additional optimization you would recommend to further reduce these costs?

Also, regarding your suggestion to enable TTL on the Managed VNet Integration Runtime, I wasn't able to find that setting in our Synapse workspace. We have the default AutoResolveIntegrationRuntime configured as a Managed VNet Azure Integration Runtime, along with a Self-hosted Integration Runtime, but I don't see any TTL option exposed in the Managed VNet IR configuration. Could you clarify where this setting can be configured in Synapse, or were you referring to Azure Data Factory?

Thank you again for your help.

Answer 2

Given your follow-up, Private Link is not a credible cause of a dedicated SQL pool compute increase. Microsoft bills dedicated SQL pool compute by DWU blocks and running hours; reserved capacity only changes how matching compute usage is priced. With DW500c running 24/7 and the reservation fully applied, the underlying compute quantity should be unchanged.

Compare both periods using a Cost Details export, not only the Cost Analysis chart. Use the same metric—Actual cost or Amortized cost—and filter to the SQL pool resource. Compare PricingModel, ChargeType, Quantity, EffectivePrice, MeterName, ReservationId, and ProductOrderId. Amortized cost reallocates the reservation’s prorated daily cost to the resource, while Actual cost records the reservation purchase separately, so mixing these views can create a misleading resource-level increase.

If Quantity and EffectivePrice show a 57% difference, open a billing support request with both CSV extracts and the reservation order ID; Microsoft must reconcile the rated usage.

Answer 3

Ravi Kiran Pagidi 170

Hi Michael,

From the screenshots, the increase does not look like it is coming mainly from the SQL Pool itself.

In the “After” screenshot, most of the new/high charges appear under:

Azure Synapse Analytics Pipelines - Azure Hosted Managed VNET IR
Managed VNet IR data movement / pipeline activity / external pipeline activity
Virtual Network Private Link
Private endpoint data processed

The SQL Pool line in the screenshot appears to be very small (< $0.01). So I would first separate SQL pool cost from Synapse pipeline / Managed VNet IR / Private Link cost in Cost Analysis.

Please check:

In Cost Analysis, group by Meter and Product.
Filter only the SQL pool resource and confirm whether DWU/vCore usage actually increased.
Compare old vs new pipeline runs:
- number of activity runs
  - copy activity duration
    - DIU usage
      - data volume moved
        
        integration runtime used
        
        Check whether pipelines that previously used normal Azure IR or Self-hosted IR are now using Azure Hosted Managed VNet IR.
        
        Review Private Link charges separately. Private endpoints have hourly and data processed charges.

For optimization:

Use Managed VNet IR only where private connectivity is required.
Keep Self-hosted IR for sources already reachable through your private network, if that is cheaper for your workload.
Avoid moving large volumes through private endpoints unless required.
Tune copy activity parallelism/DIU and avoid unnecessary data movement.
Review whether any pipeline frequency or retry behavior changed during migration.

Michael Clemans 0 Reputation points

2026-07-21T18:41:58.3233333+00:00

Thank you for pointing that out. You are correct.

The SQL Pool cost shown in Cost Analysis is minimal because it is covered by our reserved capacity, which we pay for on a fixed monthly basis. Therefore, the daily SQL Pool compute charge shown in Azure Cost Analysis is expected to be close to zero.

As you mentioned, the increase is actually coming from the Pipelines, Managed VNet Integration Runtime, and data movement related costs. It was an oversight on my part to state that only the SQL Pool costs had increased.

To better illustrate the issue, I have attached a new screenshot comparing the daily costs before and after the migration, using two Mondays as the comparison points to ensure a similar workload.

Before:

After:

To the best of my knowledge, our team has not increased the number of pipeline activities, the amount of data being copied, or the overall scale of our operations since the migration. What is still not clear to me is whether using Private Links can itself increase the cost of pipeline activities or data movement, even when the workload remains essentially the same. Could you clarify whether Private Links introduce any additional charges or overhead that would explain this increase?
Ganesh Chelluri 190 Reputation points Microsoft External Staff Moderator

2026-07-24T23:13:40.4666667+00:00
Hi @Michael Clemans ,

Good news you've found it. Yes, moving to Private Link can increase pipeline/data-movement cost, not because Private Link changes compute prices, but because it forces your pipelines onto a Managed VNet Integration Runtime (Azure IR + managed VNet). That runtime bills very differently from a regular Azure IR:

Pipeline & External activities are the big driver. - On a normal Azure IR these are almost free (fractions of a cent per hour). - On a Managed VNet IR they're billed at a much higher flat per-hour rate per concurrency bucket (up to 50 concurrent pipeline activities / up to 800 external). So the SAME pipelines, same workload, cost far more just by running on the managed VNet IR.

Copy activities add queue/startup time when TTL is OFF. - DIU-hour rate is identical to Azure IR, BUT with no Time-To-Live, every copy activity spins up compute and you're billed its queue/startup time (rounded up, ~1 min each). Many small copies = lots of billed startup minutes. - Fix: enable TTL on the Managed VNet IR so warm compute is reused and per-activity queue time disappears. This is usually the single biggest saving.

Managed Private Endpoints have their own charge. - ~$0.01/endpoint/hour + data-processed charge on BOTH inbound and outbound (~$0.01/GB). High-volume copies through private endpoints add up separately from the IR. To confirm and fix: - Cost Analysis → Group by Meter → filter the two Mondays. You'll see the increase sitting in "Pipeline Activity", "External Pipeline Activity", and "Private Link data processed" meters not SQL Pool. - Enable TTL on the Managed VNet IR (set a sensible DIU count + TTL window). - Only route through Managed VNet IR / private endpoints where private connectivity is actually required; keep other sources on standard Azure IR or Self-hosted IR. - If you want, share the Meter names + hours from both Mondays and I'll point at the exact delta. So: workload unchanged, but the runtime type changed that's the 57%.