VPC, Subnets & Security Groups

1. What Is It?

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS network where you launch resources. It's your private network inside AWS — you control the IP address range, how traffic flows between subnets, and what can reach the internet.

Without a VPC, every resource you create would be on a flat shared network. Your RDS database would be reachable from the internet. An attacker who compromised one of your EC2 instances could freely reach every other instance in the account. VPC gives you network-layer isolation: a misconfigured application can't reach a database unless you explicitly allow it, and internet traffic can't reach your backend servers unless you route it there.

2. How It Works

VPC and CIDR blocks

When you create a VPC, you assign it a CIDR block — the private IP range for everything inside it. Common choices: 10.0.0.0/16 (65,536 IPs), 172.31.0.0/16. RFC 1918 private ranges (10.x, 172.16–31.x, 192.168.x) are standard; don't overlap with ranges used by services you connect to (on-premises networks, peered VPCs).

Every AWS account comes with a default VPC in each region pre-configured with public subnets, an internet gateway, and permissive security groups. It's convenient for quick experiments but not suitable for production workloads.

Subnets

A subnet is a slice of your VPC's CIDR block, tied to a specific AZ. You use subnets to separate your network into zones with different routing rules:

-+ResetFullscreen

Subnets don't provide security on their own — they organize routing. Security comes from Security Groups and NACLs.

Internet Gateway (IGW) and NAT Gateway

• Internet Gateway: Attached to the VPC, enables two-way internet access. Resources in a public subnet with a public IP can receive inbound traffic.
• NAT Gateway: Deployed in a public subnet. Allows resources in private subnets to initiate outbound connections (e.g., pulling packages from npm, calling an external API) without being reachable from the internet. NAT Gateway is per-AZ — for true HA, deploy one in each AZ.

Security Groups

A Security Group is a stateful virtual firewall attached to a resource (EC2 instance, RDS, Lambda ENI). It controls which traffic is allowed in (inbound rules) and out (outbound rules).

Key properties:

• Stateful: If inbound traffic is allowed, the response is automatically allowed without an explicit outbound rule. You don't need to open ports for return traffic.
• Whitelist-only: Security Groups can only allow traffic; they cannot explicitly deny. Anything not matched is implicitly denied.
• Source can be another Security Group: This is the most powerful pattern — instead of specifying an IP range, you say "allow traffic from resources that have Security Group sg-app." This means your RDS database's Security Group has an inbound rule allowing port 5432 from sg-app, and only EC2 instances attached to sg-app can connect. Adding a new app server to sg-app grants it database access automatically.

-+ResetFullscreen

Network ACLs (NACLs)

NACLs are stateless, subnet-level firewalls. Unlike Security Groups, they can deny traffic and must have explicit rules for both inbound and outbound (including return traffic). They're evaluated in rule-number order, lowest first.

NACLs are a secondary defense layer. Most VPC security is implemented with Security Groups; NACLs are added when you need to block specific IPs or CIDRs (e.g., blocking a known bad actor's IP range).

3. What Backend Engineers Actually Need to Know

The mental model that matters: Public subnets face the internet. Private subnets host your application. DB subnets hold your data. Security Groups are the fences between them.

Never put a database in a public subnet. The DB subnet should have no route to the internet and a Security Group that only allows traffic from the app Security Group on the specific database port.

Common misunderstandings:

• "Private subnet means secure." — A private subnet only means there's no direct route to the internet. If your Security Group allows 0.0.0.0/0 inbound on port 3306, any resource in the VPC can reach your database. The subnet determines routing; the Security Group determines access.
• "Security Groups are like iptables rules." — They are conceptually similar but stateful. You don't need to write rules for established connections or return traffic.
• "I need a public IP on my EC2 to reach the internet." — Only for inbound. For outbound, private subnet + NAT Gateway is the correct pattern. Your app servers should never have public IPs.
• "One VPC is enough." — At scale, teams often use multiple VPCs per environment (dev, staging, prod), connected via VPC Peering or AWS Transit Gateway. This provides blast-radius isolation at the network level.

VPC endpoints: If your Lambda or EC2 needs to call S3 or DynamoDB, traffic normally routes out through the NAT Gateway (costing money and bandwidth). A VPC Endpoint keeps that traffic on AWS's private network — free and faster. Gateway endpoints work for S3 and DynamoDB; Interface endpoints work for most other services.

4. Tradeoffs & Decisions

Public vs. private subnet for app servers:

• Public subnet is simpler (no NAT Gateway) but exposes your instances to the internet. Every public-IP instance is a potential attack surface.
• Private subnet with NAT Gateway is the standard production pattern. NAT Gateway costs ~$0.045/hr per AZ plus data transfer, but this is the correct tradeoff for any production workload.

Security Groups vs. NACLs:

• Use Security Groups for almost everything. They're stateful, flexible, and composable.
• Add NACLs when you need to block a specific IP range at the subnet level — Security Groups can only allow, not deny.

Single VPC vs. multi-VPC:

• Single VPC with multiple subnets is appropriate for most startups and small teams. Simpler to reason about.
• Multiple VPCs (connected via Transit Gateway or Peering) are used by larger organizations to enforce strict environment isolation — a bug in the dev VPC literally cannot affect the prod VPC's network.

If you see X:

• "Our RDS is publicly accessible" → Red flag. Move it to a private subnet immediately. This is a common security finding.
• "We need to call an external API from our Lambda in a VPC" → You need a NAT Gateway (or configure a VPC endpoint if it's an AWS service).
• "We're peering two VPCs" → Ensure the CIDR blocks don't overlap; peering doesn't scale — use Transit Gateway for hub-and-spoke topologies with 3+ VPCs.

5. Interview Cheat Sheet

Key sentences:

1. "A VPC is a logically isolated network inside AWS — you control the IP space, routing, and what can communicate with what."
2. "Security Groups are stateful whitelists attached to individual resources; the canonical pattern is to reference another Security Group as the source rather than an IP range."
3. "Private subnets block inbound internet traffic via routing, not access control — the Security Group is what controls which resources within the VPC can reach a given service."
4. "NAT Gateways let private-subnet resources make outbound internet calls without being exposed inbound — they're per-AZ, so production deployments need one per AZ for HA."

Common follow-ups:

Q: How would you design the network for a three-tier web app (load balancer, app servers, database)? A: Three subnet tiers across 2–3 AZs: public subnets for the ALB and NAT Gateways, private subnets for app server EC2/ECS, and isolated DB subnets for RDS. Security Groups chain: the ALB SG allows 443 from internet; the app SG allows 8080 from the ALB SG only; the DB SG allows 5432 from the app SG only.

Q: What's the difference between a Security Group and a NACL? A: Security Groups are stateful (return traffic automatic), allow-only, and attached to resources. NACLs are stateless (must explicitly allow return traffic), can deny, and apply to the entire subnet. Use Security Groups for access control, NACLs for blocking known-bad IP ranges.

Q: My Lambda is in a VPC and can't reach the internet. What's wrong? A: Lambdas in a VPC must be in a private subnet with a route to a NAT Gateway (which lives in a public subnet with an Internet Gateway). If the Lambda is in a public subnet, it still can't reach the internet — Lambdas don't get public IPs. Also verify the Security Group allows outbound on the necessary ports.