IP addresses, subnets and private networks

Why it matters

Every arrow on an architecture diagram resolves, eventually, to a packet with a source and destination IP address. Addresses decide what can reach what: whether your database is exposed to the internet, whether two services can talk directly, how a client finds a server that moved. Cloud networking is built almost entirely from the ideas on this page, so a working model of them removes a whole class of design mistakes.

The idea

An IP address identifies a network interface so routers can deliver packets to it. IPv4 addresses are 32 bits, written as four numbers (203.0.113.7), giving about 4 billion addresses, which ran out. IPv6 addresses are 128 bits (2001:db8::7) and effectively unlimited; adoption is wide on the public internet and uneven inside data centres, so most backends still think in IPv4.

CIDR and subnets

Addresses are grouped into networks by a prefix. CIDR notation writes the prefix length after a slash: 10.0.1.0/24 means the first 24 bits are fixed and the remaining 8 vary, so the block holds 256 addresses. A /16 holds 65,536; a /32 is one address. A subnet is such a block assigned to one segment of your network; routing decisions are made on prefixes, not individual addresses.

Public, private and NAT

Three ranges are reserved for private use and are never routed on the public internet: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Everything inside a company or a cloud account lives in private space. To reach the internet from a private address, traffic passes through NAT (network address translation), which rewrites the source to a public address and keeps a table to route replies back. Inbound connections to a private address are impossible unless something public forwards them, which is the security property you want for databases and internal services.

Addresses move; names should not

Servers get replaced, autoscale and fail over, and their addresses change with them. Hard-coding an IP into a client or a config is a slow-motion outage. Point clients at a stable name (DNS, covered later), give long-lived endpoints a reserved static IP only when a partner must allow-list you, and let everything internal discover each other through names or a service registry.

	Public IP	Private IP
Routable on the internet	Yes	No; needs NAT to go out, a forwarder to come in
Who should have one	Load balancers, NAT gateways, bastions	Application servers, databases, caches, queues
Security posture	Exposed; needs firewall rules and DDoS protection	Reachable only from inside the network
Cost	Scarce, often billed per address	Free, effectively unlimited
Stability	Reserve a static one when partners allow-list	Changes freely; use names

Trade-offs

Putting everything in private subnets behind NAT is safer and simpler to reason about, but all egress funnels through the NAT, which becomes a bandwidth and cost chokepoint for chatty services. Multiple subnets per availability zone improve blast-radius isolation at the cost of more routing tables and firewall rules to maintain. IPv6 removes NAT entirely and brings its own operational unfamiliarity.

In an interview

Rarely the headline, often the credibility check. When you draw the backend, say: "Only the load balancer has a public address; application servers and the database are in private subnets and reach the internet through a NAT gateway." If a partner integration comes up: "We'd expose a static IP for their allow-list, fronting a balancer." That is usually all the networking an interviewer wants, delivered confidently.