Where can I track Vnet Data Gateway costs?

[mccloudy]

Vnet Data Gateways went GA but I still can't see the costs. Where exactly are they? 

[Anonymous]

Hi @mccloudy ,

The VNet Data Gateway is billed as an additive premium infrastructure charge, associated with a Premium or Fabric capacity. This means that it has its own meter and incurs a bill that is consistent across and in addition to all artifacts. The total bill of running an artifact through the VNET Data Gateway is the sum of the Artifact Charge and the VNET Data Gateway Charge.
The VNET Data Gateway Charge is proportional to your usage of the VNET Data Gateway; usage is defined as uptime, or anytime the VNET Data Gateway is on. A single VNET Data Gateway uses two cores. The Consumption Unit (CU) consumption rate is 2x. Therefore, the price is calculated as follows:
Price=2x(CU Consumption rate)×2 cores (per VNET Data Gateway)×$0.18(Pay as You Go price for one CU per hour)=$0.72 per VNET/hour.
Please note that there’s no cost associated with setting up a VNET data gateway. Billing starts when your first query runs or you run a test connection. To reduce costs, you can actively manage the time to live on your VNET data gateway in settings.

For original post,you may refer to Virtual network (VNET) data gateways business model | Microsoft Learn

Best regards.
Community Support Team_Caitlyn

[mccloudy]

@Anonymous v-xiaoyan-msft Thank you for the explanation. I'm having trouble finding where these costs can be tracked. Is it somewhere in my subscription? I see lots of new, nonbillable vnet data gateway CU in the capacity metrics app and I'm hoping they don't turn to billable there.. 

Is there any way to calculate how many gateways we really need to keep refreshes from failing? Thanks again. 

[basland]

Apologies for hijacking this thread, but I have a very related question. 

The additional Vnet costs, do they count against the existing Compute Units that are available, or do we pay additional dollars on top of the existing capacity unit?

Second question - when calculating the time, is the Vnet gateway on 24/7 or does the meter only run when we actually use the gateway?

[mccloudy]

@basland From what I understand.... Take it with a grain of salt because this service is new. You will see two new Operations in the Fabric Capacity Metrics report drill down details. One is called Vnet Data Gateway Uptime. This is for the uptime of the gateway servers. The other is called Vnet Data Gateway. This is for the Power Query CU. If you didn't use Vnet Data Gatways, the Power Query CU would be combined with the Analysis Services CU in the Dataset Refresh Operations.. 

To reduce cost, you don't want to leave your Vnet data gateway servers up 24/7 if you can avoid it. They can be set to auto shutdown after 30 min.

[basland]

Thanks for the explanation! 

Will this already work for Fabric Data Factory Pipelines as per your knowledge? 

[mccloudy]

@basland I do not use data factory pipelines. Do you use them to trigger PBI data set refreshes? It's the PBI dataset refresh that spins up the vnet data gateway for me.

[dbeavon3]

This vnet gateway stuff is now the third most expensive background operation in our capacity.
It is costing approximately $1000 a month, for a minimal number of refreshes.

We never would have assumed it would be so expensive.  For years while the managed vnet gateway was in preview, we had used it with no additional cost.  

Has anyone considered the cost/benefit of using this managed gateway, instead of just hosting your own in an Azure VM?  I think Azure VM's can be half the price ($500/month), and you don't have to worry about adding every new refresh to the schedule (ie. won't be "nickled-and-dimed").  Aside from periodic maintenance of the PaaS resource in azure, what other considerations would come into play?  This seems like a very simple way to save ~$6 grand a year or so. 

For someone who familiar with Azure, it isn't too hard to provision a VM and install a gateway.  I suppose there are fault tolerance features and auto-scaling features that may be missing, so you have to factor in the risk/rewards.  In general I find Power BI to be pretty unreliable; and the VM which the gateway runs on is probably NOT one of the weakest links so the lack of fault tolerance there wont greatly increase the overall outages that users might experience.  Any feedback would be welcome.