Project: Design a VPC with Public and Private Components

As with every hands-on project so far in this course, you can design this directly in a real AWS account or work through it entirely on paper. If you do build any of this in a real account, review your current Free Tier eligibility and current pricing for VPC-related services first — several of the components below (NAT resources, load balancers, public IPv4 addresses, Route 53) can have cost implications independent of each other, and none of them should be assumed automatically free.

Bringing every lesson in this module together into one request path:

Internet
  → Route 53 (Lesson 6) — resolves a domain name to the load balancer
  → Load Balancer (Lesson 7) — distributes traffic, health-checks targets
  → Public subnets across 2 AZs (Lessons 1–2) — hold the load balancer / ingress layer
  → Application targets (EC2) — in public or private subnets depending on design, reached only via the load balancer's Security Group
  → Private subnets (Lesson 2) — hold the application tier and the database
  → Database — never directly reachable from the internet (Module 5)

At least two Availability Zones are used throughout, per Lesson 7's resiliency reasoning — never a single-AZ design for anything meant to stay available.

This is the actual point of the exercise — not memorizing the diagram, but being able to justify each placement:

• Route 53 sits in front of everything because users need a memorable name, not a raw address, and DNS is the layer that resolves one to the other (Lesson 6).
• The load balancer sits in public subnets because it's the one component genuinely meant to be reachable from the internet — and its own Security Group, not a wide-open rule, is what controls that (Lesson 5).
• Application targets are reached only from the load balancer's Security Group, never directly from the internet — the web/app-tier pattern Lesson 5 described.
• The database sits in a private subnet with a Security Group allowing inbound only from the application tier's Security Group — Module 5's warning against direct database exposure, enforced here at the network layer.
• NAT (Lesson 4) gives the private application tier outbound access for updates or external API calls, without ever accepting a new inbound connection initiated from the internet.
• Route tables for the private subnets deliberately carry no 0.0.0.0/0 → Internet Gateway route (Lesson 3) — that route belongs only where a subnet is genuinely meant to be reachable from outside.

If any part of this was built in a real account, work through this checklist before considering the project finished — some of these have dependencies on each other, so order matters: a component often can't be deleted while something else still depends on it.

1. Delete or deregister the load balancer first, since other resources may depend on it.
2. Delete associated target groups, if any were created separately from the load balancer.
3. Release NAT resources created for this project, and any Elastic IP/public IP addresses allocated for them or for the load balancer.
4. Remove Route 53 records and, if created solely for this training exercise, the hosted zone itself.
5. Delete Security Groups created for this project, once nothing still references them.
6. Delete subnets, then route tables, then detach and delete the Internet Gateway, and finally delete the VPC itself — roughly the reverse order of how the pieces were created, since AWS won't let you delete a VPC that still contains dependent resources.
7. Confirm nothing training-related remains by checking the VPC dashboard directly — the same "verify, don't assume" discipline every earlier module's project applied to its own resources.