Idle virtual network gateways: the basics
Why does a gateway with no connections still cost money?
A virtual network gateway is the resource that terminates a site-to-site VPN, a point-to-site VPN or an ExpressRoute circuit at the edge of an Azure virtual network. Unlike a virtual machine, you cannot stop or deallocate a gateway to pause its bill. It is a managed, always-on resource: from the moment it is created it runs reserved compute in the chosen SKU, and Azure charges a fixed hourly fee for every hour it is provisioned, a partial hour billed as a full one. That charge is the same whether the gateway is carrying live traffic or sitting completely idle with nothing connected to it.
Azure Advisor surfaces exactly this waste in its cost recommendations under the title 'Reduce costs by deleting or reconfiguring idle virtual network gateways'. Advisor flags a gateway that has had no connections defined against it for an extended period, typically more than 90 days, because a gateway with zero connections cannot be doing any useful work yet is still drawing its full hourly rate. The same recommendation covers both VPN gateways and ExpressRoute gateways, and it pairs with the related recommendation to remove unprovisioned ExpressRoute circuits.
Most idle gateways are leftovers, not deliberate spend. A proof of concept that was never torn down, a migration whose on-premises side was decommissioned while the Azure gateway was left behind, a disaster-recovery design that changed, or an oversized SKU chosen 'to be safe' for a link that never carried the traffic to justify it. The work is to list every gateway in the estate, see which ones have no connections, confirm with the owning team that they are genuinely unused, and then delete the dead ones or right-size the over-provisioned ones.
In this lesson you will learn how Azure bills a virtual network gateway, how to find every gateway in a subscription that carries no connections, and how to delete the genuinely dead ones or right-size the over-provisioned ones without disrupting a link that is quietly still in use. It follows the Azure Advisor recommendation 'Reduce costs by deleting or reconfiguring idle virtual network gateways' and the matching 'Virtual Network Gateways' cost workbook query.
The gateway you cannot switch off
Engineers used to running virtual machines often assume they can deallocate a gateway overnight or over a quiet weekend to save money, the way they would stop a VM. They cannot. A virtual network gateway has no stopped or deallocated state: it is either provisioned and billing, or deleted and gone. There is no pause button. That single design fact is why idle gateways are such a reliable source of silent waste: the only way to stop the meter is to delete the resource, so a gateway left behind after its purpose ended keeps charging its full hourly rate, indefinitely, until somebody notices and removes it.
Finding idle gateways across a subscription
Priya runs the platform team at a company that has migrated several workloads to Azure over three years. Advisor's cost tab shows a handful of idle virtual network gateway findings, and the monthly cost report has a stubborn networking line nobody can fully explain.
Rather than act on the Advisor findings one at a time, Priya starts by listing every gateway in the subscription alongside its type and SKU, then checks which ones have any connections defined, so the genuinely dead gateways are separated from the ones still carrying a live link before anything is deleted.
List every virtual network gateway in the subscription with its type and SKU. These are the resources billing by the hour.
Every gateway in this list bills its full hourly rate continuously. The type and SKU set the rate; the next check decides which are doing any work.
How Advisor decides a gateway is idledeep dive
A virtual network gateway is a 'Microsoft.Network/virtualNetworkGateways' resource. Its 'gatewayType' property is either 'Vpn' or 'ExpressRoute', and its 'sku.name' (for example 'Basic', 'VpnGw1' through 'VpnGw5', or the ExpressRoute 'ErGw' tiers) sets the hourly rate. The connections that run over it are separate resources, of type 'Microsoft.Network/connections', that reference the gateway. A gateway with no connection resource pointing at it is, by definition, carrying no traffic: it is fully provisioned and billing, but unused.
Advisor's 'Reduce costs by deleting or reconfiguring idle virtual network gateways' recommendation works on exactly that signal. It looks for gateways that have had no connections defined against them for an extended period, typically more than 90 days, and surfaces them as a cost finding because a gateway that has carried no connection for three months is almost certainly a leftover rather than a link about to come online. The matching 'Virtual Network Gateways' cost workbook runs the same idea as a query you can read across a subscription or management group, listing every gateway and whether it has any associated connections.
Because the billing is purely a function of the resource existing, the remediation is equally clean: there is no usage metric to interpret and no threshold to argue about. Either a gateway has a live connection and earns its hourly rate, or it does not and the rate is pure waste. The only nuance is that the gateway resource cannot be deleted while any connection resource still references it, so removing a gateway means deleting its connections first, even if those connections are themselves dead.
What is the impact of leaving idle gateways running?
The direct impact is continuous, recurring spend for nothing in return. A gateway charges its full hourly rate every hour it exists, so an idle gateway is a fixed cost that recurs around the clock with no offsetting value. Because there is no deallocated state, the charge never pauses on its own: it accrues until someone deletes the resource. A single idle higher-tier or ExpressRoute gateway can quietly cost more over a year than many teams would expect for a resource carrying no traffic.
The second-order impact is that idle gateways hide the true shape of connectivity spend. When the networking line on the cost report mixes live gateways with dead ones, it is hard to tell whether the bill reflects real demand or accumulated leftovers, which makes forecasting and chargeback less trustworthy. Clearing the idle gateways means the remaining connectivity cost maps to connectivity actually in use, which is the baseline every other network cost decision should be measured against.
There is also a small but real management cost. Every gateway in the estate is a resource that has to be patched, monitored and reasoned about during audits and migrations. An idle gateway adds that overhead while delivering nothing, so removing it simplifies the estate as well as the bill. Unlike many cost controls, there is no resilience or performance downside to weigh here: a gateway carrying no connections protects nothing, so removing it costs nothing operationally.
How do you remove idle gateways safely?
Work this as one loop across the estate rather than chasing individual Advisor findings. The order matters: confirm a gateway is genuinely unused, and delete its connections, before you delete the gateway itself, so you never drop a link that was quietly still in use.
1. Inventory every gateway and its connections
List every virtual network gateway in the subscription with its type and SKU, then list the connections defined against each one. A gateway with zero connection resources is the prime candidate. Treat this inventory as the source of truth rather than the raw Advisor count, because the inventory shows you the SKU, which sets the saving, and the connection state, which decides whether it is safe to remove.
2. Confirm idle is not 'idle on purpose'
For each gateway with no connections, ask the owning team whether it is genuinely unused or kept deliberately as a warm standby for a planned cut-over or a disaster-recovery path. Most will be leftovers from completed migrations or abandoned proofs of concept. The deliberate standbys are the exception: record them with an owner and a reason, and leave them alone.
3. Delete connections, then the dead gateways
A gateway cannot be deleted while any connection resource still references it, so delete the connections first, then the gateway. For the genuinely dead gateways this stops the hourly charge immediately and in full. Prioritise the higher-tier and ExpressRoute gateways, because they carry the largest hourly rate and therefore the largest saving.
4. Reconfigure rather than delete where a link is real but oversized
Some gateways are not idle but over-provisioned: a high SKU chosen 'to be safe' for a link whose throughput never justified it. Where the connection is genuinely needed, the saving comes from moving to a smaller SKU rather than deleting. Changing the SKU is a resize on the existing gateway, so plan it in a maintenance window because it briefly interrupts the connection.
# Step 1: find VPN/ExpressRoute gateways in this resource group, with SKU.
az network vnet-gateway list --resource-group net-sandbox \
--query "[].{name:name, type:gatewayType, sku:sku.name}" -o table
# Step 2: for a candidate gateway, list the connections defined against it.
# Zero rows means the gateway carries no connections and is billing for nothing.
az network vpn-connection list --resource-group net-sandbox \
--vnet-gateway vpn-poc-legacy -o table
# Step 3: a gateway cannot be deleted while a connection references it,
# so delete any leftover dead connections first (skip if step 2 was empty).
for conn in $(az network vpn-connection list \
--resource-group net-sandbox --vnet-gateway vpn-poc-legacy \
--query "[].name" -o tsv); do
az network vpn-connection delete --resource-group net-sandbox --name "$conn"
done
# Step 4: delete the idle gateway. This stops the hourly charge in full.
az network vnet-gateway delete --resource-group net-sandbox --name vpn-poc-legacy
# Reconfigure instead of delete when the link is real but the SKU is oversized:
# az network vnet-gateway update --resource-group net-prod \
# --name vpn-prod-hub --sku VpnGw1 # resize briefly interrupts the connectionQuick quiz
Question 1 of 5Why does a virtual network gateway with no connections still appear on your Azure bill?
You scored
0 / 5
Keep learning
Go deeper on how Azure prices virtual network gateways, how Advisor surfaces idle ones, and the exact steps to delete a gateway safely.
- Cost recommendations - Azure Advisor The full list of Advisor cost recommendations, including idle virtual network gateways.
- VPN Gateway pricing How gateways are billed by the hour per SKU, plus egress data transfer.
- Delete a virtual network gateway: portal The order to delete a gateway and its dependent connection resources.
You can now treat virtual network gateways as a tracked cost rather than background networking noise: inventory every gateway with its type and SKU, check which carry no connections, confirm the dead ones with their owners, delete the connections and then the gateways to stop the hourly charge, and right-size the live but oversized ones instead of deleting them. Because a gateway has no deallocated state, deletion is the only way to stop the meter, and the saving recurs for as long as the gateway stays gone.
Back to the library