VPC — Virtual Private Cloud¶

From AWS Re/Start networking ILT (February 2026) and apprenticeship labs.

Ultra-Short Summary¶

A VPC is your private, isolated network inside AWS. You control the IP ranges, subnets, routing, and what can talk to what. Everything in AWS runs inside a VPC — understanding VPC architecture is understanding the backbone of every AWS deployment.

What a VPC Is¶

Without VPC: AWS resources would be on a shared flat network — everything visible to everything
With VPC:    Your own private network slice — isolated by default, you control all connectivity

VPC = your personal data centre network, virtualised on AWS

Default limits: - 5 VPCs per region (soft limit, can increase) - CIDR range: /16 to /28 - Spans all AZs in a region

VPC Components¶

VPC (10.0.0.0/16)
|
+-- Public Subnet (10.0.1.0/24) -- AZ-a
|   +-- EC2 (has public IP)
|   +-- Application Load Balancer
|
+-- Private Subnet (10.0.10.0/24) -- AZ-a
|   +-- EC2 app servers (no public IP)
|
+-- Private Subnet (10.0.20.0/24) -- AZ-a
|   +-- RDS database
|
+-- Internet Gateway  -- allows public traffic in/out
+-- NAT Gateway       -- allows private subnets to call internet (outbound only)
+-- Route Tables      -- control where traffic goes
+-- Security Groups + NACLs -- control what traffic is allowed

Public vs Private Subnets¶

A subnet is "public" or "private" based entirely on its route table — not a setting on the subnet itself:

Public subnet route table:
  Destination     Target
  10.0.0.0/16     local        (VPC-internal traffic)
  0.0.0.0/0       igw-xxxx     (internet traffic -> Internet Gateway)

Private subnet route table:
  Destination     Target
  10.0.0.0/16     local        (VPC-internal traffic)
  0.0.0.0/0       nat-xxxx     (internet traffic -> NAT Gateway)
  -- or no 0.0.0.0/0 entry at all (fully isolated)

Public subnet also requires: EC2 instances need a public IP (auto-assign or Elastic IP).

Security Groups vs NACLs¶

Two layers of traffic control — they work at different levels:

Feature	Security Group	NACL
Level	Instance (ENI)	Subnet
Statefulness	Stateful — return traffic auto-allowed	Stateless — must explicitly allow both directions
Rules	Allow only — no deny rules	Allow AND deny rules
Rule evaluation	All rules evaluated together	Rules in number order, first match wins
Default	Deny all inbound, allow all outbound	Allow all in both directions
Best for	Fine-grained per-instance control	Subnet-level blocking (e.g. block an IP range)

Stateful vs Stateless — the key difference¶

Security Group (stateful):
  You allow port 443 inbound
  -> Response traffic on ephemeral port auto-allowed
  -> No separate outbound rule needed for the response

NACL (stateless):
  You allow port 443 inbound
  -> Response goes out on ephemeral port 32768-65535
  -> Must ALSO allow outbound 32768-65535 or responses are blocked

Ephemeral ports: When a client connects to your server on port 443, the response goes back to the client's randomly assigned high port (1024-65535). NACLs must allow this range outbound or responses are dropped.

Internet Gateway¶

Allows traffic between your VPC and the internet:

Internet Gateway:
  -> Attached to the VPC (one per VPC)
  -> Performs NAT for public IPs (maps public IP -> private IP)
  -> Bidirectional -- inbound requests AND outbound responses
  -> Highly available by default -- no AZ dependency

To reach internet from public subnet:
  EC2 (10.0.1.10 + public IP) -> Security Group -> Route Table -> IGW -> Internet

NAT Gateway¶

Allows private subnet resources to initiate outbound internet traffic (OS updates, API calls) without being reachable from the internet:

Private subnet EC2 -> NAT Gateway (in public subnet) -> IGW -> Internet
                                                            ^
                                              Internet can't initiate connections back

Important details:

NAT Gateway lives in a public subnet (it needs IGW access)
Create one per AZ for HA — if AZ fails, other AZs should use their own NAT GW
Managed by AWS — no patching, auto-scales
Cost: Charged per hour + per GB processed — expensive at scale
NAT Instance — older self-managed alternative (EC2 with IP forwarding), cheaper but you manage HA

VPC Endpoints¶

Connect to AWS services without going through the internet — traffic stays on the AWS backbone:

Type	Works With	How It Connects
Gateway Endpoint	S3, DynamoDB	Entry in route table — free
Interface Endpoint	Most other AWS services	ENI with private IP in your subnet — per-hour cost

Without endpoint:
  EC2 -> NAT Gateway -> Internet -> S3
  (bandwidth costs + NAT Gateway charges)

With S3 Gateway Endpoint:
  EC2 -> VPC Endpoint -> S3
  (no NAT, no internet, free)

Use Gateway Endpoints for S3/DynamoDB — always free and faster.

VPC Peering¶

Connects two VPCs so resources can communicate using private IPs:

VPC A (10.0.0.0/16) <-> VPC Peering <-> VPC B (172.16.0.0/16)

Rules:
  -> No overlapping CIDR ranges (peering fails if ranges overlap)
  -> Not transitive -- A<->B and B<->C does NOT mean A<->C
  -> Works cross-account and cross-region
  -> Must update route tables in both VPCs after creating the peering

AWS Transit Gateway — hub-and-spoke alternative when you have many VPCs to connect. Connect all VPCs to one TGW rather than creating N*(N-1)/2 peering connections.

VPC Flow Logs¶

Capture metadata about traffic flowing through your network interfaces:

Logs include:    source IP, destination IP, port, protocol, bytes, action (ACCEPT/REJECT)
Does NOT capture: packet contents, DNS query names
Destinations:    CloudWatch Logs or S3
Use cases:       security analysis, troubleshooting connectivity, compliance

Mental Model¶

VPC = your private office building in AWS

  Floor plan              = CIDR range (10.0.0.0/16)
  Rooms                   = Subnets (public/private)
  Building entrance       = Internet Gateway
  Loading dock (out only) = NAT Gateway
  Security desk           = NACLs (subnet level)
  Door locks              = Security Groups (instance level)
  Internal corridors      = VPC Peering / Transit Gateway
  Direct AWS tunnel       = VPC Endpoints

Public subnet  = reception area -- people can walk in
Private subnet = back office -- no external access, staff can go out

SAA Patterns¶

Scenario	Answer
EC2 in private subnet needs OS updates	NAT Gateway in public subnet
Block all traffic from a specific IP range	NACL deny rule (SGs can't deny)
EC2 needs S3 access without internet	S3 Gateway Endpoint (free)
Two VPCs need private connectivity	VPC Peering (or Transit Gateway for many)
App in private subnet, reachable from internet	ALB in public subnet -> EC2 in private subnet
NACLs allow traffic but responses don't return	Add outbound ephemeral port range (1024-65535)
HA for NAT Gateway across AZs	One NAT GW per AZ, each subnet routes to its AZ's NAT GW

Self-Quiz¶

What makes a subnet "public" — is it a subnet setting or something else?
Why do NACLs require outbound rules for ephemeral ports but Security Groups don't?
A private subnet EC2 can't reach the internet. Walk through the checklist of what to check.
What's the difference between a Gateway Endpoint and an Interface Endpoint?
VPC A peers with VPC B, VPC B peers with VPC C. Can VPC A reach VPC C? Why not?
Where does a NAT Gateway live — public or private subnet? Why?
What does VPC Flow Logs capture and what does it NOT capture?
When would you use Transit Gateway instead of VPC Peering?