Design and Build a Highly Available VPC

Design and build a production-style AWS VPC across 2 Availability Zones.

Introduction

30 Second Summary

Every time you use an app or visit a website, your request travels through a network of components that must be placed in exactly the right spots to keep things fast, secure, and online even when something breaks.

In this project, you will design, build, and document a highly available VPC architecture in AWS that spans multiple Availability Zones.

What You'll Build

A production-style highly available VPC architecture with public and private subnets, internet and NAT gateways, and route tables across 2 Availability Zones.

By the end of this project, you'll have:

A documented architecture diagram in Miro showing a highly available VPC with correct component placement and rationale.
A working custom VPC in AWS with 2 public subnets and 2 private subnets across 2 Availability Zones, with properly configured routing.
A written architecture document explaining why each component is placed where it is based on security and availability principles.
Secret Mission: Add security groups that enforce 3-tier network isolation between web, app, and database layers.

Are there any prerequisites?

You need an AWS account with console access. No prior VPC or networking experience is required.

Before We Start

Before We Start...

Set Up Your Tools

Building a VPC architecture without a plan leads to misplaced components and security gaps. You need both a design tool and a build tool ready before you start.

In this step, you'll sign into the AWS Console to confirm your networking dashboard is accessible. Then you'll create a Miro board where you'll sketch your architecture before building it.

In this step, get ready to:

Sign into the AWS Management Console and confirm the VPC Dashboard is accessible.
Create a free Miro account and a blank architecture board.

Sign into the AWS Console and open the VPC Dashboard

The VPC Dashboard is the central hub for managing all networking resources in AWS. You'll use it throughout this project to create and configure your VPC components.

Open your browser and go to https://console.aws.amazon.com/.
Sign in with your AWS account credentials.
In the top-right corner of the console, click the region selector dropdown.
Select us-east-1 (US East, N. Virginia). All resources in this project will be created in this region.
In the top search bar, type VPC and select VPC from the search results.
Confirm you can see Your VPCs in the left sidebar, and that a default VPC is listed.

What is the default VPC?

Every AWS account comes with a default VPC in each region. It is pre-configured with public subnets and an internet gateway so that instances can immediately connect to the internet.

You will not use the default VPC in this project. Instead, you'll create a custom VPC with a deliberate subnet layout designed for high availability and security.

Don't see a default VPC?

If no default VPC is listed, confirm that your region selector in the top-right corner shows us-east-1. Some regions may not have a default VPC if it was previously deleted.

A missing default VPC will not affect this project since you'll create a brand new custom VPC. As long as you can see the VPC Dashboard, you're good to proceed.

Why can't I see the VPC Dashboard or my default VPC?

Create a Miro account and architecture board

Miro is a visual collaboration tool where you'll diagram your VPC architecture before building it in AWS. Designing first helps you think through component placement and catch mistakes early.

Open a new browser tab and go to https://miro.com.
Sign up for a free account (or sign in if you already have one).
From your Miro dashboard, create a new blank board.
Name the board VPC Architecture.

What does the Miro free plan include?

The free plan gives you 3 editable boards and access to basic shapes, flowchart shapes, and connectors. That is everything you need for this project.

The official AWS icon shape packs require a paid plan. Labeled rectangles and arrows work perfectly for architecture diagrams.

Confirm your workspace is ready

You should now have two browser tabs open. One showing the AWS VPC Dashboard, and another with your blank Miro board.

Both workspaces are ready. Next up, you'll design the full VPC architecture in Miro and explain why each component belongs where it does.

Design the Architecture in Miro

Your AWS Console and Miro board are both ready. Before building anything in AWS, you need to design the architecture on paper first.

Designing first forces you to think about WHY each component sits where it does. This is the difference between following instructions blindly and making informed architectural decisions that you can explain in an interview.

In this step, get ready to:

Learn why each VPC component is placed in a specific subnet or zone.
Draw the complete architecture diagram in Miro with all components and traffic flows.
Review your diagram to confirm correct placement and labeling.

Understand the architecture components and their placement

The highly available VPC architecture you are building contains several components, each placed deliberately for security or availability reasons.

Before you draw anything, read through the following components and their placement rationale. Understanding the "why" behind each decision is the core skill this project teaches.

The VPC boundary and Internet Gateway

VPC (10.0.0.0/16): The overall network boundary. A /16 gives 65,536 IP addresses, which is plenty of room for subnets.
Internet Gateway (IGW): Attached at the VPC level. It is the single entry/exit point between the VPC and the public internet. It does not sit "inside" any subnet.

Why does the Internet Gateway attach to the VPC, not a subnet?

The Internet Gateway serves the entire VPC, not just one subnet. Public subnets route traffic to it. Private subnets do not.

Think of it as the front door of a building. The door belongs to the building itself, not to any individual room inside it.

Public subnets across two Availability Zones

Public Subnet AZ-1: 10.0.1.0/24 in Availability Zone 1.
Public Subnet AZ-2: 10.0.2.0/24 in Availability Zone 2.

Why are these subnets public, and why two of them?

A subnet is "public" because its route table has an entry pointing 0.0.0.0/0 to the Internet Gateway. Resources in these subnets can receive inbound traffic from the internet.

You need two subnets in two separate Availability Zones for high availability. If one AZ goes down, the other continues serving traffic.

Private subnets across two Availability Zones

Private Subnet AZ-1: 10.0.3.0/24 in Availability Zone 1.
Private Subnet AZ-2: 10.0.4.0/24 in Availability Zone 2.

Why are these subnets private?

These subnets have NO route to the Internet Gateway. Resources here cannot be reached directly from the internet.

Application and database servers are duplicated across both Availability Zones for the same high availability principle as the public subnets.

The NAT Gateway

NAT Gateway: Placed in a PUBLIC subnet (Public Subnet AZ-1).

Why does the NAT Gateway sit in a public subnet?

The NAT Gateway needs internet access itself so it can forward traffic on behalf of private instances. It must sit in a subnet that routes to the Internet Gateway.

Private subnet instances need outbound internet access for updates, patches, and API calls without being directly reachable from the internet. The NAT Gateway translates their private IPs to a public Elastic IP for outbound traffic only.

Server placement: web, application, and database tiers

Web Server: Placed in a PUBLIC subnet. Web servers must receive inbound HTTP/HTTPS traffic directly from the internet.
Application Server: Placed in a PRIVATE subnet. App servers process business logic but should never be directly accessible from the internet. They receive traffic only from the web tier.
Database Server: Placed in a PRIVATE subnet. Databases contain sensitive data and must never be exposed to the internet. They accept connections only from the application tier on specific ports.

Why this 3-tier placement pattern?

Each tier only communicates with the tier directly next to it. The internet talks to web servers, web servers talk to app servers, and app servers talk to databases.

This layered approach reduces the attack surface. Even if an attacker compromises the web tier, they cannot reach the database directly because no route or rule allows it.

Draw the architecture diagram in Miro

Now that you understand where each component goes and why, switch to your Miro board and draw the architecture.

Press R on your keyboard to activate the rectangle tool. Draw a large rectangle on the board.
Double-click the rectangle and type VPC 10.0.0.0/16 to label it.
Inside the VPC rectangle, draw two vertical columns. Label the left column AZ-1 and the right column AZ-2.

Quick shape shortcuts in Miro

Press R for rectangle, T for text, and L for connection line/arrow. You can also click the Shapes and lines icon on the left creation bar to browse all available shapes.

In the AZ-1 column, draw a box near the top and label it Public Subnet 10.0.1.0/24.
Below it in the same column, draw another box and label it Private Subnet 10.0.3.0/24.
In the AZ-2 column, draw a box near the top and label it Public Subnet 10.0.2.0/24.
Below it, draw another box and label it Private Subnet 10.0.4.0/24.

You now have four subnet boxes inside your VPC, split evenly across two Availability Zones.

At the top edge of the VPC rectangle (outside the AZ columns), draw or place a shape and label it Internet Gateway.
Inside the Public Subnet AZ-1 box, draw a small shape and label it NAT Gateway.
Place a Web Server icon or label inside each public subnet (one in AZ-1, one in AZ-2).
Place an App Server label inside each private subnet.
Place a Database label inside each private subnet (below or beside the App Server).

Now add the traffic flow arrows and route table labels to complete the diagram.

Press L to activate the connection line tool. Draw an arrow from the Internet Gateway down into the Public Subnet, pointing at the Web Server. This shows inbound traffic.
Draw an arrow from a Private Subnet up to the NAT Gateway, then from the NAT Gateway to the Internet Gateway. This shows outbound-only traffic from private resources.
Press T to add a text label near the public subnets: Public RT: 0.0.0.0/0 > IGW.
Add another text label near the private subnets: Private RT: 0.0.0.0/0 > NAT Gateway.

What do these route table labels mean?

The public route table entry 0.0.0.0/0 > IGW means "for any traffic destined for the internet, send it to the Internet Gateway." This is what makes a subnet public.

The private route table entry 0.0.0.0/0 > NAT Gateway means "for any outbound internet traffic, send it through the NAT Gateway." Inbound traffic from the internet cannot reach these subnets.

Review your diagram

Step back and verify your completed diagram against this checklist.

Confirm the VPC rectangle contains all four subnets, split across two AZ columns.
Confirm the Internet Gateway sits at the top edge of the VPC, not inside any subnet.
Confirm the NAT Gateway is inside Public Subnet AZ-1, not in a private subnet.
Confirm Web Servers are in public subnets, and App Servers and Databases are in private subnets.
Confirm your arrows show directionality: inbound traffic flows from Internet > IGW > Public Subnet > Web Server, and outbound-only traffic flows from Private Subnet > NAT Gateway > IGW > Internet.
Confirm route table labels are present near their respective subnets.

Diagram feeling cluttered?

Use different colors for public subnets (e.g., light blue) and private subnets (e.g., light orange) to visually separate the two types. You can change a shape's fill color by selecting it and using the color picker in the context menu.

If shapes are overlapping, select all objects with Cmd+A (macOS) or Ctrl+A (Windows) and spread them out. The important thing is that the logical relationships are correct, not pixel-perfect alignment.

Help me organize my VPC architecture diagram in Miro.

Your architecture diagram is complete. You now have a visual blueprint showing exactly what you will build in AWS. Next up, you will create this VPC and all its components in the AWS Console and verify the routing matches your design.

Build the VPC in AWS

Your architecture diagram is complete. You know exactly where every component belongs and why it sits there.

Now it's time to bring that design to life in the AWS Console. The VPC Console has a wizard called VPC and more that creates everything in one operation: the VPC, subnets, Internet Gateway, NAT Gateway, and route tables.

In this step, get ready to:

Create a custom VPC with 4 subnets across 2 Availability Zones using the console wizard.
Verify all created resources match your architecture diagram.
Examine route tables to confirm public subnets route to the Internet Gateway and private subnets route to the NAT Gateway.

Create the VPC using the console wizard

The VPC and more wizard creates all your networking resources at once. This matches what you designed in Miro: a VPC with public and private subnets, an Internet Gateway, and a NAT Gateway.

In the VPC Dashboard, click the orange Create VPC button in the top-right area.
For Resources to create, choose VPC and more.

Why VPC and more?

The VPC only option creates an empty VPC shell with nothing inside it. VPC and more creates the full set of networking resources (subnets, route tables, gateways) in one step. This saves you from creating each component individually.

For Name tag auto-generation, enter ha-vpc.
For IPv4 CIDR block, enter 10.0.0.0/16.

What does the name tag do?

AWS uses the name you enter to auto-generate names for all the resources it creates. With ha-vpc entered, your VPC becomes ha-vpc-vpc, your Internet Gateway becomes ha-vpc-igw, and so on. This keeps everything organized.

For Number of Availability Zones (AZs), choose 2.
For Number of public subnets, choose 2.
For Number of private subnets, choose 2.
For NAT gateways, choose In 1 AZ.
For VPC endpoints, choose None.
Click Create VPC.

Why only 1 NAT Gateway?

In production, AWS recommends deploying a NAT Gateway in each Availability Zone for fault tolerance. For this learning project, 1 NAT Gateway is sufficient to demonstrate the concept.

The NAT Gateway costs $0.045 per hour. You will delete it at the end of this project to avoid ongoing charges. Even if you delete within 5 minutes, you pay for 1 full hour ($0.045).

AWS takes a moment to create all the resources. You should see a green success banner and a list of all created resources with green checkmarks.

Seeing an error during creation?

If you see an error about exceeding limits, your account may have hit the default quota for VPCs or Elastic IPs in that region. Try a different region, or check that you don't already have 5 VPCs in the selected region.

help me troubleshoot my VPC creation error in the AWS Console

Verify the created resources

The wizard created all your networking resources. Now confirm they match the architecture you designed in Miro.

In the left sidebar, click Your VPCs.
Confirm you see ha-vpc-vpc listed with State Available and IPv4 CIDR 10.0.0.0/16.
In the left sidebar, click Subnets.
Filter by your VPC to see only the 4 subnets you created.
Confirm you see 2 public subnets and 2 private subnets spread across 2 Availability Zones.

What should I see in the Subnets list?

You should see 4 subnets with names following this pattern:

ha-vpc-subnet-public1-us-east-1a (CIDR 10.0.1.0/24)
ha-vpc-subnet-public2-us-east-1b (CIDR 10.0.2.0/24)
ha-vpc-subnet-private1-us-east-1a (CIDR 10.0.3.0/24)
ha-vpc-subnet-private2-us-east-1b (CIDR 10.0.4.0/24)

In the left sidebar, click Internet gateways.
Confirm ha-vpc-igw is listed with State Attached and linked to your VPC.
In the left sidebar, click NAT gateways.
Confirm your NAT Gateway shows Status Available, sits in a public subnet, and has an Elastic IP address assigned.

NAT Gateway still showing Pending?

NAT Gateways take a few minutes to provision. Wait 1-2 minutes and refresh the page. The status should change from Pending to Available.

help me check if my NAT Gateway is provisioning correctly

Examine the route tables

Route tables are the rules that determine where network traffic goes. The wizard created separate route tables for your public and private subnets. This is what makes a subnet "public" or "private."

In the left sidebar, click Route tables.
Filter by your VPC to see only the route tables associated with ha-vpc-vpc.
Click the public route table (the one associated with your public subnets).
Select the Routes tab at the bottom of the page.

You should see two routes: 10.0.0.0/16 targeting local (traffic stays within the VPC) and 0.0.0.0/0 targeting the Internet Gateway (igw- prefix). This is what makes the public subnets public.

Now click on a private route table (associated with your private subnets).
Select the Routes tab.

You should see two routes: 10.0.0.0/16 targeting local and 0.0.0.0/0 targeting the NAT Gateway (nat- prefix). Private subnets route outbound internet traffic through the NAT Gateway instead of directly to the Internet Gateway.

Click the Subnet associations tab to verify which subnets are linked to each route table.
Confirm the public route table is associated with both public subnets, and the private route table is associated with both private subnets.

Why does routing determine public vs private?

A subnet is "public" only because its route table has a route sending 0.0.0.0/0 (all internet-bound traffic) to the Internet Gateway. A "private" subnet routes that same traffic to the NAT Gateway instead. There is no inherent property that makes a subnet public or private. It is entirely determined by routing.

Don't see separate route tables?

Make sure you filter the route tables view by your ha-vpc-vpc VPC. You should see at least 2 route tables: one for public subnets (routes to igw-) and one for private subnets (routes to nat-).

help me find and understand my VPC route tables

Your VPC is fully built and matches the architecture you designed. Next up, you'll document everything with resource IDs and clean up the NAT Gateway to avoid charges.

Document the Architecture and Delete the NAT Gateway

Your VPC is live with all networking components in place across two Availability Zones. The route tables confirm that public subnets reach the internet through the Internet Gateway, and private subnets route outbound traffic through the NAT Gateway.

In this step, you'll capture all resource IDs and configuration details in your architecture documentation. Then you'll delete the NAT Gateway to stop the $0.045/hour charge from accumulating.

In this step, get ready to:

Record all resource IDs, CIDR blocks, and routing details in your Miro board.
Verify the AWS resources match your architecture diagram.
Delete the NAT Gateway and release its Elastic IP to avoid ongoing charges.

Record your architecture details

Having a record of your resource IDs and configurations is essential for troubleshooting, onboarding teammates, and referencing in future projects. You'll pull these details from the AWS Console and add them to your Miro board.

Return to the VPC Console in your browser.
Click Your VPCs in the left sidebar.
Note down the VPC ID for ha-vpc-vpc and confirm the CIDR block is 10.0.0.0/16.
Click Subnets in the left sidebar.
For each of the 4 subnets, note the subnet ID, CIDR block, Availability Zone, and whether it is public or private.
Click Internet gateways in the left sidebar and note the Internet Gateway ID.
Click NAT gateways in the left sidebar and note the NAT Gateway ID and which subnet it sits in.
Click Route tables in the left sidebar and note the route table IDs along with their routes (destinations and targets).

What to record for each subnet

Your 4 subnets should look like this:

ha-vpc-subnet-public1-us-east-1a: 10.0.1.0/24 in us-east-1a (public).
ha-vpc-subnet-public2-us-east-1b: 10.0.2.0/24 in us-east-1b (public).
ha-vpc-subnet-private1-us-east-1a: 10.0.3.0/24 in us-east-1a (private).
ha-vpc-subnet-private2-us-east-1b: 10.0.4.0/24 in us-east-1b (private).

Switch back to your Miro board.
Add a text note to your board listing all the resource IDs, CIDR blocks, Availability Zones, and route table routes you just collected.

Why document resource IDs?

Resource IDs (like vpc-0abc123 or subnet-0def456) are the unique identifiers AWS assigns to each resource. In production, teams reference these IDs when troubleshooting connectivity issues, writing infrastructure-as-code, or onboarding new engineers.

Verify the architecture matches your design

Before moving on, compare the live AWS resources against your Miro diagram to confirm everything was created correctly.

Confirm your public subnets have a route table entry pointing 0.0.0.0/0 to the Internet Gateway (ha-vpc-igw).
Confirm your private subnets have a route table entry pointing 0.0.0.0/0 to the NAT Gateway.
Confirm your resources are spread across 2 Availability Zones (us-east-1a and us-east-1b).
Check that the component placement in your Miro diagram matches what you see in the console. The Internet Gateway should be at the VPC level, the NAT Gateway inside a public subnet, and the web/app/database server labels in the correct subnet types.

This is your architecture documentation: the diagram plus the resource details plus the rationale you wrote in Step 2.

Delete the NAT Gateway to avoid charges

The NAT Gateway charges $0.045 per hour, and partial hours are billed as full hours. Deleting it now means you pay for at most one hour. The remaining resources (VPC, subnets, Internet Gateway, and route tables) are completely free.

In the VPC Console, click NAT gateways in the left sidebar.
Select your NAT Gateway by clicking its checkbox.
Click Actions, then select Delete NAT gateway.
Type delete in the confirmation field.
Click Delete.
Wait for the status to change to Deleted. This may take 1-2 minutes.

Why delete the NAT Gateway but keep everything else?

The NAT Gateway is the only resource in this project with an hourly charge. VPCs, subnets, route tables, and Internet Gateways are free to keep running indefinitely.

Keeping the free resources is useful if you want to build on this VPC in a future project or continue into the Secret Mission.

Now you need to release the Elastic IP that was allocated for the NAT Gateway. An unassociated Elastic IP incurs a small charge, so releasing it stops that cost too.

Click Elastic IP addresses in the left sidebar (under the Virtual private cloud section).
Select the Elastic IP that was allocated for the NAT Gateway. Its Association ID column will show empty or - since the NAT Gateway was deleted.
Click Actions, then select Release Elastic IP addresses.
Click Release in the confirmation dialog.

Can't find the Elastic IP?

Make sure you've waited for the NAT Gateway status to show Deleted before looking for the Elastic IP. While the NAT Gateway is still deleting, the Elastic IP remains associated and won't appear as unassociated.

Also confirm you're looking in the correct region (check the region selector in the top-right corner of the console).

Help me find the Elastic IP from my NAT Gateway

Cost summary

The NAT Gateway costs $0.045 per hour. Deleting it immediately means you pay for at most 1 hour ($0.045 total). The VPC, subnets, Internet Gateway, and route tables are free and can remain indefinitely.

Secret mission

Enforce 3-Tier Security with Security Groups

Your VPC has the right network layout, but there's nothing stopping traffic from flowing freely between tiers. Can you create security groups that enforce strict isolation, where each layer only accepts traffic from the layer directly above it?

Clean Up Your Resources

This project's remaining resources (VPC, subnets, Internet Gateway, route tables, and security groups) are all free. If you deleted the NAT Gateway and released the Elastic IP in Step 4, you have no ongoing charges regardless of whether you keep the VPC.

Decide whether to keep your resources for future projects or delete them entirely.

Resources you used:

VPC ha-vpc-vpc with 4 subnets, Internet Gateway, route tables, and security groups (Free).
NAT Gateway (already deleted in Step 4, no longer incurring the $0.045/hour charge).
Elastic IP (already released in Step 4).
Miro board "VPC Architecture" (Free, on the Miro free plan).

Keep everything running

No action needed. Choose this if you plan to use this VPC for future projects or want to reference the architecture later.

The VPC, subnets, Internet Gateway, route tables, and security groups cost nothing to keep.
Your Miro board is free and stays on your account.
The NAT Gateway and Elastic IP are already deleted, so there are zero ongoing charges.

Pause - I'll come back to this later

There are no running processes to pause in this project. All remaining resources are static and free.

The VPC and its components sit idle at no cost.
You can return anytime and pick up where you left off.
If you later launch EC2 instances or another NAT Gateway inside this VPC, those new resources will incur charges.

Delete - I don't want to use this again

Remove all project resources and start fresh. This deletes the VPC and everything inside it in one action.

In the VPC Console, click Your VPCs in the left sidebar.
Select the checkbox next to ha-vpc-vpc.
Choose Actions, then Delete VPC.
The confirmation page shows associated resources (subnets, route tables, Internet Gateway, security groups) that will also be deleted. Review the list.
Type delete in the confirmation field and choose Delete.
Your Miro board is free and does not cost anything to keep. If you want to remove it, open your Miro workspace and delete the "VPC Architecture" board from the board list.

What gets deleted?

The Delete VPC action removes the VPC and all associated subnets, route tables, security groups (non-default), and Internet Gateway in one operation. You do not need to delete each resource individually.

Nice Work!

You just designed, built, and documented a production-style highly available VPC architecture in AWS. That is a core networking skill that underpins every cloud deployment.

You learned how to:

Designed a highly available VPC architecture spanning 2 Availability Zones, explaining why each component (IGW, NAT Gateway, web/app/DB servers) sits where it does based on security and availability principles.
Built the VPC in AWS with 2 public subnets, 2 private subnets, an Internet Gateway, a NAT Gateway, and properly configured route tables.
Documented the architecture with resource IDs, CIDR blocks, and routing configurations in a professional architecture diagram in Miro.
Secret Mission: Created security groups enforcing 3-tier isolation where each layer only accepts traffic from the layer above it.

Ready to quiz yourself?