VPC: Virtual Private Cloud & Networking

AWS Fundamentals

Chapter 5 · VPC: Virtual Private Cloud & Networking

Amazon VPC launched 25 September 2009 — three years after EC2 (Chapter 3), once "a virtual machine anywhere on AWS's own shared network" stopped being enough, and real customers needed a genuinely isolated, self-controlled network of their own. This chapter also delivers on a real promise from Chapter 3: the full contrast between security groups and their subnet-level counterpart, Network ACLs.

What Is a VPC?

A VPC (Virtual Private Cloud) is a real, logically isolated section of AWS's own network, scoped to one Region, with its own private IP address range defined as a CIDR block (e.g. 10.0.0.0/16). Everything inside it — EC2 instances, RDS databases (Chapter 6), and more — lives on that private network by default, invisible to anything outside the VPC unless you deliberately open a path.

Subnets: Public vs. Private

A VPC is carved into subnets, each a smaller CIDR range within the VPC's own block, and each tied to exactly one Availability Zone (Chapter 1). Whether a subnet is real "public" or "private" isn't an inherent property of the subnet itself — it's entirely determined by its route table (below): a subnet is public if its route table sends internet-bound traffic to an Internet Gateway, and private otherwise.

Worked Example: Carving a VPC Into Subnets

A VPC with CIDR block 10.0.0.0/16 (65,536 addresses) is split into two /24 subnets — 10.0.1.0/24 (public) and 10.0.2.0/24 (private), each with 256 addresses on paper. A real, easy-to-miss detail: AWS reserves the first 4 and the last 1 address in every subnet for its own internal use (the network address, the VPC router, DNS, future use, and the broadcast address) — so each real /24 subnet actually offers 251 usable addresses, not 256.

Route Tables

A route table is a real, ordered set of rules mapping destination CIDR ranges to a target — "traffic within the VPC's own 10.0.0.0/16 stays local," "everything else (0.0.0.0/0) goes to the Internet Gateway." Every subnet is associated with exactly one route table (though one route table can serve several subnets), and it's this association — not anything about the subnet's own configuration — that ultimately decides where a subnet's own traffic can go.

Internet Gateway

An Internet Gateway attaches directly to a VPC and provides a real, two-way path to the public internet for any subnet whose route table points to it. Instances in that subnet also need a real public IP address of their own (assigned automatically, or via Elastic IP) for this path to actually be usable — the gateway alone doesn't grant one.

NAT Gateway

A private subnet's own instances often still need real outbound internet access (downloading OS updates, calling an external API) without ever being reachable from the internet inbound. A NAT Gateway, deployed in a public subnet, solves exactly this: private-subnet instances route their outbound traffic to it, and it forwards that traffic to the Internet Gateway using its own public IP — but nothing on the internet can initiate a new connection back in through it. This asymmetry — outbound yes, inbound no — is the real, defining difference between a NAT Gateway and an Internet Gateway.

A Useful Mental Model
Internet Gateway = a real, two-way door. NAT Gateway = a one-way door that only opens outward, letting private resources start conversations with the internet without ever letting the internet start one with them.

Security Groups vs. Network ACLs — the Real Contrast

Chapter 3 covered security groups as stateful, instance-level firewalls. Network ACLs (NACLs) are the VPC's own subnet-level counterpart, and they work genuinely differently.

PropertySecurity GroupsNetwork ACLs
Applies toIndividual instances (network interfaces)An entire subnet
StatefulnessStateful — reply traffic automatically allowedStateless — inbound and outbound rules both needed explicitly
Rule typesAllow rules onlyAllow AND explicit Deny rules
EvaluationAll rules evaluated; if any allows it, it's allowedRules evaluated in numbered order; first match wins, then stops

Because NACLs are stateless, a rule allowing inbound traffic on a port does not automatically allow the matching outbound reply — that needs its own separate, explicit rule, in the opposite direction. And because NACL rules are evaluated in real numbered order with the first match winning, rule ordering itself carries meaning that security groups simply don't have.

Two Layers, Not a Choice Between Them
Security groups and NACLs aren't alternatives — real, well-designed AWS architectures use both together, as two independent layers (defense in depth): NACLs providing a coarse, subnet-wide baseline, security groups providing fine-grained, per-instance control on top of it.

Hands-On Exercises

Exercise 1

A subnet's route table sends 0.0.0.0/0 traffic to a NAT Gateway rather than an Internet Gateway. Explain, in your own words, whether this makes the subnet public or private, and what real capability its instances have (and lack) as a result.

📄 View solution
Exercise 2

A VPC uses the CIDR block 10.0.0.0/24. Explain how many usable IP addresses this real subnet actually provides once AWS's own reserved addresses are accounted for, and why.

📄 View solution
Exercise 3

A NACL has an inbound rule allowing HTTPS traffic on port 443, but no matching outbound rule exists. Explain, in your own words, whether traffic will actually flow correctly, and why this scenario couldn't happen with a security group instead.

📄 View solution

Chapter 5 Quick Reference

  • VPC — a logically isolated network within a Region, defined by a CIDR block (launched 2009)
  • Subnet — a smaller CIDR range within a VPC, tied to one AZ; public/private is determined by its route table, not the subnet itself
  • Route table — maps destination CIDR ranges to a target; decides where a subnet's traffic actually goes
  • Internet Gateway — two-way internet access; NAT Gateway — outbound-only, for private subnets
  • Security groups — stateful, instance-level, allow-only; NACLs — stateless, subnet-level, allow+deny, evaluated in numbered order
  • Real subnet capacity — a /24 provides 251 usable addresses, not 256 (AWS reserves 5)