Networking: VPCs, subnets, load balancers & DNS
Compute, storage, and databases are useless in isolation — they have to talk to each other and your users have to reach them, while attackers must not. Networking is the primitive that does both: it's the wiring that connects your resources and the gates that control who can reach what. Networking intimidates more beginners than any other cloud topic, so we'll build it up one concept at a time, each motivated by the problem it solves.
The VPC: your own private slice of the network
When you put resources in the cloud, you don't want them floating on the open internet where anyone can poke them. You want a private, isolated network that you control — and that's a VPC (Virtual Private Cloud). A VPC is your own logically isolated section of the provider's network, with its own private internal IP address range, where your resources live and can talk to each other privately. Think of it as a walled corporate campus: inside, machines communicate freely over private roads; the outside world only gets in through gates you deliberately open.
Everything else in this lesson happens inside a VPC.
Subnets: rooms within the network, public and private
A VPC is divided into subnets — smaller sub-ranges of the network, each living in a specific availability zone (recall Chapter 1: spreading subnets across AZs is how you get resilience). The most important distinction is public vs private:
- A public subnet has a route to the internet. Resources here can be reached from outside — you put things that should face the world here, like a load balancer.
- A private subnet has no direct route from the internet. Resources here can only be reached from inside the VPC. You put things that should never be directly exposed here — your databases, your internal application servers.
This split is a cornerstone of cloud security architecture. The classic, durable pattern: put the public-facing entry point (a load balancer) in a public subnet, and hide your application servers and databases in private subnets behind it. Users reach the load balancer; they can never reach the database directly.
Firewalls: security groups and the rules of who-talks-to-whom
Even inside a VPC, you control traffic with firewall rules — and the cloud's main tool for this is the security group (AWS/Azure terminology; GCP calls them firewall rules). A security group is a set of rules attached to a resource that says exactly what traffic is allowed in and out — which sources, on which ports. For example: "this database accepts connections only from the app servers' security group, only on the database port." Everything not explicitly allowed is denied by default.
Security groups are how you enforce least privilege at the network layer: the database isn't reachable from the internet (it's in a private subnet) and even within the VPC only the app tier can reach it (its security group says so). Defense in depth.
:::note Ports, briefly Network traffic arrives at a machine on a numbered port — like apartment numbers at one street address. Web traffic conventionally uses port 443 (HTTPS), databases have their own (e.g. 5432 for PostgreSQL). Firewall rules are written in terms of "allow port X from source Y," so a passing familiarity with common ports helps you read them. :::
Load balancers: one front door, many servers behind it
You learned in Chapter 1 that resilience means running multiple copies of your app across AZs. But users only know one address — so something has to take incoming requests and spread them across your fleet. That something is a load balancer: a service that sits in front of multiple servers and distributes incoming traffic among them, sending each request to a healthy instance.
It does three valuable things at once:
- Distributes load so no single server is overwhelmed.
- Provides one stable address (one DNS name) for users, hiding the changing set of servers behind it.
- Health-checks the servers and stops sending traffic to any that are unhealthy — which is exactly what lets one AZ fail without users noticing. The load balancer is the practical mechanism behind the multi-AZ resilience pattern.
Brand names: ELB/ALB (AWS), Cloud Load Balancing (GCP), Load Balancer / Application Gateway (Azure).
DNS: turning names into addresses
Finally, users type myapp.com, not a numeric IP address. DNS (the Domain Name System) is the internet's phone book: it translates human-friendly domain names into the numeric IP addresses machines actually use to find each other. A managed cloud DNS service lets you point your domain name at your load balancer's address, so myapp.com resolves to your front door. DNS is also where you can route users to the nearest region, or shift traffic during a failover, by changing what a name resolves to.
Brand names: Route 53 (AWS), Cloud DNS (GCP), Azure DNS (Azure).
Putting it together: the request's full journey
Trace one user request through every networking concept:
- The user's browser asks DNS for
myapp.com; DNS returns the load balancer's IP. - The request hits the load balancer in a public subnet of your VPC.
- The load balancer picks a healthy app server in a private subnet (across AZs) and forwards the request — allowed by the app servers' security group.
- The app server queries the database in a private subnet — allowed only because its security group permits the app tier on the database port.
- The response travels back out through the load balancer to the user.
The database was never reachable from the internet — wrong subnet, wrong security group. That's networking doing its two jobs at once: connecting the pieces, and gating who can reach what.
Why it matters
Cloud networking is the wiring and the gates. A VPC is your private, isolated network; subnets divide it into public (internet-facing) and private (hidden) zones, with the durable pattern of a load balancer in public and servers/databases in private. Security groups are firewalls that enforce least privilege — only the app tier reaches the database, only on its port. A load balancer spreads traffic across healthy servers in multiple AZs (the mechanism behind resilience) and gives users one stable address, which DNS maps your domain name to. Connect the pieces, control who reaches what — that's the whole job. But "who is allowed" goes deeper than the network: it's the identity system, IAM, that decides what every actor can do.
Where this leads: the public/private subnet split and least-privilege firewall rules are core to Cloud Security (Chapter 8).
Next: Advanced networking: CIDR, NAT, peering & private connectivity →