# Azure VPN Gateway

> Azure VPN gateways bill per hour by SKU for every hour they exist, whether a single packet crosses the tunnel or none. Gateways built for decommissioned offices or expired POCs keep billing until deleted, so ZopNight discovers each one via Resource Graph with SKU and connection state and reviews idle gateways through connection metrics.

Source: https://zop.dev/integrations/azure/azure-vpn-gateway
Updated: 2026-08-19

---

VPN gateways provide site-to-site and point-to-site connectivity into a VNet, billed hourly by SKU. Gateways for decommissioned offices or expired POCs keep billing until deleted.

## Gateway-hours accrue with or without traffic

A VPN gateway's price is its SKU multiplied by hours of existence. The SKU fixes throughput, tunnel count, and the hourly rate; nothing about the meter responds to whether the tunnels carry anything. A gateway serving fifty branch offices and a gateway whose one office closed in 2023 generate the same charge per hour. VPN gateways also take a long time to create, often tens of minutes, which nudges teams toward keeping them "just in case," a rational instinct that turns directly into standing spend.

## Connection state and idle-tunnel review

Discovered via Azure Resource Graph with SKU and connection state. Cost Management billing attributes spend, and connection metrics support idle-gateway review: a gateway whose connections show no meaningful traffic across the review window is a deletion candidate, not a scheduling candidate. VPN gateways are discovery and cost visibility only. Azure offers no stop or pause for a gateway, so unlike a VM there is no nightly saving to capture. The decision is binary: needed, or deletable.

## Dead offices, live gateways

The waste patterns here are organizational as much as technical. Site-to-site tunnels outlive the sites: offices close, providers change, a firewall migration moves the tunnel elsewhere. The Azure-side gateway remains, billing hourly against a peer that no longer answers. Proof-of-concept and disaster-recovery environments show the second pattern: a gateway stood up to test connectivity or satisfy a DR checklist, never dismantled after the exercise. A third is redundancy left doubled: an old gateway kept during a migration to a new one, past the point anyone remembers which is which.

## VPN gateway pages in the portal

Azure portal → Virtual network gateways lists gateways with type, SKU, and VNet; opening one shows its Connections blade with each tunnel's status and data transferred. Connections sitting at zero bytes over a long window are the manual confirmation of what ZopNight's idle-gateway review flags from metrics.