9 lessons, from fundamentals to advanced architecture. Each explains the idea, then lists the points worth remembering:
Beginner
VPC, subnets and Availability Zones
A VPC is an isolated virtual network you define with a private IP range (CIDR). You divide it into subnets, each pinned to ONE Availability Zone; a subnet is "public" if its route table sends internet-bound traffic to an Internet Gateway, and "private" otherwise. Public subnets host internet-facing resources (load balancers, bastions); private subnets host application servers and databases. Spreading subnets across multiple AZs is the foundation of high availability.
VPC = isolated network; each subnet lives in exactly one AZ
Public subnet routes to an Internet Gateway; private does not
Spread subnets across AZs for availability
Exam tip: A subnet is "public" ONLY because its route table has a 0.0.0.0/0 route to an Internet Gateway — not because of any subnet flag. This distinction is tested constantly.
A VPC is created with a CIDR block (e.g. 10.0.0.0/16) that defines its private IP range; each subnet takes a smaller slice (e.g. 10.0.1.0/24). A smaller prefix number means more addresses (/16 ≫ /24). AWS reserves a few addresses in every subnet for internal use, so the usable count is slightly less than the raw block. Plan non-overlapping ranges up front — overlapping CIDRs prevent VPC peering and complicate hybrid connectivity.
VPC CIDR (e.g. /16) is subdivided into subnet CIDRs (e.g. /24)
Smaller prefix number = more addresses; AWS reserves a few per subnet
Avoid overlapping ranges — they block peering and hybrid networking
Exam tip: Remember AWS reserves the first four and the last IP in each subnet, so a /24 does not give a full 256 usable addresses.
A route table decides where subnet traffic goes. An Internet Gateway (IGW) gives a subnet two-way internet reachability (making it public). Private subnets have no IGW route; to let their instances reach the internet OUTBOUND only (for updates, external APIs), you add a route to a NAT gateway that lives in a PUBLIC subnet. Inbound connections to private instances stay blocked — exactly what you want for app servers and databases. Every VPC has a main route table applied to any subnet you don't explicitly associate.
Route table = the traffic map for a subnet; main route table is the default
IGW = bidirectional internet (public subnets)
NAT gateway (in a public subnet) = outbound-only internet for private subnets
Exam tip: NAT gateway is AZ-scoped and managed/scalable; for HA deploy one per AZ. A self-managed NAT instance is the older, less-available alternative.
An Elastic Network Interface (ENI) is a virtual NIC in a subnet; instances get a primary ENI with a private IP that persists for the instance's life. A public IP (auto-assigned) changes on stop/start; an Elastic IP is a static public IP you own and can remap between resources for failover. Security groups attach to ENIs. Private IPs are how resources talk inside the VPC; public/Elastic IPs are only for internet reachability.
ENI = virtual NIC in a subnet; carries private IP + security groups
Auto-assigned public IP changes on stop/start; Elastic IP is static and remappable
Internal traffic uses private IPs; public/EIP only for internet exposure
Exam tip: Use an Elastic IP when you need a fixed public address you can move to a standby resource; don't rely on the auto-assigned public IP across restarts.
Security groups are STATEFUL firewalls attached to ENIs/resources: allow inbound and the return traffic is automatically allowed. They can only ALLOW (no deny rules). Network ACLs are STATELESS firewalls attached to subnets: you must allow both request and response directions explicitly (including ephemeral ports), and they can both ALLOW and DENY. Security groups are your primary control; NACLs add coarse subnet-wide rules or an explicit deny (e.g. block a bad IP range).
Security group vs NACL: SGs are stateful, per-resource, allow-only; NACLs are stateless, per-subnet, allow+deny. NAT gateway vs VPC endpoint: a NAT gateway gives private subnets general OUTBOUND internet (any destination) and is billed hourly + per GB; a VPC endpoint gives private access to a SPECIFIC AWS service without the internet — a Gateway endpoint for S3/DynamoDB (free) or an Interface endpoint (PrivateLink) for others. Use endpoints for AWS-service traffic and NAT for general internet egress.
VPC endpoints let resources reach AWS services privately, without traversing the internet or a NAT gateway. A Gateway endpoint (for S3 and DynamoDB) is a route-table target — free, and the standard way to give private subnets access to S3/DynamoDB. An Interface endpoint (AWS PrivateLink) puts an ENI with a private IP in your subnet for most other services, billed hourly + per GB. Endpoints keep traffic on the AWS network and remove the need to route service traffic through NAT.
Gateway endpoint (S3, DynamoDB): route-table entry, no extra cost
Interface endpoint (PrivateLink): an ENI in your subnet for most services
Both keep AWS-service traffic off the public internet (and off NAT)
Exam tip: S3 and DynamoDB use GATEWAY endpoints (route table, free). Everything else uses INTERFACE endpoints (ENI, PrivateLink).
VPC peering connects two VPCs privately so resources communicate using private IPs; it is non-transitive (A–B and B–C does not give A–C) and requires non-overlapping CIDRs plus route-table entries on both sides. For many VPCs, a Transit Gateway acts as a hub-and-spoke router so each VPC attaches once instead of building a mesh of peerings — the scalable way to connect dozens of VPCs and on-premises networks.
High availability comes from spreading resources across multiple AZs: subnets per AZ, a load balancer across those AZs, Auto Scaling launching instances in each, and a NAT gateway per AZ so an AZ failure doesn't cut outbound access for the survivors. Common failures to reason about: a single-AZ NAT gateway becomes a single point of failure; forgetting a route makes a subnet unexpectedly private/public; overlapping CIDRs block peering; a missing NACL return rule silently drops responses.
HA = subnets + LB + Auto Scaling + NAT all spread across AZs
One NAT gateway = a single point of failure for outbound; deploy per AZ
Walk through how a private-subnet instance can reach the internet for updates while never accepting inbound connections, and how it can reach S3 privately.
Strong answer: private subnet has no IGW route; add a NAT gateway in a public subnet and route 0.0.0.0/0 to it (outbound only). For S3, use a Gateway VPC endpoint (free, route-table target) so traffic never leaves the AWS network — no NAT needed for S3.
How do you place a public web app and a private database in a VPC so the database is never reachable from the internet, and what firewalls control the traffic?
A strong answer covers:
Public subnet for the LB, private subnet for the DB
Security groups (stateful) vs NACLs (stateless)
Outbound via NAT gateway (no inbound)
Instances in a private subnet cannot reach the internet to download OS patches. Walk me through your investigation.
A strong answer covers:
Private subnet needs a route to a NAT gateway for outbound
NAT must live in a PUBLIC subnet with an IGW route
Security groups (stateful) and NACLs (stateless, need return rules)
Check the subnet is associated with the right route table
Common wrong turns:
Putting the NAT gateway in the private subnet
Expecting a NAT gateway to allow inbound connections
Forgetting NACLs are stateless and need an ephemeral-port return rule
A workload is generating unexpectedly high NAT Gateway costs. How would you investigate and reduce them?
A strong answer covers:
NAT bills per hour AND per GB processed — find the traffic
Use VPC Flow Logs / Cost Explorer to identify top talkers
S3/DynamoDB gateway endpoints remove that traffic from NAT
Interface endpoints (PrivateLink) for other AWS services
Common wrong turns:
Assuming a NAT gateway is only an hourly charge
Adding more NAT gateways to "spread load" instead of removing traffic
Moving instances to public subnets to avoid NAT
Explain the difference between a security group and a network ACL, and when the distinction actually bites you.
A strong answer covers:
Security groups attach to ENIs/instances and are STATEFUL
NACLs attach to subnets and are STATELESS
Only NACLs can explicitly DENY (e.g. block an IP range)
Stateless means return traffic needs its own rule
Common wrong turns:
Saying security groups attach to subnets
Trying to block a single malicious IP with a security group
Design the VPC layout for a public web tier and a private database tier that must survive an Availability Zone failure.
A strong answer covers:
Subnets in at least two AZs, public and private per AZ
ALB across AZs fronting the app tier
RDS Multi-AZ for automatic database failover
NAT per AZ so one AZ failure does not break egress
Common wrong turns:
A single NAT gateway shared across AZs as a hidden single point of failure
Putting the database in a public subnet
Assuming Multi-AZ gives read scaling
A production security group was opened to the internet overnight. How do you find out who did it and stop a repeat?
A strong answer covers:
CloudTrail records the API call and the identity behind it
CloudTrail = who did what; CloudWatch = health; Config = configuration/compliance
Organization trail to S3 for durable, cross-account retention
Relying only on the 90-day event history for audit
Design a highly available API running across multiple Availability Zones. Be explicit about what fails and what survives.
A strong answer covers:
ALB spanning at least two AZs
Auto Scaling group spanning the same AZs, self-healing
ELB health checks so app failures trigger replacement
Multi-AZ data tier (RDS Multi-AZ) with private subnets
No single points of failure (NAT, single instance)
Common wrong turns:
Leaving a single NAT gateway or single instance in the path
Using EC2 status checks only
Answer these with follow-ups and optional AI feedback in the AWS mock interviewer.
Key VPC comparisons
NAT Gateway vs VPC Endpoint
A NAT gateway lets private-subnet instances reach the INTERNET outbound (e.g. third-party APIs, OS patches). A VPC endpoint gives private, in-network access to AWS services (like S3 or DynamoDB) WITHOUT traversing the internet or a NAT. If the destination is an AWS service, prefer an endpoint (cheaper, more private); for arbitrary internet destinations, use NAT.
Other AWS services to study next
VPC rarely appears on its own in an exam question — these come up alongside it: