Virtual Network

A virtual network provides a logically isolated address space for cloud resources. AWS calls it a VPC and scopes it to an account and region; Azure calls its regional network a VNet. Address ranges, subnets, routes, and security rules determine how resources within and outside it communicate.

What lives inside it does three separable jobs, and confusing them is where most debugging time goes: subnets divide the address space, route tables decide where traffic goes, and security rules decide what is allowed along a path that routing has already made possible. Reachability and permission are different questions, and so are addressing and placement.

Whether a subnet carries zone placement depends on the provider

A subnet allocates a range of network addresses for resources. Its relationship to availability-zone placement differs between providers.

An AWS subnet belongs to one Availability Zone. Zonal resources placed in that subnet share that zone, so adding more instances there alone does not establish zone redundancy. Address exhaustion can prevent further allocation in that subnet; check capacity in every subnet needed by the deployment.

Azure VNets and subnets span the availability zones of their region. Supported zonal resources select placement independently of subnet count. Three subnets therefore do not by themselves establish a three-zone workload; inspect the resources and their failover design.

Google Cloud scopes the network differently again

The two models above are both regional. Google Cloud is the third case and the difference is structural: “VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone,” while “subnets are regional resources.”

So one network can span regions, with a regional subnet in each, and connecting two regions is not a peering exercise because they were never separate networks. That changes what a diagram means rather than adding a feature — a design showing one network behind workloads in several regions is not omitting a peering or other network-to-network connection between those subnets, because none is needed. The traffic still crosses regions, so latency, any applicable transfer charges, and route and firewall dependencies remain.

That convenience has limits, and both are easy to assume away. A global network does not place anything for you: where a workload runs, and whether it runs in more than one region, is still a per-resource decision and a multi-region deployment is still a design you build. And reachability is not implied by membership — routes between subnets of one network exist automatically, but firewall rules still decide what is allowed, and a default-deny for incoming traffic means even same-network communication needs a rule.

Route tables make a subnet private, not its name

An AWS route table maps destination address ranges to forwarding targets such as gateways, interfaces, or connections. Evaluate the applicable routes for each flow rather than inferring its path from the subnet’s name.

A subnet without an explicit route-table association uses the main route table. Review that inherited configuration when creating the subnet and whenever the main table changes.

A new direct connection through an internet gateway needs an applicable route, an appropriate public address, and rules permitting the flow. AWS security groups and network ACLs provide distinct filtering controls. Removing the applicable gateway route closes that direct path; a public address alone cannot replace the route.

Blocking new connections and terminating existing sessions are different tasks. AWS security groups may keep tracked connections working after an allow rule is removed until those connections time out; qualifying untracked flows instead stop when their permitting rule is removed. For immediate isolation, verify the actual path and an effective control such as a stateless network ACL, then test both existing sessions and new attempts.

Also inspect other paths: a public load balancer, reverse proxy, bastion, separate IPv6 route, or connected network may still reach the resource. NAT gateways allow outbound initiation and return traffic, not unsolicited inbound initiation; a NAT instance with deliberate port forwarding is different. Remove unnecessary public addresses and broad rules so later routing changes cannot reopen the same exposure.

In AWS, a private subnet has no direct internet-gateway route. Non-default subnets do not automatically assign public IPv4 addresses unless configured to do so. IPv4 outbound internet access can be added through a NAT device with suitable routes and filtering; it does not authorize unsolicited inbound connections.

IPv4 and IPv6 have separate route entries. Review both address families and their filtering rules. IPv6 outbound-only internet access can use an egress-only internet gateway; closing the IPv4 path does not close an independently configured IPv6 path.

Routing and filtering are different questions

Routing selects packet destinations and filtering permits or drops flows. A missing usable route and a filtering drop can both appear as a timeout. Inspect the effective routes and rules and correlate connection tests with available flow evidence; the symptom alone does not distinguish them.

Either way the rules are access grants, and they deserve the review that any grant does. Least privilege applies to a security group exactly as it does to an identity, and the rule opened during an incident is the one audits find still open a year later.

Address planning is the decision you cannot redo cheaply

Address planning should distinguish expanding network capacity from changing addresses already assigned to resources. AWS permits secondary IPv4 CIDR blocks subject to overlap, route, and quota restrictions, but does not resize an existing VPC CIDR block. Azure supports VNet address-space changes with applicable constraints and peering synchronization. Subnet changes and resource renumbering have their own limits and migration implications.

Allocate capacity for expected growth and reserve future ranges through IP address management. Private address space is finite within the organization’s connected network, so excessive allocation can constrain later networks. Avoid overlaps across networks intended to connect, including on-premises ranges. If two destinations use the same address, ordinary destination-based routing cannot select both unambiguously; the connection needs an explicit translation or service-access design.

Overlapping networks can sometimes connect through address translation, proxies, or service-level private connectivity. AWS documents private NAT with a transit gateway as one approach. Each covers specified paths and adds configuration and troubleshooting obligations; it does not automatically provide general connectivity between every overlapping address. Compare that design with supported expansion or renumbering options.

Connection options assume that planning. VPC peering lets two networks “route traffic between them privately,” and a transit gateway acts as “a Regional virtual router for traffic flowing between its attachments,” which can include networks, VPN connections, and on-premises links. Ordinary direct routing needs non-overlapping destination ranges. A transit gateway combined with a separately designed translation path can connect specified overlapping-network flows, as the private-NAT example above illustrates; the gateway alone does not remove address ambiguity.

For any resource, the question worth being able to answer is: which subnet, which route table, which routes, and which rules. How those choices interact with private endpoints, DNS, load balancing, on-premises links, and transfer cost is worked through in The Route Table Nobody Read.

References


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.