13.2 — Cloud Networking in Practice

Chapter 5.10 derived the primitives: a virtual network is an RFC 1918 block with software-enforced isolation, a subnet is public if and only if its route table sends 0.0.0.0/0 to an internet gateway, security groups are stateful and network ACLs are not, and overlapping address ranges are the one irreversible mistake.

This page is what an organisation runs into after that — address planning across dozens of accounts, connecting to an office, resolving names in both directions, and the fact that networking is now a line item on the invoice.

1. Address planning, before it is too late

The mistake everyone makes once: 10.0.0.0/16 for everything.

It works for the first environment, and then production, staging, development, the data platform and two acquisitions all have 10.0.0.0/16. They can never be connected, because routing cannot distinguish them, and the fix is renumbering a live network.

IPAM (IP address management) is the practice of allocating ranges centrally and never letting a team pick one. Cloud providers offer a service for it; a spreadsheet with real discipline is better than a service nobody uses.

A workable plan looks like this:

10.0.0.0/8                organisation
  10.0.0.0/12             production      (10.0.0.0  – 10.15.255.255)
    10.0.0.0/16           prod-eu-west
    10.1.0.0/16           prod-us-east
  10.16.0.0/12            non-production
  10.32.0.0/12            shared services (DNS, directories, tooling)
  10.240.0.0/12           reserved for acquisitions and future regions

Three rules that save years of pain:

Leave large gaps. Address space is free and renumbering is not. A /16 per virtual network is generous and it is the right default.

Never reuse a range, even after decommissioning, until you are certain nothing routes to it.

Record allocations somewhere a person must go through to get one. The failure is always someone in a hurry picking a range that "looked free".

And do not forget the corners. Your on-premises network, your partners' networks, the Kubernetes pod and service ranges (Chapter 13.6.12), and any VPN client pool all need addresses that do not collide with each other. A cluster with a pod range overlapping the office network produces failures that are genuinely hard to diagnose, because half the destinations work.

2. Connecting to what you already have

Almost every organisation has something outside the cloud, and there are three ways to reach it.

Site-to-site VPN. An encrypted tunnel over the public internet. Cheap, available in an hour, and it inherits the internet's variable latency and its outages. Correct for low-bandwidth, non-critical connectivity and as a backup path.

Dedicated connection — AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect. A private circuit from your network to the provider's, arranged through a carrier. Weeks to months to provision, predictable latency, high bandwidth, and — the detail that often justifies it — substantially cheaper egress rates, which can make a high-transfer workload cheaper overall despite the circuit cost.

Note it is not encrypted by default. It is private, not confidential. Run a VPN over it, or use TLS end to end (Chapter 5.7), if the data warrants it.

The standard production shape is both: a dedicated connection with a VPN as automatic failover, which gives predictable performance and survives a circuit failure.

Software-defined WAN appears in larger estates, managing many branch sites and cloud connections centrally.

Routing between them is BGP (Chapter 5.3.2), and the two things that matter are: advertise only what you intend — advertising a summary that overlaps a cloud range breaks things quietly — and plan for asymmetric routing, where traffic leaves by one path and returns by another, which stateful firewalls (Chapter 5.10) drop because they never saw the outbound connection.

3. DNS across the boundary

Once you have hybrid connectivity, name resolution has to work in both directions, and this is where a surprising share of hybrid incidents live.

A private hosted zone resolves names only inside your virtual network — db.internal.example.com to a private address, invisible from the internet. This is how you avoid hard-coding private addresses, which Chapter 5.10's rules make necessary anyway.

Split-horizon DNS serves different answers for the same name depending on who asks: api.example.com resolves to a private address inside and a public one outside. Useful, and it is a reliable source of confusion — "it resolves differently on my laptop" is usually this, working as designed.

Resolving on-premises names from the cloud needs a forwarder: a rule saying "queries for corp.example.com go to these on-premises servers".

Resolving cloud names from on-premises needs the reverse: an inbound resolver endpoint in the virtual network, with your on-premises servers conditionally forwarding to it.

Both directions must be configured, and the failure is asymmetric and confusing: applications in the cloud reach the office fine, and nothing in the office can find the cloud.

Remember the resolver address is the virtual network's base + 2 (Chapter 5.10). Security group or firewall rules that block it break everything in a way that looks like a network problem rather than a DNS one.

4. How traffic gets in and out

Inbound, in layers:

1. DNS resolves your name (Chapter 5.5).
2. A CDN or edge network may terminate the connection first (Chapter 13.4).
3. A load balancer — layer 4 or layer 7 (Chapter 10.15) — in public subnets across zones.
4. A web application firewall, usually attached to the load balancer or the CDN.
5. Targets in private subnets, reachable only from the load balancer's security group.

An API gateway sits at this boundary and does the things a load balancer does not: authentication and authorisation, per-client rate limiting and quotas, request and response transformation, usage plans and keys, and per-route routing to different backends. The distinction worth holding: a load balancer distributes traffic, an API gateway manages an API. Chapter 10.8.3 covers the pattern; here it is the concrete component at the edge.

Outbound, and this is where the money is:

• NAT gateway — private instances reach the internet. Charged per hour and per gigabyte processed, and one per zone for availability.
• VPC endpoints — reach the provider's own services privately, bypassing the NAT gateway entirely. Chapter 5.10 makes the security argument; here is the financial one: a data pipeline pulling terabytes from object storage through a NAT gateway is a large and entirely avoidable bill.
• Egress firewall — inspect and restrict outbound traffic by domain. This is the enforcement point for Chapter 8.6.2's egress filtering, and it is where you block the metadata address and unknown destinations.

The rule to carry: know every path by which a byte leaves your network, and price each one.

5. Why IPv4 costs money now

Chapter 5.3.3 explained the exhaustion. The commercial consequence arrived in 2024: cloud providers now charge for every public IPv4 address, whether attached or idle — a few dollars per address per month, which across a large estate is a real number and, more importantly, a deliberate incentive.

What to do about it:

• Do not give instances public addresses. Private subnets plus a NAT gateway or a load balancer.
• Release unattached addresses. They are charged whether used or not, and forgotten reserved addresses are common.
• Use one load balancer for many services rather than one per service.
• Adopt IPv6 where the path supports it. It is free of address charges, and dual-stack is the practical route because parts of the internet and many partner systems are still IPv4-only.

The honest note: IPv6 in the cloud is well supported and not effortless. Some managed services still lag, egress needs an egress-only internet gateway rather than a NAT gateway, and any code that stores or matches addresses must handle 128-bit values and IPv4-mapped forms (Chapter 5.9).

6. Network cost, made explicit

Because it is invisible until the invoice:

Traffic	Typical charge
Internet in	Free
Internet out	Per GB, the largest line
Between zones, same region	Per GB, each direction
Within one zone, private addresses	Usually free
Between regions	Per GB, higher
Through a NAT gateway	Per GB plus hourly
Through a VPC endpoint	Much cheaper or free
Via a dedicated connection	Substantially reduced egress

Three architectural consequences:

Cross-zone chatter is a real cost. A service mesh spread across three zones pays per gigabyte for its own internal traffic. Zone-aware routing — prefer a replica in the same zone, fail over across zones — is the fix, and it also reduces latency.

Move compute to data, not data to compute. Processing in the region where the data lives avoids the transfer entirely.

Endpoints for provider services, always. It is cheaper, faster and more secure at the same time, which is rare.

7. Debugging, in order

Chapter 5.10 gave the six checks. In a hybrid or multi-account estate, extend them:

1. Is it DNS? Resolve from the failing machine, not from your laptop, and check which resolver answered. Split-horizon and forwarding rules make this the first suspect.
2. Is there a route? Read the route table on both sides. Cloud-to-office often works while office-to-cloud has no return route — which produces a connection that opens and hangs.
3. Is it allowed? Security groups both ways, network ACLs (stateless, so the ephemeral return range must be allowed), on-premises firewalls, and any egress firewall.
4. Is anything listening? The bind-address mistake from Chapter 5.9.
5. Is it asymmetric? Traffic out one path and back another, dropped by a stateful device that never saw the outbound flow.
6. Do the ranges overlap? If two networks share a range, some destinations work and some do not, and the pattern looks random.

Flow logs are the tool that ends most of these arguments. They record accepted and rejected connections with source, destination, port and action, so "the network is blocking us" becomes a specific rule and a specific packet.

What the interviewer will push on

"How would you plan addressing for an organisation on a cloud platform?" Central allocation from a large block, generous per-network ranges, big reserved gaps, and never letting a team pick. Then the reason: overlapping ranges cannot be routed and the fix is renumbering a live network, so this is one of very few genuinely irreversible decisions. Include Kubernetes pod ranges and VPN pools in the plan.

"VPN or a dedicated connection?" VPN for speed of provisioning, low bandwidth and as a backup; dedicated for predictable latency, high bandwidth and cheaper egress, which often pays for it. Then the detail people miss: a dedicated connection is private but not encrypted. Production usually runs both, with VPN as failover.

"Hybrid DNS is broken in one direction. What is wrong?" Only one half is configured. Cloud-to-office needs forwarding rules; office-to-cloud needs an inbound resolver endpoint plus conditional forwarding from the on-premises servers. The tell is knowing the two directions are separate configurations.

"Where does cloud network spend actually go?" Internet egress, cross-zone traffic in both directions, and NAT gateway per-gigabyte processing. The fixes are zone-aware routing, VPC endpoints for provider services, and moving compute to the data. Endpoints are the rare change that is cheaper, faster and more secure simultaneously.

"Why did public IPv4 addresses start costing money?" Exhaustion made them a scarce traded asset, and charging is both cost recovery and an incentive to move. The practical response is private subnets behind load balancers and NAT, releasing unattached addresses, and dual-stack — with the honest caveat that IPv6 support in managed services is good and uneven.

"A connection to an on-premises service opens and then hangs. Where do you look?" Asymmetric routing or a missing return route, and a stateful firewall dropping the reply because it never saw the outbound flow. Then reach for flow logs rather than arguing — they name the rule and the packet.

One thing to volunteer: mention that a Kubernetes cluster's pod CIDR is part of the address plan. It is allocated by whoever created the cluster, it commonly overlaps a corporate range, and the resulting failure — half of the on-premises destinations unreachable — is one of the hardest hybrid problems to diagnose from the symptom.

Recall

• Overlapping address ranges are the one irreversible mistake. Allocate centrally (IPAM), leave large gaps, never reuse a range, and include Kubernetes pod/service ranges and VPN pools in the plan.
• VPN is fast to provision and inherits internet variability; a dedicated connection gives predictable latency, high bandwidth and cheaper egress — and is private, not encrypted. Production runs both.
• Hybrid DNS is two separate configurations: forwarding rules for cloud-to-office, an inbound resolver endpoint plus conditional forwarding for office-to-cloud. Split-horizon explains "it resolves differently on my laptop".
• Inbound path: DNS → CDN → load balancer in public subnets → web application firewall → private targets. A load balancer distributes traffic; an API gateway manages an API — authentication, quotas, transformation, per-route backends.
• Know every path a byte leaves by. NAT gateway is hourly plus per gigabyte; VPC endpoints bypass it, which is cheaper, faster and more secure at once; an egress firewall is where Chapter 8.6.2's filtering is enforced.
• Public IPv4 addresses are charged now, attached or not. Private subnets behind load balancers, release unattached addresses, and move to dual-stack — with the caveat that managed-service IPv6 support is uneven.
• Network cost: in is free, out is charged, cross-zone is charged in both directions. Fix with zone-aware routing, endpoints, and moving compute to the data.
• Debug in order: DNS → route (both sides) → security groups and ACLs → is anything listening → asymmetric routing → overlapping ranges. Flow logs end the argument.

Self-test: Why is an overlapping CIDR unfixable in practice? · What does a dedicated connection not give you? · Which half of hybrid DNS is usually missing? · Name the two charges on a NAT gateway and what removes both. · Why did IPv4 addresses start costing money? · What symptom points at asymmetric routing?

Next: 13.3 covers what runs on all this — virtual machines, containers and serverless, with the cost curve that decides between them and the limits that decide whether serverless fits at all.