Amazon VPC
Amazon VPC (Virtual Private Cloud) is a logically isolated network you create inside a Region. You place subnets, route traffic, attach resources, and decide what can talk to what. Almost everything that runs "inside your account" — EC2, RDS, ECS tasks, ElastiCache, VPC-attached Lambda — runs inside a VPC.
A VPC is Region-wide, giving you a private IPv4 (and optional IPv6) address space divided into subnets across Availability Zones, with routing rules deciding where packets go. It is the single most cross-cutting service on AWS: half the other services assume you understand it.
Addressing and Subnets
A VPC has an IPv4 CIDR block between /16 and /28, usually an RFC 1918 range like 10.0.0.0/16. Plan the CIDR before creating production VPCs and avoid overlaps: two VPCs both numbered 10.0.0.0/16 can never be peered without renumbering one.
A subnet is a slice of the CIDR tied to one AZ. "Public" and "private" are conventions, not switches: a subnet is public only when an Internet Gateway is attached and its route table points 0.0.0.0/0 at that gateway. A typical layout is one public and one private subnet per AZ, across at least two AZs.
public — ALB · NATprivate — app serversisolated — databasepublic — ALB · NATprivate — app serversisolated — databaseRouting and Internet Access
A route table maps destination CIDRs to targets — local, an Internet Gateway, a NAT Gateway, a peering connection, a Transit Gateway, or a VPC endpoint — with longest-prefix match winning. An Internet Gateway gives bidirectional public access; an instance is reachable only when the IGW is attached, the route exists, the instance has a public IP, and security rules allow it.
A NAT Gateway lets private instances make outbound connections without being reachable inbound — place one per AZ for HA. NAT Gateway charges per hour plus per GB are one of the two biggest VPC cost lines; route AWS-service traffic through VPC endpoints to avoid them.
Security Groups vs Network ACLs
A security group is a stateful firewall on an instance, ENI, ALB, or RDS — return traffic for an allowed connection is automatic, rules are allow-only, and the default denies inbound and allows outbound. A network ACL is a stateless subnet-level filter with allow and deny rules evaluated in order.
Do almost all enforcement with security groups and leave NACLs permissive, using them only for coarse blocks like denying a CIDR range. A security group can reference another as its source — db-sg allows 5432 from app-sg — which is cleaner than hard-coded CIDRs. When debugging connectivity, check security groups first, then routes, then NACLs.
VPC Endpoints and Connectivity
VPC endpoints reach AWS services privately. Gateway endpoints are free and exist only for S3 and DynamoDB (added as a route); interface endpoints (PrivateLink) place an ENI with a private IP and work for most services, billed per hour and GB. The classic use is cutting NAT Gateway bills for traffic that never needs to leave AWS.
To connect VPCs: peering is a one-to-one link that does not scale past a handful (N(N-1)/2 connections); Transit Gateway is the hub-and-spoke answer beyond three or four VPCs; PrivateLink exposes one specific service rather than a whole network. Flow Logs capture packet metadata for forensics and troubleshooting.
Security Group — stateful, attached to a resource, allow-only. The primary firewall for almost all enforcement — reference other security groups as sources.
Network ACL — stateless, attached to a subnet, allow and deny. A coarse guardrail for blocking ranges, not everyday allow-listing.
- Overlapping CIDR ranges across VPCs you later want to peer or connect to on-prem — peering refuses to establish, fixable only by renumbering one side.
- Placing a NAT Gateway in just one AZ — it does not survive that AZ's outage; run one per AZ for production.
- Routing heavy S3 or DynamoDB traffic through a NAT Gateway instead of a free Gateway endpoint, paying per-GB NAT charges for nothing.
- Debugging connectivity at the NACL layer first — nine times out of ten the block is in a security group.
- Building a single-AZ VPC for production, which has the same failure profile as a single data center.
- Meshing VPC peering past five or six VPCs instead of moving to a Transit Gateway, drowning in N(N-1)/2 connections.
- Plan the CIDR before creating the VPC and keep ranges non-overlapping across VPCs.
- Use at least two AZs in production, with one public and one private subnet per AZ.
- Use security groups as the primary firewall and reference other security groups instead of hard-coded CIDRs.
- Use Gateway endpoints for S3/DynamoDB and interface endpoints for other AWS-service traffic to cut NAT costs.
- Turn on VPC Flow Logs in production before you need them.
- Move to Transit Gateway once you exceed three or four VPCs.
Knowledge Check
What actually makes a subnet 'public'?
- An Internet Gateway on the VPC and a route sending 0.0.0.0/0 to it
- Setting the subnet's type field to 'public' in the AWS console
- Giving every instance in the subnet a public IP address
- Placing the subnet in the Region's first Availability Zone
Why must you avoid overlapping CIDR blocks across VPCs?
- Two VPCs with the same range cannot be peered or connected without renumbering one
- Overlapping CIDRs double the hourly NAT Gateway cost on both sides of the link
- AWS outright rejects the creation of any new VPC whose CIDR matches a default range
- Overlapping CIDRs silently disable VPC Flow Logs
How does a security group differ from a network ACL?
- A security group is stateful and per-resource; a NACL is stateless and per-subnet
- A security group is stateful per-subnet; a NACL is per-instance
- Security groups support explicit deny rules, while NACLs do not
- They are functionally identical except for where each one appears in the AWS console
What is the cheapest way to give private instances access to S3 without a NAT Gateway?
- A Gateway VPC endpoint for S3, free and added as a route
- An interface endpoint for S3, which is also free of charge
- A second NAT Gateway placed in another Availability Zone
- VPC peering to a public VPC that fronts S3
You have grown to roughly ten VPCs that all need to reach each other. What is the right connectivity choice?
- A Transit Gateway hub — ten attachments, not 45 peering links
- Full-mesh VPC peering — it stays the simplest at any scale
- PrivateLink connections between every pair of the VPCs
- Merge all ten of them into one large flat VPC
You got correct