Three-Tier Application VPC Scenario

Goal

This section turns the chapter into a real design answer. The point is not to produce the only correct VPC layout. The point is to practice explaining why the paths and boundaries make sense.

Scenario

A company is deploying a customer-facing application on AWS. It has:

a public web entry point
private application services
a private database tier
some outbound calls to external APIs
future plans to add more services and shared platform components

The business wants a design that is simple enough to launch now, but structured enough that growth does not force a full redesign in six months.

The Short Version

The architecture answer should sound like this:

I would use one VPC with separate subnets for public entry, private application services, and private data across multiple Availability Zones. Route tables would make only the entry tier internet-facing. Application services could use controlled outbound access through NAT if needed, and the database tier would stay on private paths only. I would also choose address space that leaves room for growth and future connectivity.

That answer is strong because it explains the path logic, not just the objects.

One Possible Layout

Internet
  -> Public subnets / load balancers
  -> Private application subnets
  -> Private data subnets

Private application subnets
  -> NAT gateway for approved outbound internet access

Private data subnets
  -> Local VPC paths only

Spread each tier across at least two Availability Zones when the workload needs better resilience. The specific resource names can change later. The important structure is the same:

only the public entry tier accepts internet traffic
the application tier stays private
the data tier stays even narrower
outbound access is intentional, not automatic

Walk the Traffic Path

Start outside the VPC. Public users should reach a managed entry point such as a load balancer in public subnets. Those subnets are public because their route tables support the internet path and because the entry point is meant to be reachable.

Next, traffic moves to private application subnets. Those subnets should not be directly reachable from the internet. Their job is to run application logic, not to be public addresses.

Then traffic moves to the data tier. The database subnets should stay on internal paths only. If the application is public, that does not make the database public by association.

Finally, consider outbound traffic. If the application tier needs internet egress, that path should be explicit through NAT. If some services do not need internet access at all, do not give it to them by default.

Why This Design Ages Better

This layout gives the team room to grow:

more application services can join the private application subnets or adjacent ones
database components remain clearly separated
future inspection or endpoint patterns can be added without rewriting the whole mental model
shared services or transit connectivity can appear later if needed

The design is not "future proof" in the magical sense. It is simply future-friendly because the boundaries are clear.

Trade-Offs to Explain

Decision	Benefit	Trade-Off
Tiered subnets	Clear separation of entry, application, and data paths.	More routing and subnet planning than a flat layout.
Multi-AZ placement	Better resilience to one Availability Zone failure.	More resources, more coordination, and possibly more cost.
NAT-based egress	Allows outbound access without direct inbound reachability.	Adds cost and should not be broader than necessary.
Private database tier	Stronger isolation and simpler security reasoning.	Requires clean operational access patterns for maintenance and troubleshooting.

Common Mistakes

Drawing a three-tier diagram without walking the reader through actual routes.
Making the application tier public because it feels convenient during initial setup.
Giving the database tier unnecessary outbound internet paths.
Choosing a VPC CIDR that leaves no room for future subnet growth or adjacent environments.

If Someone Asks You

How would you design a practical AWS VPC for a three-tier application?

A good answer is:

I would start with one VPC sized for growth, then place public entry, private application, and private data tiers in separate subnets across multiple Availability Zones. Route tables would make only the entry tier public. The application tier could use controlled NAT egress when needed, and the data tier would stay private. The main goal is to make each traffic path intentional and easy to explain.

What You Should Remember

Good VPC design is a story about intended traffic paths, not a diagram full of unlabeled boxes.

Questions to Check Your Understanding

Which components in this scenario usually need public reachability?
Why is NAT an egress design choice rather than a general connectivity shortcut?
How does early address planning make this design easier to grow later?