Why this matters
As a Platform Engineer, you design and operate the private networks where services live. A solid VPC design prevents outages, blocks unwanted traffic, controls costs, and makes future growth painless.
- Real tasks you will face: plan IP ranges, split public and private subnets, set up routing and NAT, isolate environments, connect to on‑prem, and enable private access to cloud services.
- Bad VPC design shows up later as IP conflicts, unreachable services, security gaps, or expensive data egress.
Who this is for
- Platform and DevOps engineers setting up cloud networking for teams.
- Backend engineers deploying services that must be reachable and secure.
- Learners moving from single-VM setups to multi-AZ, production-grade networks.
Prerequisites
- Basic IP networking (CIDR notation, subnets, routes, gateways).
- Understanding of security groups/firewalls, inbound vs outbound traffic.
- Familiarity with your cloud provider’s core networking terms (VPC/VNet, subnets, IGW, NAT, route tables).
Learning path
- This lesson: VPC Design Basics (address planning, subnets, routing, security boundaries).
- Next: Load balancers and service-to-service networking.
- Then: Private endpoints, service catalogs, and policy controls.
- Later: Hybrid connectivity (VPN/Direct Connect), Transit/Hub networks, and multi-account/multi-project patterns.
Concept explained simply
A Virtual Private Cloud (VPC) is your own private slice of the cloud network. You choose an IP range (CIDR), split it into subnets, and control how traffic flows in and out. Public subnets can reach the internet directly. Private subnets cannot be reached from the internet; they go out through a NAT. Security groups and network ACLs control what’s allowed.
- Core pieces: VPC (CIDR), Subnets (by AZ), Route Tables, Internet Gateway, NAT Gateway/Instance, Security Groups (stateful), Network ACLs (stateless), VPC Endpoints (private access to services), Peering/Transit Gateways (connect VPCs), VPN (connect on‑prem).
Mental model
Think of the VPC as a campus. Each building (subnet) sits in a zone (AZ). Public buildings have doors to the street (IGW). Private buildings have no street doors; they exit through a guarded side gate (NAT) for outbound only. Hall passes (security groups) let specific people in; perimeter rules (NACLs) affect entire hallways. Route tables are the campus maps telling you which path to take to reach a destination.
Key design decisions
1) IP range and growth
Pick a CIDR that avoids overlap with on‑prem and other VPCs. Give yourself room to grow (e.g., /16 for medium orgs, /20 for small sandboxes). Avoid 10.0.0.0/8 if your company already uses it elsewhere.
2) Subnet layout
Per AZ, create at least one public and one private subnet. Keep enough free subnets for future use (databases, services, internal tools). Align subnet sizes to expected pod/service counts (if running Kubernetes).
3) Egress strategy
Decide how private workloads reach the internet: NAT gateways/instances, or private endpoints to avoid internet entirely. NAT gateways are managed but cost per AZ; minimize cross‑AZ traffic to control costs.
4) Ingress strategy
Accept traffic via load balancers in public subnets. Terminate TLS at the edge and forward to private subnets. Lock down security groups to least privilege.
5) Connectivity and isolation
Separate environments (dev/stage/prod) by VPC or account/project. Use VPC peering or a transit hub to connect shared services. Enforce network policies and distinct CIDRs to avoid conflicts.
Worked examples
Example 1: Small startup, 2 AZs, web + DB
- VPC CIDR: 10.20.0.0/16
- Subnets per AZ: public /24, private-app /24, private-db /24
- AZ A: public 10.20.0.0/24, app 10.20.1.0/24, db 10.20.2.0/24
- AZ B: public 10.20.10.0/24, app 10.20.11.0/24, db 10.20.12.0/24
- Routing: public subnets route 0.0.0.0/0 to IGW; private subnets route 0.0.0.0/0 to NAT in their AZ.
- Security: LB in public SG allows 80/443 from internet; app SG allows from LB SG only; DB SG allows 5432 from app SG only.
Example 2: Staging and production isolation
- Two VPCs: staging 10.30.0.0/16 and prod 10.31.0.0/16. No overlap.
- Shared tooling VPC 10.100.0.0/16 (CI, observability) connected via a transit hub or peering with explicit route tables.
- Restrict flows: staging cannot reach prod; prod can reach shared tooling on specific ports. Separate accounts/projects for stronger blast radius control.
Example 3: Hybrid with on‑prem
- On‑prem: 172.16.0.0/12; choose VPC: 10.50.0.0/16 to avoid overlap.
- Site‑to‑site VPN terminates to a virtual private gateway or equivalent. Propagate routes to private subnets.
- DNS split-horizon: internal names resolve to private IPs, public names to LB addresses.
- Guardrails: on‑prem to prod limited to specific CIDRs and ports via security groups and route controls.
Design checklist
- Pick non‑overlapping CIDR with room to grow.
- Create at least two AZs; public + private subnets per AZ.
- Attach IGW; create NAT per AZ for private egress (or plan private endpoints).
- Separate routing per subnet type; avoid cross‑AZ NAT traffic.
- Define SGs per role (LB, app, DB); tighten to least privilege.
- Consider VPC endpoints for frequently used cloud services to keep traffic private and reduce NAT costs.
- Enable flow logs for troubleshooting (respect cost/storage policies).
- Plan naming: vpc-env-region, subnet-{public|private}-{az}, rt-{public|private}.
Exercises
These mirror the graded exercises below. Do them here first, then submit in the Exercises section. Tip: Write answers clearly; show CIDRs, routes, and reasoning.
Exercise 1 (Plan address space)
Design a 2‑AZ VPC for a web app with public, private‑app, and private‑db subnets. VPC CIDR is 10.60.0.0/16. Produce six /24 subnets (3 per AZ) and specify default routes for each subnet type.
- Deliverables: subnet CIDRs per AZ; route table targets for 0.0.0.0/0.
Exercise 2 (Route tables and endpoints)
In the same VPC, add private endpoints for object storage and secrets manager so app and db subnets can reach them without NAT. Show updated routes and indicate which traffic still uses NAT.
- Self‑check: Do any CIDRs overlap? Are NATs AZ-local? Are inbound rules least-privilege?
Common mistakes and how to self‑check
- Overlapping CIDRs across VPCs or with on‑prem. Self‑check: list all current CIDRs and compare before finalizing.
- Single NAT in one AZ. Self‑check: ensure each private subnet’s default route points to a NAT in the same AZ to avoid cross‑AZ charges and single points of failure.
- Putting databases in public subnets. Self‑check: DB subnets must have no route to IGW; only outbound via NAT if needed or endpoints.
- Too-small subnets. Self‑check: estimate peak instances/pods + headroom; prefer /24 for simplicity unless constrained.
- Wide-open security groups. Self‑check: use SG-to-SG references and limit ports.
Practical projects
- Create a 2‑AZ VPC with public and private subnets, deploy a public load balancer and a private app tier, verify inbound and outbound flows.
- Add VPC endpoints for object storage and secrets; measure reduced NAT traffic by checking NAT metrics before/after.
- Peering two VPCs (non‑overlapping CIDRs) and restricting routes to a shared internal service only.
Mini challenge
You must support a bursty batch job in private subnets that hits external APIs heavily for 1 hour/day. Minimize egress cost and keep resilience. What would you change in NAT, endpoints, or scheduling? Write a short plan with trade‑offs.
Next steps
- Take the Quick Test to check your understanding. Everyone can take it for free; only logged‑in users will see saved progress.
- Move on to load balancers and private access patterns.
- Revisit your IP plan before adding new environments to avoid conflicts.