Cloud Networking: VPCs, VNets, Routing, Peering, and Gateways

Cloud networking becomes much easier when the provider names are translated back into familiar networking questions. What is the address space? Which subnet is the resource in? Which route matches the destination? Which security control allows or denies the traffic? Is translation occurring? Does the path cross a gateway, load balancer, peering connection, private endpoint, or hybrid link?

AWS VPCs, Azure VNets, and Google Cloud VPC networks are not identical, but they all provide a private logical network in which cloud resources can communicate according to defined routes and controls. The engineering challenge is to understand the path rather than memorize one console.

Good cloud networking also requires understanding ownership. In large environments, application teams may consume a network designed and governed by a central platform or networking team rather than creating independent networks for every project.

Address space is the first design decision because overlap is expensive later

Private IPv4 ranges are finite, especially in hybrid and multi-cloud environments. A small application team may see no problem with choosing any RFC 1918 range, but duplicated address space becomes painful when networks later need to connect.

Plan address allocation at organizational scale. Leave room for growth, understand how subnet sizes affect available addresses, and document which ranges belong to which environment or region. IPv6 can reduce some scarcity pressure but introduces its own operational requirements.

CIDR, addressing, routing, DNS, ports, stateful filtering, and troubleshooting remain foundational when infrastructure moves to a cloud provider. The product names change; packets still need an address, a route, an allowed path, and a working return path.

Subnets create placement and routing boundaries

Subnets divide a network’s address space and usually have a regional or zonal relationship depending on the provider. Resources receive addresses from those ranges, and the subnet often determines which route table or other network controls affect the resource.

A “public subnet” is not public merely because of its name. Public reachability typically depends on a combination of route, gateway, assigned public address or frontend, and security policy. Likewise, a private subnet still needs an intentional path for software updates, APIs, or external dependencies.

Design subnets around operational and security boundaries rather than creating one subnet per application by habit. Excessive segmentation creates management overhead; insufficient segmentation can increase blast radius.

For hands-on practice, build a three-tier lab: public ingress, private application subnet, and private data service. Add DNS, a load balancer, outbound NAT, and a second network connected through peering. Then break one element at a time. Remove a route, change a security rule, create overlapping address space in a second lab, or return the wrong DNS answer. Troubleshooting those failures creates more durable skill than memorizing diagrams.

Routes explain where packets go after they leave the source

Routing tables associate destination prefixes with targets or next hops. AWS documents this directly: each subnet is associated with a route table, and a route such as 0.0.0.0/0 can point toward an internet gateway. Azure and Google Cloud implement the same basic forwarding idea with provider-specific route systems.

When troubleshooting, check the most specific matching route, the direction of traffic, and the return path. Asymmetric routing can break stateful firewalls and appliances. Route propagation from VPNs, transit systems, or dynamic routing can also change behavior without a local static route being edited.

Route literacy is one of the fastest ways to move from “networking seems broken” to a concrete hypothesis.

Packet captures, flow logs, network-watcher tools, reachability analyzers, and provider diagnostics are useful only when engineers already have a path hypothesis. Tool output becomes much easier to interpret when you know the expected source address, destination, route, security controls, and return path. That habit scales from a two-subnet lab to complex enterprise transit architectures.

It also makes post-incident reviews more precise because teams can distinguish a routing failure from a security-policy failure instead of treating every outage as generic connectivity trouble.

Peering connects networks but does not automatically create a universal transit fabric

Peering is designed to connect separate virtual networks privately. Azure VNet peering, AWS VPC peering, and Google Cloud VPC Network Peering each have their own constraints and routing behavior.

A common mistake is assuming that if network A peers with B and B peers with C, then A can automatically reach C. Many peering systems are deliberately non-transitive. If the architecture needs centralized transit, use the provider’s routing hub, transit service, or another explicit design.

Peering also requires careful address planning because overlapping ranges usually cannot be routed together cleanly.

Gateways connect different network domains

Internet gateways, NAT gateways, VPN gateways, ExpressRoute or Direct Connect style services, cloud routers, and transit gateways solve different connectivity problems. The word “gateway” does not imply one universal function.

An internet gateway can provide a path between cloud resources and the public internet when other conditions are met. NAT can let private resources initiate outbound connections without accepting unsolicited inbound traffic. VPN gateways connect encrypted tunnels to other networks. Dedicated private connectivity provides more predictable enterprise links.

Choose gateway patterns based on traffic direction, security, performance, availability, and cost. Centralizing all egress through one inspection point may simplify control but can also create latency, cost, and failure-domain concerns.

Load balancing adds another layer to the path. A layer-4 load balancer forwards based largely on network and transport information, while an application gateway or layer-7 load balancer can route using hostnames, paths, headers, or other application-aware rules. Health probes matter because a load balancer can have a valid route to a backend that is technically reachable but not healthy enough to serve traffic.

High availability should be considered at the network layer too. VPN gateways, NAT services, load balancers, DNS resolvers, and inspection appliances can become hidden single points of failure if deployed without regional or zonal resilience. Redundant application servers cannot compensate for a shared network component that all traffic must cross.

Security controls must be evaluated along the entire path

Cloud networks usually combine stateful security groups or equivalent controls, subnet-level or firewall policies, application gateways, web application firewalls, private endpoints, and identity-aware controls. A packet can have the correct route and still be blocked at several layers.

Do not solve every problem by opening a wider CIDR range or port. First identify which two components genuinely need to communicate and then express the narrowest practical rule. Log denied traffic where useful so troubleshooting does not require guesswork.

Networking and security become tightly coupled at advanced levels. Inspection points, private connectivity, segmentation, route control, TLS, denial-of-service protection, and centralized egress all affect both reachability and risk, so designs should be reviewed as one system rather than by separate teams.

Finally, document ownership. Teams need to know who controls route tables, firewall policy, DNS zones, peering approvals, address allocation, and hybrid gateways. Many “network problems” last longer than necessary because the technical path spans several teams and nobody knows who can safely change the failing component. Clear operating ownership is part of network architecture, not administrative housekeeping.

DNS is part of the network even when the IP path is healthy

Applications usually connect to names, not raw addresses. DNS failures can therefore look exactly like network outages from an application’s point of view.

Cloud environments may use public zones, private zones, provider-managed internal names, conditional forwarding, hybrid resolvers, and split-horizon designs. When troubleshooting, verify what name is being queried, which resolver answers, and whether the returned address is reachable from the source.

Hybrid DNS deserves special attention because on-premises and cloud environments may each be authoritative for different namespaces. A routing design without a matching name-resolution design is incomplete.

Private service access and private endpoints also change the troubleshooting model. A managed database may resolve to a private address only from certain networks, use provider-managed DNS zones, or require explicit endpoint policies. When a connection fails, verify both name resolution and the network path before changing firewall rules.

Hybrid and multi-cloud networking magnify every design choice

Once networks cross providers or data centers, address overlap, routing propagation, DNS, MTU, encryption, firewall ownership, and failure recovery all become more complex. The architecture also gains cost from data transfer and dedicated connectivity.

Central networking teams often use hub-and-spoke or transit designs to make connectivity manageable at scale. The important skill is understanding the basic path components well enough to predict how centralized routing, DNS, inspection, and shared connectivity change the blast radius of a failure.

The best troubleshooting habit remains simple: start at the source, identify the destination, trace name resolution and routes, inspect each control along the path, and confirm the return route. Provider terminology changes; packet logic does not.

Cloud networking also has economics. NAT gateways, centralized firewalls, cross-zone traffic, inter-region links, peering, public egress, and dedicated hybrid connectivity can all generate meaningful cost. A design that centralizes every packet for inspection may simplify governance while adding latency and transfer charges. Network architects need to make those trade-offs visible.

AWS, Azure, and Google Cloud networking models reveal which concepts transfer cleanly across providers and where implementation behavior differs. That ability to translate concepts is especially valuable in hybrid and multi-cloud environments.