Azure Virtual Network
Does ZopNight manage Azure Virtual Network?
Azure virtual networks are free to create, and the charges hang off what runs inside them: VNet peering bills per GB in each direction, and egress traffic meters separately. ZopNight discovers every VNet via Resource Graph and uses it to anchor the topology graph linking VMs, subnets, NICs, and gateways.
Rules that fire on Azure Virtual Network
No active rule family targets Azure Virtual Network today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and topology only. |
Virtual networks are the fundamental network boundary in Azure, hosting subnets, NICs, and peerings. VNets are free themselves but anchor peering, gateway, and egress charges and define the topology ZopNight maps.
A free boundary that anchors paid traffic
Creating a VNet costs nothing: there is no hourly meter, no per-VNet charge, and no fee for the address space it claims. The money moves the moment traffic crosses its edges. VNet peering bills per gigabyte in both directions, egress to the internet meters separately, and every gateway attached to the network, VPN or ExpressRoute, runs its own hourly charge. So while the VNet row on an invoice is blank, the network design it encodes decides several real line items. A hub-and-spoke layout with chatty spokes, for example, pays peering on every hop that a flatter design would avoid.
How ZopNight maps VNet topology
Discovered via Azure Resource Graph and used to build the network topology that connects VMs, subnets, and gateways for blast-radius and dependency views. When ZopNight evaluates stopping a machine or flags an idle gateway, the VNet graph is what shows which resources sit behind the same boundary and would feel the change. One known enrichment gap: placing a VM inside its VNet requires NIC join data, so VNet placement of VMs depends on the NIC linkage being present.
VNet hygiene worth a look
Because deletion is blocked while any resource remains inside, VNets almost never disappear. Abandoned environments tend to leave an empty or near-empty VNet behind, still holding address space and sometimes still linked to private DNS zones or peerings. Reviewing VNets with few or no attached NICs is a quick way to find whole environments that were half-torn-down. Peerings that connect to networks nobody uses anymore are a second pattern: the link itself is easy to forget, but any residual traffic across it keeps metering.
Locating virtual networks in the Azure portal
Azure portal → Virtual networks lists every VNet with its address space, resource group, and subscription. Opening one shows its subnets, peerings, and connected devices, the same relationships ZopNight assembles automatically across every subscription it can see.