Cloud Networking

Cloud networking connects workloads, users, offices, the internet, and managed cloud services. You build it from software-defined networks, addresses, routes, gateways, traffic filters, name resolution, and traffic-distribution services.

The cloud changes how you operate these familiar networking ideas. You declare network resources through an API. The provider implements them on shared infrastructure. You can create or remove a network in minutes, but speed does not remove the need for careful design.

Your central question is always the same: Which traffic should travel from this source to that destination, through which path, under which controls?

Start with the packet path

A useful mental model has five checks:

Name: How does the source resolve a service name to an address?
Route: Which route matches the destination, and what is its next hop?
Policy: Which filters allow or deny the flow?
Translation or distribution: Does a gateway translate the address, or does a load balancer select a healthy target?
Return path: Can the response travel back through a compatible route and policy?

When an application times out, trace these checks in order. “The network is down” is rarely precise enough to help.

Virtual networks are isolation and routing scopes

Cloud providers offer a virtual network, often called a VPC or VNet. It gives your resources a private addressing and routing scope. You divide that address space into subnets and place network interfaces or managed services in those subnets.

A subnet is an IP prefix, not a security boundary by itself. A route table decides where matching traffic goes. A firewall rule, security group, or network access rule decides which traffic may pass. Providers attach these controls to different scopes, so you must learn the exact evaluation model of your chosen platform.

Cloud implementations differ. An AWS VPC spans a Region, while its subnets belong to individual Availability Zones. Google Cloud VPC networks are global, while their subnets are regional. Azure virtual networks and subnets are regional. Keep the vendor-neutral concepts stable, then verify each provider's scope and defaults.

Plan addresses before connections

An IPv4 address identifies an interface within an addressing scope. Classless Inter-Domain Routing, or CIDR, writes a network as an address plus prefix length. A shorter prefix represents a larger address block. A longer prefix represents a smaller, more specific block.

Private IPv4 ranges from RFC 1918 can be reused inside separate organizations. That reuse becomes a constraint when networks later connect. Two networks with overlapping prefixes cannot route between identical destinations without translation, renumbering, or an intermediary design.

Plan for growth before assigning subnets. Reserve non-overlapping ranges for environments, regions, workloads, and future connections. Document ownership. Avoid filling an address block so tightly that the next deployment forces a redesign.

IPv6 provides a much larger address space and does not require IPv4-style address conservation. It still requires routes, filtering, DNS, monitoring, and deliberate exposure decisions. Dual-stack operation means you operate both protocol paths. A control applied only to IPv4 leaves the IPv6 path untreated.

Routes choose paths

A route maps a destination prefix to a next hop. The next hop might be local delivery, an internet gateway, a network address translation gateway, a peering connection, a transit hub, a virtual appliance, or a hybrid connection.

Routing uses the most specific matching prefix. A route for a particular service network therefore wins over a default route. The IPv4 default route is 0.0.0.0/0; the IPv6 default route is ::/0. A default route means “use this path when no more specific route matches.” It does not mean that policy allows the traffic.

Reachability needs both a route and permission. Adding an internet gateway does not make a private workload publicly reachable by itself. Public addressing, route direction, filtering, and application listeners all matter.

Ingress and egress are different decisions

Ingress is traffic entering a network or service. Egress is traffic leaving it. Treat them separately.

For public ingress, place a managed load balancer or application gateway at the edge when possible. It can expose a stable endpoint and distribute requests across healthy targets. Keep application targets private when they do not need direct public access.

For IPv4 egress, a network address translation gateway can let private workloads initiate connections through a public address. It does not create a general inbound path to those workloads. Private service endpoints can keep traffic to supported managed services on provider networks and can reduce dependence on public addressing or general internet egress.

Egress requires policy too. An unrestricted default route through a translation gateway is convenient, but it also creates a broad path for data movement and software downloads. Restrict destinations when the risk and platform capabilities justify it.

Segmentation limits movement

Segmentation separates workloads into policy scopes. You might separate production from development, public entry points from application tiers, or regulated systems from general services.

Use least-privilege rules. Allow the required protocol, port, source, and destination. Avoid broad rules that turn every private address into a trusted peer. Network location alone does not establish identity or authorization. NIST zero trust guidance explicitly rejects implicit trust based only on network location.

Stateful and stateless filters behave differently. A stateful filter tracks an allowed connection and normally permits its return traffic. A stateless filter evaluates each direction independently. Provider terminology varies, so verify whether a control is stateful, its attachment scope, its rule priority, and its default behavior.

DNS is part of the design

Applications should usually connect by service name, not by a hard-coded address. DNS maps names to records. Cloud DNS services commonly support public zones and private zones. Private zones let selected networks resolve internal service names that the public internet should not see.

Hybrid systems need a name-resolution plan across cloud and on-premises environments. Decide which resolver is authoritative for each zone, where queries are forwarded, and how private records stay private. A working route with broken DNS still looks like an application outage.

Load balancing and resilience

A load balancer accepts traffic and selects a target. Layer 4 load balancers make decisions from transport information such as address and port. Layer 7 load balancers can use application information such as an HTTP host or path.

Health checks remove unhealthy targets from normal selection. They do not repair the target. Design the workload across failure domains, make health checks reflect real readiness, and test what happens when a target, zone, or connection fails.

Regional and global distribution solve different problems. A regional load balancer spreads traffic within a region. A global traffic service may direct users among regions. Neither removes the need for application state, data replication, DNS, and recovery design.

Hybrid and multi-network connectivity

Peering directly connects two virtual networks. A transit hub connects several networks through a central routing point. A site-to-site VPN carries encrypted traffic across another network. A dedicated private circuit provides a provider connection that does not use the public internet as its normal path.

Choose by scale, bandwidth, latency, availability, routing control, encryption needs, and cost. A dedicated circuit is not automatically encrypted. A VPN is not automatically redundant. Build redundant devices, tunnels, and paths when the requirement demands them.

Route exchange through Border Gateway Protocol can reduce manual updates, but dynamic routing also propagates mistakes. Filter advertised and accepted prefixes. Prevent overlapping ranges before connection. Test failover in both directions.

Observe the network you operate

Collect evidence at several layers:

configuration history shows what changed;
flow logs show summarized network conversations and policy results;
DNS logs show lookup behavior;
load balancer metrics show target health, request volume, and errors;
application metrics and traces show whether reachable services work correctly;
active connectivity tests show whether a proposed or current path should succeed.

Flow logs do not normally contain full packet payloads. They are useful for reachability analysis, security review, and traffic patterns. Packet capture provides deeper evidence when the platform and privacy policy permit it.

Create alerts from service objectives and known failure signals. Logging every possible event can add noise and cost. Retain the evidence you need for operations, security, and compliance.

Design for cost and change

Cloud networking has usage costs. Common cost drivers include cross-zone or cross-region transfer, internet egress, managed gateways, firewalls, load balancers, dedicated connections, public addresses, and log ingestion. Pricing differs by provider and region.

Draw the expected traffic paths before deployment. A technically valid route through a central appliance may add latency, processing charges, and a failure dependency. Private endpoints may avoid one path while adding endpoint charges. Compare the whole path, not one resource price.

Manage network configuration as reviewed code where possible. Validate address overlap, routes, and policy before deployment. Roll out high-impact changes in stages. Keep an emergency recovery path that does not depend on the control you are changing.

Where cloud networking ends

Cloud networking provides connectivity and traffic controls. It does not replace application authentication, authorization, encryption, safe software, or data governance. A private subnet is not proof that a caller is trusted. A firewall cannot decide whether a valid user may approve a payment.

Managed services also change your control boundary. You may configure an endpoint and policy without managing the underlying routers. Learn which layers the provider operates and which settings remain yours.

The skill is not memorizing product names. It is tracing paths, expressing intent as routes and policy, testing failure, and collecting evidence.