Virtual network gateway takes most of the Budget

I’ve noticed that Virtual network gateway is the resource with most of my monthly Costs.

And I don’t even know what it does.

I do have a VM that I turn on/off occasionally with 2 disks.

But what is Virtual network gateway? And why is it so expensive? ($350 a month)
This Virtual Network Gateway costs twice as the VM.

What can I do about it? Can I turn it off?

Something you haven’t yet answered is WHO built out your Azure environment? These services don’t just build themselves. Whoever built it can explain better than all of us taking guesses because you can’t describe the rest of the architecture.

You may not use for YOUR VPN, but this is most likely in use as a site to site VPN.

Before you delete it like others have suggested, you need to ascertain if it is being used to connect your on-prem LAN to Azure.

Quickest way is to search of Local Gateway and have a look if anything is connected. If so, you have a S2S VPN and should not delete your gateway.

Delete it, and there goes your connectivity from the office.

You’ve said yourself that you’re a data guy… Where’s your infrastructure team?

Idk why everyone is suggesting to delete it without checking, but check if there’s a tunnel built between it and something else. This is fairly easy to do from Azure Portal. There must be some reason it exists that might be beyond your knowledge of how the systems are connected.

  • Virtual network gateways are VPN connectivity solutions
  • If you’re able to access this VM from your company network or LAN, then you’re probably using the VNG. If you only access this VM (and its services) via the Public IP, then odds are the VNG does nothing.
  • In the Azure Portal search box, type “Virtual Network Gateway”. Once the search completes, you should see the Virtual Network Gateway resource link. Go there.
  • Determine how many VNGs you have. They are offered in a series of tiers and generations with varying costs.
  • Under the VNG(s), review the “Connections” blade. If there are connections present, destroying this VNG could have consequences. If there are no connections present, it is not likely to be doing anything. Also review Point-to-Site configuration, just in case.

Only you and your org can decide if this resource is necessary. Any destructive changes cannot be undone so investigation is necessary. There’s not much of a blind “try and see” on/off switch here.

It’s essentially serving as a VPN, most likely between your office location and your cloud tenant, presumably your office location has an IP range, and a network engineer wanted to extend this IP range to make your Azure servers reachable from your office within the same IP range.

The question you need to answer is do you need a private tunnel between these servers and your office, if they’re constantly communicating with a service you have on-prem, most likely the answer is yes.

I think the reasons your cost are so skewed is because you appear to only have a single VM in Azure, think of it like building an entire mechanics shop just because you want to change the oil on your car at home occasionally. This cost might not seem as high if you had more servers. When you’re working with cloud you have the concept of a “Landing Zone” which in short is the minimum amount of infrastructure needed to support a workload, in most cases Network resources, whereas on-premise, most of your network costs are already realized and only increase if you’re doing a major expansion.

but if you were to get rid of the VNG, that means the only way to access your servers is via the public internet, you can enable Network Security Groups on the interfaces for these servers, and even do things like restrict what IPs can connect to them, but generally security wise this could be an issue depending on how sensitive the data on your Azure VMs
is, it’s also possible your VNG is provisioned for a higher performance SKU than is required if the SKU is anything higher than “Basic” you should look into just how much traffic is going across, however in my experience sometimes Basic doesn’t support the customization needed to connect to your remote site such as custom IP Sec policies.

Do you have enabled Just In Time policy?
Turn off all unnecessary stuff, start stop vm manually

It’s for private connectivity ( site to site of user remote vpn) …
Do you access VM using private IP? Or the VM talk to any component on the DataCenter for example?

What is the SKU? This price looks like a VPNGW2.

Go into the vpn gateway and check if there are any p2s or s2s connections. You can also check the metrics to see if there are is any data going through the gw if it’s 0 bytes In and 0
Bytes out you’re go If there are non then you can delete it. Before you delete it however get a terraform export of the configuration
of the vpn gateway. That way you can get someone to rebuild it if needed.

I’ve used this before, very useful tool.

According to your comments the VPN gateway is NOT used by you to manually connect to the VM, but it DOES have a Site-to-Site connection set up.

The question is now whether there are some other services that make use of the VPN Gateway, that you’re not aware of.

Maybe something is syncing a local database with the one that runs on the VM, through a VPN (how it should be done)? Maybe the VPN gateway was initially set up so you wouldn’t connect to the VM using its external IP address (which is to be avoided), but you didn’t get the memo?

We can’t tell without further information.

I found your thread because I hit the same issue. $192 a month with the actual ZERO traffic in Virtual Network Gateway. This is just the health / availability checks. In my case I figured I’m not needing / using it. Configured it “just in case”, but the cost is prohibitively expensive for what it does.

If you’re new to azure and not part of a support desk (ie: you’re just playing & learning), then you enabled an option during the creation of the vm (actually, probably the vnet) and you can safely delete the vpn gateway because it’s not in use.

Chances are its configured to establish a private connection to your onsite location so you can use the recovery services vaults to backup physical machines.

Could be wrong. Just guessing.

Use the Resource Explorer and check when it was deployed and by who.

There are many levels of vnet gateways and it looks like you are maybe paying for vpngw2. Are you using this for point to site or are all of your systems in a vnet that you otherwise connect to site to site? Just need more information to know whats going on here.

Is ur VM in a different region than the disk?

hired some company that cold called the right person, did not understand what we were implementing, and now hate “the cloud” because it’s “so expensive”

This may be close if my anecdotal experiences continue being correct.

Who built it is no longer available. I am trying to figure out myself.

I have a small team of Data Analysts. We don’t have intfrastructure team (yet :slight_smile:
We use Azure for VM with SQL Server.
Thanks for the tips, I’ll try to check