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

 

Cloud networking uses familiar networking ideas inside a software-defined environment. IP addresses, subnets, routes, gateways, firewalls, DNS, and private connectivity still matter, but the control plane is delivered through APIs and managed services instead of only through physical routers and switches. The result is easier automation and faster provisioning, but it also creates new assumptions that engineers must understand clearly.

A virtual network is not merely a container around cloud resources. It defines an address space, trust boundaries, routing behavior, service connectivity, and the paths through which workloads reach users, other networks, and managed services. Poor network design can make an otherwise healthy cloud workload unreachable, insecure, expensive, or impossible to scale cleanly.

This guide explains VPCs and VNets, subnets, route tables, peering, gateways, hybrid connectivity, private access, security controls, DNS, and troubleshooting from a provider-neutral perspective. The goal is to understand the mechanics well enough that AWS, Azure, Google Cloud, and other implementations become variations on a common networking model rather than unrelated products.

Start with the virtual network as an isolation boundary

Most cloud platforms let you create a logically isolated virtual network for resources. AWS commonly calls this a Virtual Private Cloud, while Azure uses Virtual Network. Other providers use similar concepts. The network has an address space and contains subnets where workloads and service endpoints can be attached.

Isolation is the starting assumption. Resources in different virtual networks generally do not communicate automatically unless you configure a connection, routing path, or service-specific mechanism. That makes the virtual network an important boundary for architecture, security, and ownership.

Cloud networking changes the control plane more than it changes the underlying logic. The evolution from traditional networking shows how familiar ideas such as addressing, segmentation, routing, and policy are expressed through virtual and software-defined constructs.

Plan IP address space before deploying resources

Address planning is easy to ignore in a small lab because almost any private range appears to work. At organizational scale, overlapping address spaces can block peering, complicate hybrid connectivity, make acquisitions harder to integrate, and force translation techniques that add operational complexity.

Choose address ranges with the expected environment in mind. Consider production, development, shared services, multiple regions, on-premises networks, partner networks, and potential future growth. Leave room for subnets and avoid allocating an enormous range to one workload merely because the cloud platform permits it.

Document ownership of address space. A centralized IP address management process can prevent teams from independently selecting ranges that later collide. Automation should validate network allocations before deployment rather than discovering overlap during an urgent integration project.

Use subnets to express placement and policy

A subnet is a smaller IP range inside the virtual network. Subnets often represent placement, routing, security, or operational boundaries. A public-facing load-balancing tier, application tier, data tier, management tier, and private endpoints may live in different subnets so traffic paths and controls can be managed deliberately.

Do not assume that naming a subnet public or private creates security. The actual behavior depends on routes, public IP assignments, gateways, security rules, and the platform’s service model. A subnet is private because of how traffic can reach and leave it, not because of the label attached to it.

Design subnets around architectural purpose. Excessively small subnets can run out of addresses as services scale. Excessively broad subnets can make segmentation and troubleshooting harder. Reserve enough space for platform-managed addresses and future growth where the provider requires it.

Understand route tables as forwarding decisions

A route says where traffic matching a destination should go next. Cloud platforms usually create some system routes automatically for local network ranges and common destinations. Engineers can add static or user-defined routes to steer traffic through gateways, firewalls, appliances, hybrid connections, or other network services.

When troubleshooting, follow the packet. Determine the source address, destination address, relevant subnet, applicable route table, best matching route, next hop, and return path. Many cloud network problems become straightforward when you stop looking at resource names and instead trace the forwarding decision one step at a time.

A route table is easier to understand when the abstraction is tied to an actual forwarding path. AWS VPC design provides a concrete example of how subnets, routes, gateways, and destinations combine to determine where a packet goes next.

Remember that return routing matters

Connectivity is bidirectional for most application flows. A forward path from client to server is not enough if the response follows a different route that is blocked, translated incorrectly, or sent to another inspection device. Asymmetric routing can be especially troublesome when stateful firewalls or network appliances expect both directions of a connection.

When a ping, TCP session, or application request fails, trace both directions. Check whether the destination has a route back to the source network and whether security devices on the return path recognize the session. Hybrid networks frequently fail because on-premises routing knows about one cloud subnet but not a newly added range.

Design changes should include route propagation and return-path validation, not just the creation of the forward connection.

Distinguish internet gateways from outbound translation

Cloud networks often use a gateway or platform function to reach the public internet. The exact design differs by provider, but an important distinction is whether a workload is directly reachable from the internet or only able to initiate outbound connections through address translation.

Private application instances frequently need software updates, external APIs, or package repositories without accepting unsolicited inbound traffic. A managed NAT service or controlled egress path can provide outbound access while keeping the workload itself free of a public address.

Understand the failure and scaling characteristics of the egress design. Centralizing all outbound traffic through one appliance can simplify control but also create a capacity bottleneck or shared failure domain. Log and monitor egress so unexpected destinations or sudden transfer costs can be investigated.

Treat peering as connectivity, not automatic transitivity

Network peering connects two virtual networks so resources can communicate using private addresses without sending traffic across the public internet. It is attractive because it is simple and usually provides high-bandwidth, low-latency connectivity through the provider backbone.

Peering does not necessarily behave like a traditional transit router. Many cloud peering designs are intentionally non-transitive: if network A peers with B and B peers with C, A may not automatically reach C through B. Route exchange, security policy, DNS, and service access can also require separate configuration.

At small scale, many direct peerings can work well. At large scale, a mesh becomes difficult to manage. That is when hub-and-spoke or managed transit architectures become useful.

Use hub-and-spoke to centralize shared connectivity

A hub network can host shared services such as firewalls, DNS, hybrid gateways, inspection, bastion access, and centralized egress. Spoke networks host individual applications, teams, or environments and connect to the hub through peering or a transit service.

The architecture reduces duplicated shared infrastructure and can make policy enforcement more consistent. The trade-off is that the hub becomes important to many workloads. Its capacity, availability, routing, and change process need stronger controls because a mistake can affect a large blast radius.

Hub-and-spoke patterns centralize shared services only if routes, inspection, and failure behavior are designed deliberately. AZ-700 networking provides a useful Azure context for seeing how peering, gateways, and application-delivery components fit into that model.

Use transit services when peering no longer scales

Large organizations may need connectivity among dozens or hundreds of virtual networks, multiple regions, branch locations, datacenters, and partner networks. Managed transit services provide a central routing layer so every network does not require direct peering with every other network.

A transit design should still be segmented. Central connectivity does not mean every network should reach every other network. Use route domains, tables, policy, and security controls to separate production from development, regulated workloads from general workloads, and shared services from tenant environments.

Plan address space and route scale early. A transit architecture can simplify connectivity, but it cannot magically solve widespread overlapping IP ranges or unclear ownership.

Connect on-premises networks through VPN carefully

Site-to-site VPN connections use encrypted tunnels over the public internet to connect cloud networks with on-premises or other environments. They are useful for initial hybrid connectivity, smaller traffic volumes, backup links, and locations where dedicated circuits are not justified.

Production designs should use redundancy. That can include multiple tunnels, separate termination devices, diverse internet providers, dynamic routing, and clear failover behavior. Two tunnels that share one physical firewall and one internet circuit may protect against a tunnel failure but not against the larger device or provider failure.

Measure performance and stability. Encryption overhead, internet conditions, packet size, routing changes, and firewall capacity can all influence the effective throughput of a VPN path.

Use dynamic routing for changing hybrid environments

Border Gateway Protocol is commonly used to exchange routes between cloud gateways and external networks. Dynamic routing reduces the need to manually update static routes as networks change, but it also introduces routing policy that must be understood and governed.

Know which prefixes are advertised, which are accepted, and how preferred paths are selected. A mistaken route advertisement can direct large amounts of traffic toward the wrong environment. Use filters, communities, priorities, or platform-specific controls where appropriate to keep route exchange intentional.

Dynamic routing matters most when connectivity can change and several paths may be valid. advanced AWS networking takes that reasoning further with BGP, dedicated connectivity, load balancing, and more complex hybrid network architecture.

Use dedicated connectivity when requirements justify it

Cloud providers offer private or dedicated connectivity services that bypass the public internet for traffic between customer networks and the provider edge. These services can deliver more predictable throughput, private routing, and integration with enterprise WAN designs.

Dedicated does not automatically mean resilient. A circuit can share a provider, facility, router, or physical path with another circuit that appears separate on paper. Ask the connectivity provider about diversity and design redundant paths according to the failure scenarios that matter.

Many organizations combine dedicated connectivity with VPN as a backup. Test the failover and confirm that routing, capacity, and security policies remain correct when traffic moves to the secondary path.

Understand security groups and stateful filtering

Cloud platforms commonly provide stateful workload-level or interface-level security rules. These rules allow or deny traffic according to source, destination, protocol, port, identity, tags, or other platform constructs. Because the filter is stateful, return traffic for an allowed connection is often handled automatically.

Keep rules narrow and meaningful. Allowing all internal network traffic because it seems private creates a large lateral-movement surface. Prefer application-to-application requirements: web tier to application tier on a specific port, application tier to database tier, management source to administrative endpoint.

Review rules as applications change. Old exceptions accumulate easily in cloud environments because creating a rule is fast and removing one feels risky when ownership is unclear.

Understand subnet-level stateless controls

Some platforms also expose stateless access-control lists or similar subnet-level filters. Stateless controls evaluate traffic in each direction independently, so both request and response flows may need explicit rules. They can provide a coarse boundary around a subnet but can be harder to operate than stateful workload rules.

Use layers for different purposes. A subnet-level control can establish a broad network boundary, while stateful security groups or firewall policies enforce workload-specific access. Avoid duplicating the same complex policy in multiple layers because troubleshooting becomes difficult when engineers cannot tell which layer rejected the packet.

Document which control is authoritative for each class of decision.

Separate network security from routing

A route determines where traffic should go. A firewall or security policy determines whether the traffic is permitted. Confusing these functions creates wasted troubleshooting effort. A packet can have a perfect route and still be blocked, or a security rule can permit traffic that has no valid path.

When testing connectivity, check routing first, then security policy, then service state. Use flow logs, packet captures where available, reachability-analysis tools, and application logs to determine where the traffic stops.

Routing answers where traffic should go; policy can change which path is permitted or preferred. policy-based routing is a useful example of that distinction because forwarding can be influenced by policy rather than destination alone.

Use private service access where it reduces exposure

Managed databases, storage services, secrets platforms, and other PaaS services may expose public endpoints by default. Private endpoints or service-specific private connectivity can let workloads reach them through provider-controlled private paths rather than through a public address.

Private access can reduce exposure and simplify some compliance requirements, but it introduces DNS and routing considerations. Applications must resolve the service name to the private endpoint from the correct networks, and administrators need to understand how access works from on-premises or peered networks.

Do not assume private connectivity replaces identity and authorization. Network location should complement, not substitute for, strong authentication and least-privilege access.

Design DNS alongside the network

DNS is part of cloud networking because applications depend on names to locate services. Public DNS directs internet clients. Private DNS resolves internal names for workloads, private endpoints, and hybrid services. Split-horizon designs can return different answers depending on where the query originates.

Plan how cloud networks resolve on-premises names and how on-premises clients resolve cloud-private names. Conditional forwarding, resolver endpoints, managed DNS forwarding, and private zones may all be involved. A network can have correct routes and still be unusable when name resolution points to the wrong address.

Include DNS checks in connectivity troubleshooting. Verify which resolver answered, what record was returned, and whether the client is caching an outdated value.

Plan multi-region networking explicitly

Deploying an application in two regions does not automatically create one global private network. Regions may have separate virtual networks, route domains, firewalls, and service endpoints. Inter-region connectivity must be designed, and the cost and latency of cross-region traffic should be understood.

Keep chatty application dependencies close together where possible. A design that continuously sends database, logging, or storage traffic across regions can produce avoidable latency and transfer cost. Replicate or partition state deliberately rather than letting the network hide a poor placement decision.

Multi-region networks need explicit decisions about addressing, route exchange, failure domains, inspection, and latency. Google Cloud network engineering brings those considerations together from the perspective of operating a production cloud network.

Control egress as carefully as ingress

Security discussions often focus on inbound access, but outbound traffic can be equally important. Compromised workloads may attempt to download tools, contact command-and-control infrastructure, or exfiltrate data. Legitimate applications can also create unexpected transfer costs by sending large volumes across regions or to the public internet.

Use known egress paths, DNS controls, firewall policies, proxies, or service endpoints where the risk justifies them. Log destinations and volumes. Make exceptions explicit rather than allowing unlimited outbound traffic by default simply because it makes deployment easier.

Egress design also affects availability. If every workload depends on one centralized firewall or proxy, that system must be sized and protected according to the combined traffic and failure impact.

Monitor network flow instead of guessing

Flow logs and network telemetry can show source and destination addresses, ports, accepted or rejected traffic, bytes, packets, and timing depending on the platform. These records are invaluable when troubleshooting intermittent connectivity or validating that policy behaves as expected.

Use telemetry to answer a specific question. Did the packet leave the source? Did it reach the destination subnet? Was it rejected by a policy? Did return traffic appear? Was latency concentrated on one path? Avoid collecting huge volumes of network data without a plan to query and retain it effectively.

Troubleshooting becomes faster when flow evidence can confirm where traffic was accepted, dropped, translated, or redirected. network traffic monitoring reinforces that evidence-first approach instead of relying on configuration inspection alone.

Troubleshoot from the endpoint outward

Begin at the source. Confirm the application is sending traffic to the intended destination and port. Check local name resolution, interface configuration, route selection, and security policy. Then move outward through gateways, peerings, firewalls, transit services, and the destination network.

At the destination, confirm that the service is listening and that return traffic has a valid path. A large percentage of networking problems are application listeners, DNS answers, missing routes, unexpected network policies, or return-path mistakes rather than failures in the provider backbone.

Change one condition at a time. Randomly editing routes and firewall rules until traffic works can create an insecure environment and destroy the evidence needed to understand the original problem.

Build network labs around packet paths

A useful cloud networking lab starts with a diagram and a prediction. Create two subnets and decide how they should communicate. Add a route, a security rule, or a gateway and predict the packet path. Then break one condition deliberately and use logs or reachability tools to identify the failed assumption.

Expand gradually. Peer a second virtual network. Add a hub. Connect a simulated on-premises network. Create a private endpoint. Introduce overlapping routes or restrictive security rules in a safe environment. The objective is to learn how the control plane translates intent into forwarding behavior.

A useful networking lab starts with an expected packet path, then introduces a controlled fault and checks where the evidence diverges. AZ-700 practice scenarios supplies Azure-specific scenarios that can be used without changing that provider-neutral troubleshooting method.

Use a provider-neutral network review checklist

For every workload, document the virtual networks, address ranges, subnets, routing tables, gateways, peerings, transit services, hybrid links, public endpoints, private endpoints, DNS dependencies, and security boundaries. Identify which team owns each shared component and what failure scope it has.

Trace the critical traffic flows: user to application, application to database, application to external service, administrator to management endpoint, on-premises to cloud, and monitoring to its destination. Record how each flow is routed, filtered, resolved, encrypted, and observed.

Finally, test the highest-risk assumptions. Fail a route, remove a peering, block a security rule, change DNS, or disconnect a tunnel in a controlled environment. Networking becomes understandable when engineers can predict and then observe what the packet will do.

Avoid overlapping address space before it becomes an integration problem

Overlapping IP ranges are easy to create because private address space is reusable by design. The problem appears later when two networks that both use the same range need to communicate. A router cannot determine which destination owns the overlapping address without additional translation, segmentation, or application-layer workarounds.

Prevent overlap through centralized allocation, automated validation, and documented ownership. Reserve ranges for future regions and major environments rather than consuming the entire corporate address plan in the first cloud account. When integrating an acquired company or partner whose ranges already overlap, treat translation as a deliberate exception because it adds troubleshooting and observability complexity.

Cloud-native applications can reduce dependence on fixed addresses by using DNS, service discovery, and identity, but underlying network ranges still matter for routing, hybrid connectivity, firewall policy, and some third-party allow lists. Good address planning remains a foundational operational control.

Include IPv6 in long-term network design

IPv6 is increasingly relevant as organizations grow beyond convenient IPv4 allocations and connect large numbers of cloud workloads, devices, and services. The protocol provides a vastly larger address space, but it does not remove the need for routing, segmentation, security policy, DNS, and operational visibility.

Do not treat IPv6 as an automatic extension of an IPv4 design. Confirm which services support dual-stack operation, how addresses are assigned, how egress and ingress controls behave, and whether on-premises or partner networks can route IPv6. Security teams need equivalent policy and logging for both protocols so enabling IPv6 does not create an unmonitored path.

A gradual dual-stack approach can help teams develop skill without forcing every dependency to move at once. Include IPv6 behavior in application tests, observability, and incident runbooks rather than enabling it only at the network edge.

Design network appliances and inspection paths for scale

Organizations often insert firewalls, intrusion-prevention systems, secure web gateways, or other appliances into cloud traffic paths. These controls can centralize security policy, but they also become architectural dependencies. Throughput, connection limits, zone placement, state synchronization, routing symmetry, and software upgrades all affect the availability of inspected traffic.

Avoid assuming that a virtual appliance scales like a native managed service. Understand how additional instances are added, how flows are distributed, and what happens to established sessions when an appliance fails. If stateful inspection requires both directions of a flow to pass through the same appliance, routing design must preserve that behavior.

Use service chaining only where the control requirement justifies the complexity. Every additional hop creates another place where latency, misconfiguration, or capacity exhaustion can interrupt the application path.

Govern network changes as shared infrastructure

Cloud networking is often consumed by many application teams even when a small platform or infrastructure group owns the core network. A route, DNS forwarding rule, transit policy, or firewall change can therefore have a larger blast radius than the change requester realizes.

Use infrastructure as code, peer review, automated validation, and staged rollout for shared network changes. Detect overlapping routes, overly broad security rules, missing tags, unauthorized public exposure, and policy violations before deployment. Keep an inventory that maps shared network objects to the workloads that depend on them.

Ownership must be clear during incidents. Application teams should know when a problem belongs to their local security group or service configuration and when to involve the team responsible for transit, hybrid connectivity, DNS, or centralized inspection. Clear boundaries reduce both unnecessary escalation and risky self-service changes to shared infrastructure.

Include network cost in architecture decisions

Cloud network cost is influenced by more than the number of gateways. Data transfer across regions, availability zones, public internet paths, NAT services, inspection appliances, load balancers, and dedicated connectivity can all contribute. A technically correct architecture can become unexpectedly expensive if large data flows cross costly boundaries continuously.

Map major traffic volumes along with packet paths. Keep high-volume, latency-sensitive dependencies close where possible. Cache or replicate data deliberately rather than repeatedly transferring the same information across regions. Understand whether centralized inspection or egress causes traffic to make an unnecessary detour through another zone or region.

Cost analysis should never justify bypassing required security or resilience, but it can reveal an architecture that is inefficient by accident. Network telemetry and billing data together help teams distinguish valuable traffic from avoidable movement.

Make network documentation useful during incidents

A network diagram is most useful when it explains paths and control points rather than merely displaying icons. Show address ranges, route domains, transit points, gateways, inspection, hybrid links, DNS relationships, and the important application flows. Keep highly dynamic details in generated inventories rather than forcing every changing IP address onto a static drawing.

Pair the diagram with a short troubleshooting map. For each critical flow, identify the source, destination, expected DNS answer, relevant route table, security controls, and telemetry source. An engineer responding at 2 a.m. should be able to follow the path without first reconstructing the architecture from several consoles.

Update documentation through the same workflow as infrastructure changes where possible. Stale network documentation can be worse than no documentation because it causes responders to trust a path that no longer exists.

Validate network changes with explicit acceptance tests

A network change should have a measurable success condition before it is deployed. If a route is being added, define which sources should reach which destinations and which paths must remain unreachable. If a private endpoint is being introduced, define the expected DNS answer, route, source identity, and public-access behavior. If a firewall policy changes, identify both the traffic that must begin working and the traffic that must continue to be denied.

Turn those expectations into repeatable checks where possible. Connectivity probes, route validation, DNS lookups, policy tests, and flow-log review can catch mistakes before users report them. This is especially important for shared transit and hybrid networks because a small configuration change can affect many applications at once.

Acceptance tests make the design easier to operate: they convert “the network looks right” into evidence that the intended packet paths and security boundaries still behave as designed.

Cloud networking becomes much easier when every configuration is tied to an expected packet path. Instead of memorizing dozens of service names, keep returning to five questions: what is the source, what is the destination, which route selects the next hop, which policy permits or denies the flow, and how does the response return? Add DNS and identity when the service model requires them. That sequence works in simple labs, large enterprise networks, and certification scenarios because it focuses on the mechanics that remain stable even as providers introduce new products and interfaces.

The strongest network design is therefore one that can be explained, tested, and observed as a set of intentional paths rather than a pile of cloud objects. When engineers understand those paths, changes are safer and troubleshooting becomes evidence-driven.