VPC Subnet
Does ZopNight manage VPC Subnet?
A VPC subnet is a regional IP range and carries no charge of its own, but it decides which region cost-bearing VMs land in and how their egress is billed. ZopNight inventories every subnet via Cloud Asset Inventory to anchor topology and packing-density analysis.
Rules that fire on VPC Subnet
No active rule family targets VPC Subnet today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A subnet is a regional IP range inside a VPC where instances and services get their addresses. Subnets are free but determine where cost-bearing resources can live and how traffic egress is charged.
A free range that decides where paid resources live
No meter runs on a subnet itself. Google charges nothing for creating one, however large its CIDR block. The cost consequences are all indirect, and they are real. A subnet pins its member resources to one region, so the subnet a team picks on day one determines which regional rates every VM, load balancer, and Cloud SQL instance in it pays from then on. Traffic between resources also inherits its price from subnet placement: two VMs in the same zone talk for free over internal IPs, while the same conversation across regions bills as inter-region egress. In that sense the subnet is the cheapest object in the project and one of the most expensive decisions.
Subnet inventory as ZopNight’s topology anchor
ZopDev discovers subnets through Cloud Asset Inventory and uses them to anchor every other resource in network topology. Knowing which subnet a VM sits in is what lets packing-density analysis reason about co-location, and what makes cross-region traffic paths visible instead of inferred. Because a subnet has no lifecycle worth automating (there is nothing to stop and nothing metered to pause), it is discovery-only: no schedule ever touches one.
Hygiene findings that start at the subnet layer
Three patterns are worth a periodic look. Sprawl: dozens of near-empty subnets accumulated from abandoned experiments make topology reviews slower and mistakes likelier. Range exhaustion: a subnet that runs out of addresses forces workloads into a second subnet, sometimes in another region, quietly introducing inter-region egress. And accidental cross-region placement: a dev VM dropped into a distant region’s subnet pays that region’s rates and cross-region data charges nobody budgeted.
Reading subnet ranges in the console
Google Cloud console → VPC network → VPC networks lists each network; opening one shows its subnets with region, primary and secondary CIDR ranges, and the resources drawing addresses from them.