5.10 — Networking in the Cloud

A cloud console shows you a dozen unfamiliar names: VPC, subnet, route table, internet gateway, NAT gateway, security group, network ACL, VPC endpoint, transit gateway.

Every single one of them is something from Chapters 5.1 to 5.9 with a management interface bolted on. There is no new networking here. A VPC is a private address range from Chapter 5.3.1. A route table is the routing table from Chapter 5.3.2. A NAT gateway is your home router from Chapter 5.3.3. A load balancer is the layer-4-versus-layer-7 distinction from Chapter 5.1.

So this page derives each concept from the primitive it wraps, and shows what a working network actually looks like. Once you see the mapping, cloud networking stops being vocabulary and becomes something you can reason about.

1. The VPC: your own private address space

You start by choosing a private CIDR block (Chapter 5.3.1):

10.0.0.0/16      →  65,536 addresses, 10.0.0.0 through 10.0.255.255

That is a VPC on AWS, a VNet on Azure, a VPC network on Google Cloud. Same thing: a logically isolated network, using one of the RFC 1918 private ranges, inside which you control everything.

Nothing about that is new. It is exactly what your home router does with 192.168.1.0/24 — a private range that means nothing on the public internet, with a translation layer for anything that needs to leave.

What the cloud adds is that the isolation is enforced by software rather than by wire. Your VPC and another customer's VPC may run on the same physical hosts and the same physical switches, and both may use 10.0.0.0/16, and they cannot see each other. The mechanism is an overlay: every packet is wrapped in an outer header carrying a network identifier, so the physical network routes on the outer header and only the correct VPC's hosts ever unwrap it. This is the VLAN idea from Chapter 5.2 — tag the traffic, let only tagged-alike traffic mix — implemented in software at enormous scale.

Choose the block deliberately, because it is painful to change. Three rules:

• Make it big. A /16 costs nothing extra and a /24 will run out. Addresses are free; renumbering is not.
• Do not overlap with anything you might ever connect to. If your VPC is 10.0.0.0/16 and your office is 10.0.0.0/16, you can never VPN them together — routing cannot distinguish two identical prefixes. Overlapping CIDR is the single most common irreversible mistake in cloud networking, and it is why organisations keep a central allocation registry.
• Leave room between blocks so a future environment can be added without interleaving.

2. Subnets: splitting the block, and the availability zone

Inside the VPC you carve subnets, exactly as in Chapter 5.3.1:

10.0.0.0/16                     the VPC
├── 10.0.1.0/24                 public subnet,  zone A
├── 10.0.2.0/24                 public subnet,  zone B
├── 10.0.11.0/24                private subnet, zone A
├── 10.0.12.0/24                private subnet, zone B
├── 10.0.21.0/24                database subnet, zone A
└── 10.0.22.0/24                database subnet, zone B

A cloud subnet lives in exactly one availability zone — one physically separate datacentre within a region, with independent power and cooling. This is the constraint that shapes every diagram: to survive a zone failure you need a subnet in each zone, which is why the list above is duplicated. A subnet cannot span zones, so redundancy is expressed by having more subnets.

The provider reserves five addresses in every subnet, not two. Chapter 5.3.1 said the network address and broadcast address are always reserved. AWS also takes three more: the first usable address is the VPC router, the second is the DNS resolver, and one more is held for future use. So a /24 gives you 251 usable addresses, not 254, and a /28 gives you 11 rather than 14 — which matters when you size a small subnet and wonder why you cannot launch the last instance.

"Public" and "private" are not settings. There is no checkbox. A subnet is public if and only if its route table sends 0.0.0.0/0 to an internet gateway. That is the entire definition, and it is a routing fact, not an attribute. Understanding this one sentence is what separates copying a tutorial from designing a network.

3. Route tables: Chapter 5.3.2, with a form

Every subnet is associated with a route table, and a cloud route table is the same structure as the one on your laptop.

A public subnet's table:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	internet gateway

A private subnet's table:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	NAT gateway

A database subnet's table:

Destination	Target
10.0.0.0/16	local

Read them with longest prefix match (Chapter 5.3.1) and everything follows:

• The local route is automatic and cannot be removed. It is why every subnet in a VPC can reach every other by default — a fact worth knowing, because subnets are not an isolation boundary. Isolation comes from security groups, not from being in a different subnet.
• The default route decides everything else. Internet gateway means public. NAT gateway means outbound-only. No default route at all means the subnet cannot reach the internet in either direction, which is exactly right for a database.

This is the two-line laptop routing table from Chapter 5.3.2, with a web form in front of it. Nothing else has changed.

4. The two gateways, and the asymmetry between them

An internet gateway is not a NAT device. It is a horizontally scaled, highly available target that performs one-to-one address translation between an instance's private address and its public address. Traffic can flow in both directions: an instance in a public subnet can be connected to from the internet, provided its security group allows it.

A NAT gateway is the NAT from Chapter 5.3.3. It sits in a public subnet, holds a public address, and rewrites the source address and port of outbound traffic from private subnets, keeping a translation table so replies come back. Inbound connections are impossible, for exactly the reason Chapter 5.3.3 gave: an unsolicited packet matches no translation entry, so there is nowhere to send it.

The standard three-tier layout. Read it as three route tables: internet gateway, NAT gateway, and nothing. The application servers can fetch a package update and cannot be connected to from outside; the databases cannot even do that.

The NAT gateway must be in a public subnet, which reads as a paradox until you trace a packet. An app server in a private subnet sends to 0.0.0.0/0, which its route table points at the NAT gateway. The NAT gateway rewrites the source and forwards to 0.0.0.0/0 — and its own route table, being a public subnet's, points at the internet gateway. Two hops, two route tables, and the arrangement is exactly the one in your house where the router is the only device with a public address.

The cost surprise worth knowing: a NAT gateway is charged per hour and per gigabyte processed. A workload pulling large volumes from a service through NAT can run up a bill larger than the compute. This is the main reason VPC endpoints exist (section 7), and it is a genuine architectural driver rather than a billing footnote.

High availability requires one NAT gateway per availability zone. A single one is both a single point of failure and a cross-zone data-transfer charge on every packet. The standard layout is one per zone, with each private subnet routing to the one in its own zone.

5. Security groups and network ACLs: the two firewalls, and the difference

This is the most-confused pair in cloud networking, and the distinction is precise.

	Security group	Network ACL
Attaches to	an instance's interface	a subnet
Stateful	yes	no
Rules	allow only	allow and deny
Evaluation	all rules, any match allows	in numbered order, first match wins
Default	deny all inbound, allow all outbound	allow all both ways

Stateful is the word that matters. A security group tracks connections: if you allow inbound on port 443, the reply traffic is automatically permitted, whatever port it goes back on. You write one rule.

A network ACL is stateless. It examines every packet independently with no memory of what came before. So allowing inbound 443 is not enough — you must also allow outbound on the ephemeral port range 1024–65535, because that is where the replies are addressed (Chapter 5.4.1). Forgetting the return rule is the classic network ACL mistake, and the symptom is a connection that establishes and then hangs.

Security groups can reference each other, and this is their best feature:

Database security group:
  inbound TCP 5432 from  sg-application     ← not a CIDR, a security group

That rule says "any instance carrying the application security group may reach me on 5432" — no addresses, no maintenance as instances scale up and down and change addresses. This is identity-based rather than address-based firewalling, and it is strictly better than CIDR rules for internal traffic.

Use security groups as the primary control. They are stateful, they compose by identity, and they are attached to workloads rather than to network geography. Use network ACLs sparingly, for a coarse subnet-wide deny — blocking a known-bad range, or enforcing "this subnet may never talk to the internet" as a second layer that an individual team cannot override. Trying to build fine-grained policy in network ACLs produces a rule set nobody can reason about.

Default outbound is a real decision. Security groups allow all outbound by default, which is convenient and means a compromised instance can exfiltrate data anywhere. Locking egress down to known destinations is meaningful defence in depth and it is operationally annoying — an honest trade rather than an obvious win.

6. Load balancers: Chapter 5.1's layer numbers, sold as products

The layer-4-versus-layer-7 distinction from Chapter 5.1 is exactly the product split:

Layer	AWS	Azure	What it can do
4	Network Load Balancer	Azure Load Balancer	forward on IP and port; extreme throughput; preserves the client IP
7	Application Load Balancer	Application Gateway	route on host, path, header or cookie; TLS termination; rewrite headers
edge	CloudFront	Front Door	CDN plus global routing (Chapter 10.14.3)

A layer-4 balancer does not read your traffic, so it works for any TCP or UDP protocol, adds almost no latency, and cannot route /api to one target group and /images to another. A layer-7 balancer terminates the connection, decrypts, reads the HTTP request and makes a new connection to the backend — which is what enables path routing and header rewriting, and what makes it a real hop that must scale.

Two consequences that appear in every production system:

The client IP disappears at layer 7. The backend sees the balancer's address. The real client is in the X-Forwarded-For header, and you must configure your framework to trust the proxy or every rate limit, log line and geolocation is wrong (Chapter 9.9.2). The corollary matters: X-Forwarded-For is a client-supplied header, so trusting it from an untrusted source lets anyone forge their address. Trust it only from your own balancer.

Health checks decide everything. The balancer removes a target that fails its check. Too shallow — a TCP connect — and it keeps sending traffic to a process that is up but broken. Too deep — a check that queries the database — and a database blip takes every instance out of rotation simultaneously. Chapter 9.7.6 works through this properly, including why a probe proves liveness and not capability.

7. Reaching services without touching the internet

Your application needs to call the provider's object storage. The service has a public endpoint, so by default the traffic goes out through the NAT gateway, across the public internet, and back into the provider's network.

That is three bad things at once: it costs NAT processing charges per gigabyte, it adds latency, and it means your data leaves the private network even though both ends are inside the same provider.

A VPC endpoint (AWS) or Private Endpoint (Azure) fixes this by giving the service an address inside your VPC. Two kinds, and the difference is worth knowing because it explains why one is free:

• A gateway endpoint adds a route table entry for the service's address ranges, sending that traffic to the service directly rather than to the NAT gateway. It costs nothing, because it is a routing change and nothing more. AWS offers these for S3 and DynamoDB.
• An interface endpoint creates an actual network interface with a private IP inside your subnet, and DNS is overridden so the service's hostname resolves to that private address. It works for almost every service and it is billed hourly plus per gigabyte — but far less than NAT.

The security payoff is larger than the cost payoff. With endpoints in place, a private subnet can reach exactly the services you allow and nothing else on the internet at all, because it needs no default route. That is a genuinely strong posture: an instance with no route to 0.0.0.0/0 cannot exfiltrate data to an attacker's server even if it is fully compromised.

Connecting VPCs to each other:

• Peering is a direct route between two VPCs. Simple, cheap, and not transitive — if A peers with B and B peers with C, A still cannot reach C. Ten VPCs fully connected need 45 peerings, which is the n(n-1)/2 problem and why peering does not scale.
• Transit gateway is a hub: every VPC connects once to the hub, and the hub routes between them. Ten VPCs need ten attachments instead of 45 peerings. Costs per attachment and per gigabyte, and is the right answer past a handful of networks.
• VPN connects a VPC to your office or datacentre over the internet, encrypted. Cheap, and it inherits the internet's variable latency.
• Dedicated connections (Direct Connect, ExpressRoute) are a physical private circuit. Predictable latency and lower per-gigabyte cost, at a fixed monthly price and weeks of lead time.

And the constraint that governs all of them: the CIDR blocks must not overlap. Peering, transit gateways and VPNs all refuse or misbehave with overlapping ranges, because longest prefix match cannot choose between two identical prefixes. This is section 1's warning arriving as a real limitation.

8. DNS inside the network

Every VPC has a resolver at the base of the VPC CIDR plus two — for 10.0.0.0/16, that is 10.0.0.2. This is the address DHCP hands to every instance (Chapter 5.3.1), and it is Chapter 5.5's recursive resolver, run by the provider.

Two behaviours worth knowing:

Instances get automatic internal names that resolve to their private addresses, and those names resolve only inside the VPC.

A private hosted zone lets you run your own DNS namespace that exists only within the VPC — so db.internal.example.com resolves to a private address inside, and does not exist at all from outside. This is how service discovery is usually done without running anything extra, and it is also how an interface endpoint transparently redirects a public service hostname to a private address.

9. The vocabulary map

The concepts are identical; only the names differ.

Concept	AWS	Azure	Google Cloud
Private network	VPC	Virtual Network (VNet)	VPC network
Subnet	Subnet	Subnet	Subnet (regional, not zonal)
Instance firewall	Security Group	Network Security Group	Firewall rules
Subnet firewall	Network ACL	NSG on the subnet	—
Outbound NAT	NAT Gateway	NAT Gateway	Cloud NAT
Inbound gateway	Internet Gateway	(implicit with a public IP)	(implicit)
L4 balancer	Network Load Balancer	Load Balancer	TCP/UDP Load Balancing
L7 balancer	Application Load Balancer	Application Gateway	HTTP(S) Load Balancing
Private service access	VPC Endpoint	Private Endpoint	Private Service Connect
Network-to-network	Peering / Transit Gateway	VNet Peering / Virtual WAN	VPC Peering / Network Connectivity Center
Private circuit	Direct Connect	ExpressRoute	Cloud Interconnect

One genuine structural difference: a Google Cloud subnet is regional, spanning every zone in the region, while AWS and Azure subnets are per-zone. So a Google VPC needs fewer subnets for the same redundancy. It is the only difference in this table that changes the shape of a design rather than the spelling.

10. The failures you will actually debug

Work in this order. Every one of these maps to something earlier in the Part.

"I cannot connect to my instance." Six checks, in sequence: (1) is the security group allowing inbound on that port from your address; (2) is the route table correct for the subnet; (3) does the instance have a public IP if you are connecting from outside; (4) is a network ACL blocking the return traffic on ephemeral ports; (5) is the operating system firewall on the instance blocking it; (6) is the process bound to 0.0.0.0 rather than 127.0.0.1 (Chapter 5.9). The last one is the most common and the one people check last.

"Instances cannot reach the internet." Is there a default route; does it point at a NAT gateway; is the NAT gateway in a public subnet with its own route to the internet gateway; does the NAT gateway have an elastic IP.

"Two VPCs cannot talk after peering." Peering creates the connection but not the routes — you must add a route in each VPC's table pointing at the peering connection. Then check for overlapping CIDR, and check the security groups, which do not automatically permit the peer's range.

"It worked in one zone and not the other." A route table associated with one subnet and not the other, or a NAT gateway in only one zone.

"Our data transfer bill is enormous." Traffic crossing availability zones is charged, traffic through a NAT gateway is charged per gigabyte, and traffic leaving the region is charged more. The usual culprit is chatty cross-zone traffic or large downloads through NAT that a VPC endpoint would make free.

And the systemic point: every one of these is a Chapter 5.3 routing question, a Chapter 5.4 port question, or a Chapter 5.9 binding question. There is no cloud-specific networking knowledge here — only cloud-specific names for the questions.

What the interviewer will push on

"What makes a subnet public?" Not a setting — its route table has 0.0.0.0/0 pointing at an internet gateway. That one sentence is the whole answer, and getting it right shows you understand routing rather than the console.

"Why must a NAT gateway sit in a public subnet?" Because it needs its own route to the internet gateway. Trace the packet: the private instance's table sends the default route to the NAT gateway, and the NAT gateway's table sends it to the internet gateway. Two hops, two route tables.

"Security group or network ACL?" Security groups are stateful and attach to instances, so return traffic is automatic and rules can reference other groups by identity. Network ACLs are stateless and attach to subnets, so you must allow the ephemeral return range explicitly — and forgetting that is the classic symptom of a connection that establishes and hangs.

"Design a three-tier network." Public subnets with the load balancer and NAT gateway, private subnets with the application, database subnets with no default route at all — each duplicated across two availability zones. Then say what each route table contains, because that is where the design actually lives.

"Why would you add a VPC endpoint?" Cost (NAT charges per gigabyte), latency, and — the stronger reason — security, because a private subnet with endpoints needs no default route at all, so a compromised instance has nowhere to send data.

"You peered two VPCs and traffic does not flow." Peering creates the connection, not the routes. Add routes on both sides, check for overlapping CIDR, and check that security groups permit the peer's range.

"Why does your application see the load balancer's IP instead of the client's?" Layer-7 termination. The client address is in X-Forwarded-For, and the framework must be told to trust the proxy — while trusting that header from anywhere else lets anyone forge their address.

"What is the one decision you cannot easily undo?" The VPC CIDR block. Overlapping ranges make peering and VPNs impossible, and renumbering a live network is a migration rather than a change. Naming this as the irreversible one is a senior answer.

One thing to volunteer: say that everything in the console maps to a primitive — VPC to a private CIDR, route table to a routing table, NAT gateway to your home router, load balancer to the layer-4/layer-7 split — and that debugging therefore reduces to routing, ports and binding. It reframes the topic from memorised product names to something derivable, which is exactly what an interviewer is trying to find out.

Recall

• A VPC/VNet is a private RFC 1918 CIDR block with software-enforced isolation — the VLAN idea from Chapter 5.2 at scale. Choose it big and non-overlapping; overlapping CIDR is the one irreversible mistake, because it makes peering and VPNs impossible.
• A cloud subnet lives in one availability zone, which is why redundancy means duplicating subnets. The provider reserves five addresses, not two.
• A subnet is public if and only if its route table sends 0.0.0.0/0 to an internet gateway. It is a routing fact, not a setting. The automatic local route means subnets are not an isolation boundary.
• An internet gateway is bidirectional one-to-one translation; a NAT gateway is Chapter 5.3.3's NAT, must sit in a public subnet so it has its own route out, and is charged per gigabyte — which is what makes VPC endpoints worth having.
• Security groups are stateful, attach to instances, and can reference other groups by identity; network ACLs are stateless, attach to subnets, and need an explicit ephemeral-port return rule or connections establish and hang.
• Load balancers are Chapter 5.1's layer numbers as products: L4 forwards without reading, L7 terminates and routes on path/host/header — and then the client IP lives in X-Forwarded-For, which must be trusted only from your own balancer.
• VPC endpoints keep service traffic off the internet; the real payoff is that a private subnet can then have no default route at all, so a compromised instance cannot exfiltrate.
• Peering is not transitive and needs routes added on both sides; a transit gateway replaces n(n-1)/2 peerings with n attachments.

Self-test: Give the exact definition of a public subnet · Trace a packet from a private instance to the internet, naming both route tables · Why must a network ACL have an outbound rule for ports 1024–65535? · What are the three reasons to add a VPC endpoint, and which is the strongest? · Why does peering two VPCs sometimes not work after you create it? · Which single decision in a VPC is effectively irreversible?

Part 5 is complete. You have the whole path: why networks are layered and how the standards holding it together came to exist (5.1), a voltage becoming an addressed frame (5.2), addresses that encode location and the routing that uses them (5.3), the transport that turns unreliable delivery into a stream (5.4), the name lookup that starts every request (5.5), the protocol the web runs on including the cookie in full (5.6), the encryption that makes it safe (5.7), the communication patterns built on top (5.8), the system calls underneath all of it (5.9), and the cloud network that is all of the above with a console (5.10).

Next: Part 6 — Frontend Engineering, which begins where 5.6 left off: the browser receives those bytes, and turns them into pixels.