Introduction and Context
The Problem You Are Solving
Your organization is preparing to deploy a web application that consists of three layers: a public-facing load balancer, an application tier running business logic, and a database tier holding sensitive data. The default VPC in AWS is not suitable for this. It places every resource in a flat, publicly accessible network. There is no isolation between tiers, no control over traffic paths, and no concept of trust zones.
Your job is to design a VPC that enforces network isolation by construction. The public subnet holds only resources that must be reachable from the internet. The private subnet holds application servers that should never be directly reachable from the internet but need outbound access to pull packages, updates, and API calls. The database subnet holds data-tier resources that have no direct internet path in either direction.
This lab walks through building that network from scratch. By the end, you will have a functioning multi-tier VPC that a real workload can be deployed into.
What You Will Build
You will construct a VPC spanning two Availability Zones (AZs) with the following structure:
- One VPC:
10.0.0.0/16 - Per AZ: one public subnet, one private (application) subnet, one private (database) subnet
- An Internet Gateway attached to the VPC
- One NAT Gateway per AZ (or one shared NAT, discussed in the cost section)
- Route tables properly scoped to each subnet tier
- Three security groups: one for the load balancer tier, one for the application tier, one for the database tier — chained so that only the upstream tier is a permitted source
The measurable end result: a private EC2 instance in the application subnet can reach the internet (e.g., curl https://example.com succeeds), while no inbound path exists from the internet to that instance.
Architecture Overview
Architecture overview placeholder — full annotated diagram provided in Section 9.
In this section, I confirmed:
0 of 3 completed