# Azure Subnet

> Azure subnets carry no charge of their own. A subnet is 1 address-space slice whose cost story is the NSGs, route tables and service endpoints attached to it plus the billable resources placed inside it. ZopNight discovers subnets through Resource Graph as children of their VNet, completing placement topology.

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

---

Subnets partition a virtual network's address space and attach NSGs, route tables, and service endpoints. They carry no direct charge but determine where billable resources live.

## Address slices with no meter of their own

Azure never bills for a subnet. Carving a VNet into two subnets or twenty changes nothing on the invoice directly; what changes is where billable things land. A NAT gateway serves a specific set of subnets; a delegated subnet hands its range to a managed service; service endpoints and private endpoints attach at subnet scope. Each of those attachments carries its own meter, and the subnet is the address where they all meet. Reading a bill without subnet context means knowing that a charge exists without knowing which environment produced it.

## Children of the VNet in discovery

Discovered via Azure Resource Graph as children of their VNet, completing the network topology used for dependency and placement context. In ZopNight's graph the subnet is the middle layer: the VNet above it defines the boundary, the NICs below it identify the actual machines. That chain is what lets a cost or scheduling decision on one VM be checked against everything else sharing its network segment. Subnets are discovery-and-topology only, with nothing to stop, start, or resize on a schedule.

## Placement decides the bill, not the subnet

The recurring hygiene patterns here are indirect but real. Delegated subnets left behind after their managed service was torn down block address reuse and hint at incomplete cleanup. Subnets whose NSG association was removed during troubleshooting and never restored are an exposure signal rather than a cost one. And environments that grew one subnet at a time often hold generous address ranges that make later VNet peering plans awkward, a design cost paid in migration effort rather than currency.

## Viewing subnets inside a VNet

Azure portal → Virtual networks → select a network → Subnets shows each subnet's address range, available IPs, delegations, and its NSG and route-table associations. That is the same association context ZopNight collects for every subnet across the estate.