AWS VPC Tutorial (2025): Step-by-Step Guide to Build a Production-Ready VPC

Imagine your manager walks over and says, “We need a secure AWS network for production — can you set it up today?” That’s the exact scenario this AWS VPC tutorial prepares you for. By the end, you’ll have built a real, production-grade Virtual Private Cloud from scratch — the same architecture I’ve deployed dozens of times this guide is written for DevOps engineers, cloud beginners, and SAA-C03 learners who want a practical, step-by-step AWS VPC tutorial they can follow in a real AWS account.

I’m Srikanth, a Senior DevOps Engineer, and I’ve seen too many engineers struggle with VPC concepts because they learned theory without building anything real. This hands-on tutorial flips that approach. We’re going to create vpc in aws step by step, and I’ll share the same insights I’ve picked up from years of production networking work.

If you’re preparing for the AWS Solutions Architect exam (SAA-C03) or simply want to stop feeling lost when someone mentions “route tables” in a meeting, this aws vpc setup guide is exactly what you need.

TL;DR — What You’ll Build

• Create a VPC with CIDR 10.0.0.0/16 (65,536 IP addresses)
• Add 6 subnets (public, private app, private DB) across 2 Availability Zones
• Attach an Internet Gateway for public internet access
• Create public route table pointing to IGW
• Create private route table pointing to NAT Gateway (optional)
• Configure Security Groups for web → app → db traffic flow
• Deploy EC2 instances to verify connectivity works
• Clean up all resources to avoid NAT Gateway costs

Total time: 45–60 minutes

What is AWS VPC?

Amazon Virtual Private Cloud (VPC) is your own isolated section of the AWS cloud. Think of it as renting an entire floor in a massive office building — you control who comes in, how the rooms connect, and what security measures you put in place. Everything else in AWS (EC2, RDS, Lambda) lives inside a VPC.

For a deeper dive into AWS VPC architecture, CIDR planning strategies, and multi-VPC design patterns, check out our AWS VPC Fundamentals & Network Design Guide — it covers the concepts behind everything you’ll build today.

For official documentation, AWS provides comprehensive coverage in their VPC User Guide.

Why DevOps Engineers Must Master VPC

Every production workload runs inside a VPC. If you can’t design and troubleshoot networking, you’ll hit a wall in your DevOps career. I’ve interviewed candidates who could write beautiful Terraform but froze when asked why their private subnet couldn’t reach the internet. This aws vpc beginner tutorial ensures you won’t be that person.

What You Will Build (Architecture Overview)

By the end of this vpc subnets tutorial, you’ll have a fully functional three-tier VPC architecture spanning two Availability Zones. Here’s what we’re creating:

VPC Foundation

• VPC CIDR: 10.0.0.0/16 (65,536 IP addresses)
• Region: us-east-1 (N. Virginia)

Subnet Layout

• 2 Public Subnets (for load balancers, bastion hosts)
• 2 Private Application Subnets (for your app servers)
• 2 Private Database Subnets (for RDS, ElastiCache)

Networking Components

• Internet Gateway for public internet access
• NAT Gateway (optional) for private subnet outbound traffic
• Route Tables controlling traffic flow
• Security Groups acting as instance-level firewalls

Test Deployment

• EC2 instances to verify connectivity

This is the exact pattern used by companies running production workloads. Master this, and you’ve mastered the foundation of AWS networking.

Estimated Cost Summary

Before we begin, here’s what this lab costs:

⚠️ Bottom line: This entire lab is effectively free if you skip the NAT Gateway, or if you create it, test it, and delete it immediately. NAT Gateway is the only significant cost.

Prerequisites

Before we start this aws vpc hands-on tutorial, make sure you have:

• AWS Account — A free tier account works perfectly
• IAM User with Admin Access — Never use your root account for labs
• Region Selected — We’ll use us-east-1, but any region works
• Basic Understanding of IP Addresses — Know what a CIDR block means (10.0.0.0/16)
• 45–60 Minutes — Set aside uninterrupted time

Lab 1 — Create Your VPC

⏱️ Time: 5 minutes

Let’s build the foundation. The VPC is the container that holds everything else.

Step-by-Step Instructions:

1. Sign into the AWS Management Console
2. Navigate to VPC (search “VPC” in the top search bar)
3. Click Your VPCs in the left sidebar
4. Click Create VPC
5. Configure the following:

• Resources to create: VPC only
• Name tag: tutorial-vpc
• IPv4 CIDR block: 10.0.0.0/16
• IPv6 CIDR block: No IPv6 CIDR block
• Tenancy: Default

1. Click Create VPC

Enable DNS Hostnames (Important):

By default, AWS disables DNS hostnames on manually created VPCs. Without this, your public instances won’t receive public DNS names.

1. Select your newly created tutorial-vpc
2. Click Actions → Edit VPC settings
3. Check Enable DNS hostnames
4. Click Save

💡 Pro Tip: Always enable DNS hostnames. You’ll need them when instances need to resolve each other by hostname, and it’s required for certain AWS services like EFS.

Verification:

You should see your new VPC in the list with state “Available.” Click on it and confirm the CIDR block shows 10.0.0.0/16 and DNS hostnames shows “Enabled.”

🧪 What Just Happened?

You’ve created an isolated network with 65,536 possible IP addresses. Nothing can communicate in or out yet — it’s completely empty. Think of it as purchasing land before building a house.

🤔 Reflection Prompt:
Why do production teams prefer /16 VPCs even when they only need a few hundred IPs today?

The answer: future-proofing. I’ve seen teams paint themselves into corners with /24 VPCs, then scramble when they needed to add new subnets for a microservices migration. A /16 gives you room to grow for years. IP addresses inside a VPC are free — there’s no reason to be stingy.

Lab 2 — Create Public, Private, and Database Subnets

⏱️ Time: 10 minutes

Subnets divide your VPC into smaller networks. The magic of AWS networking is that subnets in different Availability Zones give you fault tolerance — if one data center has issues, your app keeps running.

We’re creating six subnets following this exact plan:

For detailed documentation on subnet configuration, see AWS’s Subnet Basics Guide.

Step-by-Step Instructions:

1. In the VPC console, click Subnets in the left sidebar
2. Click Create subnet
3. Select your tutorial-vpc from the VPC dropdown
4. Under Subnet settings, enter:

• Subnet name: public-a
• Availability Zone: us-east-1a
• IPv4 CIDR block: 10.0.1.0/24

1. Click Add new subnet to add more subnets in the same operation
2. Repeat for all six subnets using the table above
3. Click Create subnet

Enable Auto-Assign Public IP (Public Subnets Only):

1. Select public-a from the subnet list
2. Click Actions → Edit subnet settings
3. Check Enable auto-assign public IPv4 address
4. Save
5. Repeat for public-b

⚠️ Critical Warning: Never enable auto-assign public IP on private subnets — that defeats the entire purpose of keeping them private and exposes your backend servers to the internet.

💡 Pro Tip: AWS reserves 5 IP addresses in every subnet for internal use (network address, router, DNS, future use, and broadcast). A /24 subnet gives you 256 addresses, but only 251 are usable. Always account for this when planning capacity.

Lab 3 — Attach an Internet Gateway

⏱️ Time: 3 minutes

Right now, your VPC is completely isolated. An Internet Gateway (IGW) is the door that connects your VPC to the public internet.

Step-by-Step Instructions:

1. In the VPC console, click Internet gateways
2. Click Create internet gateway
3. Enter name: tutorial-igw
4. Click Create internet gateway
5. You’ll see a green banner — click Attach to VPC
6. Select tutorial-vpc
7. Click Attach internet gateway

What Does an IGW Actually Do?

The Internet Gateway performs two critical functions. First, it provides a target for your route tables to direct internet-bound traffic. Second, it allows instances with public IPs (or Elastic IPs) to send and receive traffic from the internet using a 1:1 public-to-private mapping at the AWS edge. Without an IGW attached, even instances with public IPs can’t reach the internet.

💡 Pro Tip:

• One IGW per VPC — that’s all you need. It scales automatically and has no bandwidth constraints. You’ll never need to “size” an Internet Gateway.
• Internet Gateways are fully managed and free — you never pay per-hour for an IGW.

Lab 4 — Create Route Tables (Public and Private)

⏱️ Time: 10 minutes

Route tables are the traffic cops of your VPC. They contain rules that determine where network traffic goes. This is where the “public” and “private” subnet distinction actually happens — it’s not the subnet itself, but the route table associated with it.

For comprehensive route table documentation, see AWS’s Route Tables Guide.

Create the Public Route Table:

1. Click Route tables in the left sidebar
2. Click Create route table
3. Configure:

• Name: public-rt
• VPC: tutorial-vpc

1. Click Create route table

Add Internet Route to Public Route Table:

1. Select public-rt
2. Click the Routes tab
3. Click Edit routes
4. Click Add route
5. Configure:

• Destination: 0.0.0.0/0
• Target: Select Internet Gateway, then choose tutorial-igw

1. Click Save changes

Associate Public Subnets:

1. Click the Subnet associations tab
2. Click Edit subnet associations
3. Select public-a and public-b
4. Click Save associations

Create the Private Route Table:

1. Click Create route table
2. Configure:

• Name: private-rt
• VPC: tutorial-vpc

1. Click Create route table
2. Leave the routes as-is (only the local route for now)

Associate Private Subnets:

1. Click Subnet associations tab
2. Click Edit subnet associations
3. Select all four private subnets: private-app-a, private-app-b, private-db-a, private-db-b
4. Click Save associations

⚠️ Common Mistake: Forgetting to associate subnets with route tables. Unassociated subnets use the main route table, which might not have the routes you expect.

🧪 Mini Quiz:
Which routing rule makes a subnet “public”?

Answer: The route 0.0.0.0/0 → Internet Gateway. This rule says “send all internet-bound traffic to the IGW.” Without this route, even a subnet with public IP instances can’t reach the internet. The route table, not the subnet itself, determines public vs. private.

🤔 Reflection Prompt:
If your instance has a public IP but cannot reach the internet, which three things would you check first?

Hint: route table association, Internet Gateway attachment, and Security Group outbound rules are usually the culprits.

Lab 5 — (Optional) NAT Gateway for Private Subnet Outbound Access

⏱️ Time: 8 minutes

Your private subnets are secure — nothing from the internet can reach them. But what if your application servers need to download updates or call external APIs? That’s where NAT Gateway comes in.

⚠️ Cost Alert: NAT Gateway charges ~$0.045/hour (~$32/month) plus $0.045 per GB of data processed. For this lab, we’ll create it, test it, and delete it immediately. In production, budget for this cost or consider alternatives like NAT instances.

Want to reduce NAT costs? Read our VPC Endpoints Guide: Access S3/DynamoDB Without NAT Costs to learn how to bypass NAT for AWS service traffic.

Step-by-Step Instructions:

1. Navigate to NAT gateways in the VPC console
2. Click Create NAT gateway
3. Configure:

• Name: tutorial-nat
• Subnet: Select public-a (NAT Gateway must live in a public subnet)
• Connectivity type: Public
• Elastic IP allocation ID: Click Allocate Elastic IP

1. Click Create NAT gateway
2. Wait 2-3 minutes for status to become “Available”

Update Private Route Table:

1. Go to Route tables
2. Select private-rt
3. Click Routes → Edit routes
4. Click Add route
5. Configure:

• Destination: 0.0.0.0/0
• Target: Select NAT Gateway, then choose tutorial-nat

1. Click Save changes

The DevOps Logic:

With this in place, Now your private instances can reach the internet for outbound requests (downloading packages, calling APIs), but nobody on the internet can initiate a connection to them. This is exactly what you want for application and database tiers.

💡 Pro Tip: The difference between NAT Gateway and Internet Gateway confuses many beginners. IGW enables two-way internet communication for public instances. NAT Gateway enables one-way outbound-only communication for private instances. Think of NAT as a one-way mirror — your servers can see out, but nobody can see in.

🚀 Production Tip: For high availability, deploy one NAT Gateway per Availability Zone. If your single NAT Gateway fails, all private subnets lose outbound connectivity. I’ve seen this take down production systems during AZ outages.

Lab 6 — Security Groups and EC2 Testing

⏱️ Time: 15 minutes

Security Groups are your instance-level firewalls. Unlike NACLs (which are stateless), Security Groups are stateful — if you allow traffic in, the response automatically goes out.

For a detailed comparison, check out our Security Groups vs NACLs: When to Use Each guide.

Create Three Security Groups:

1. Web Security Group (sg-web)

1. Go to Security Groups in the VPC console
2. Click Create security group
3. Configure:

• Name: sg-web
• Description: Allow HTTP/HTTPS from internet
• VPC: tutorial-vpc

1. Inbound rules — Add:

• Type: HTTP, Source: 0.0.0.0/0
• Type: HTTPS, Source: 0.0.0.0/0
• Type: SSH, Source: Your IP (use “My IP”)

1. Click Create security group

2. Application Security Group (sg-app)

1. Create another security group
2. Configure:

• Name: sg-app
• Description: Allow traffic from web tier
• VPC: tutorial-vpc

1. Inbound rules — Add:

• Type: Custom TCP, Port: 8080, Source: Select sg-web
• Type: SSH, Source: sg-web

1. Click Create security group

3. Database Security Group (sg-db)

1. Create another security group
2. Configure:

• Name: sg-db
• Description: Allow traffic from app tier
• VPC: tutorial-vpc

1. Inbound rules — Add:

• Type: MYSQL/Aurora, Port: 3306, Source: Select sg-app

1. Click Create security group

Deploy Test EC2 Instances:

1. Navigate to EC2 console
2. Click Launch instance

Launch Web Instance (Public):

• Name: web-test
• AMI: Amazon Linux 2023
• Instance type: t2.micro (free tier)
• Key pair: Create or select existing
• Network settings:
• VPC: tutorial-vpc
• Subnet: public-a
• Auto-assign public IP: Enable
• Security group: Select sg-web
• Click Launch instance

Launch App Instance (Private):

• Name: app-test
• AMI: Amazon Linux 2023
• Instance type: t2.micro
• Key pair: Same as above
• Network settings:
• VPC: tutorial-vpc
• Subnet: private-app-a
• Auto-assign public IP: Disable
• Security group: Select sg-app
• Advanced details → User data: Paste this script to start a simple web server:

#!/bin/bash
# Start a dummy web server on port 8080
echo "Hello from the Private App Tier!" > /home/ec2-user/index.html
cd /home/ec2-user
python3 -m http.server 8080 &

• Click Launch instance

💡 Why User Data? A raw Amazon Linux instance has nothing listening on port 8080. The Security Group allows the traffic through, but without an application running, the OS rejects connections. This script starts a simple Python web server for testing.

Connectivity Test:

1. Wait for both instances to show “Running” status
2. Copy the public IP of web-test
3. SSH into the public instance:

ssh -i your-key.pem ec2-user@<public-ip-of-web-test>

4. From inside web-test, get the private IP of app-test from the EC2 console
5. Test connectivity to the app tier:

curl http://<private-ip-of-app-test>:8080

Expected output:

Hello from the Private App Tier!

🚀 Success! You’ve just verified that your public instance can reach your private instance through the Security Group chain.

🤔 Reflection Prompt:
Why are Security Group references (like sg-web) safer than CIDR-based rules?

Answer: Security Group references are dynamic. When instances scale up or down, new instances automatically inherit the correct access. With CIDR rules, you’d need to update IP ranges manually — a nightmare for auto-scaling environments. I once debugged a production outage caused by hardcoded IPs in security groups after an infrastructure change. Always use SG references between tiers.

Lab 7 — Clean Up to Avoid Costs

⏱️ Time: 10 minutes

This is critical. AWS will happily charge you for forgotten resources. Follow this exact order — dependencies matter.

Cleanup Checklist:

1. Terminate EC2 instances

   EC2 Console → Instances → Select both → Instance state → Terminate

Wait for termination to complete.

2. Delete NAT Gateway (if created)

   VPC Console → NAT Gateways → Select tutorial-nat → Actions → Delete

Wait for deletion to complete (2-3 minutes).

3. Release Elastic IP

   VPC Console → Elastic IPs → Select → Actions → Release

⚠️ Unattached EIPs cost $0.005/hour!

4. Delete Subnets

   VPC Console → Subnets → Select all 6 tutorial subnets → Actions → Delete

5. Detach and Delete Internet Gateway

   VPC Console → Internet Gateways → Select tutorial-igw → Actions → Detach → Delete

6. Delete Route Tables

   Delete public-rt and private-rt (can't delete main route table)

7. Delete Security Groups

   Delete sg-web, sg-app, sg-db (can't delete default SG)

8. Delete VPC

   VPC Console → Your VPCs → Select tutorial-vpc → Actions → Delete

💡 Pro Tip: If deletion fails, check for dependencies. AWS won’t delete a VPC with active resources inside it. The error message usually tells you what’s blocking deletion.

Common VPC Mistakes (Avoid These)

Before we wrap up, here are the mistakes I see engineers make repeatedly — learn from their pain:

❌ Using a single NAT Gateway across AZs — If that AZ fails, all private subnets lose internet access. Deploy one NAT per AZ in production.

❌ Forgetting to associate subnets with route tables — Unassociated subnets inherit the main route table, which often doesn’t have the routes you expect.

❌ Putting databases in public subnets — I’ve seen RDS instances with public IPs. Never do this. Databases belong in private subnets with no internet route.

❌ Overlapping CIDR blocks across environments — If your dev VPC uses 10.0.0.0/16 and prod uses the same, you can never peer them or connect via Transit Gateway.

❌ Using /24 VPCs with no room for growth — A /24 gives you 251 usable IPs total. One subnet. You’ll regret this within months.

❌ Leaving Elastic IPs unattached — AWS charges for idle EIPs. If you’re not using it, release it.

❌ Mixing public and private resources in same subnet — Subnet security is all-or-nothing. Don’t put a bastion host and database server in the same subnet.

❌ Hardcoding IPs in Security Groups — Use Security Group references for inter-tier communication. IPs change; SG references don’t.

Real-World DevOps Notes

Now that you’ve built this architecture, here’s what changes in production:

Multiple NAT Gateways for High Availability

In production, deploy one NAT Gateway per AZ. Create separate private route tables for each AZ pointing to its local NAT Gateway. This prevents cross-AZ traffic (which costs money) and provides fault tolerance.

VPC Design for Multiple Environments

Most teams use separate VPCs for dev, staging, and production. Some use separate AWS accounts entirely. The architecture you built today becomes a template you deploy repeatedly with Terraform or CloudFormation.

Future-Proof Your CIDR Blocks

Plan your CIDR ranges across all VPCs upfront. If you ever need VPC Peering or Transit Gateway, overlapping CIDRs will block you. I use a spreadsheet tracking every VPC’s CIDR range across all accounts.

VPC Flow Logs for Debugging

Enable VPC Flow Logs on day one. When something can’t connect, Flow Logs show you exactly what traffic is being accepted or rejected. They’ve saved me countless hours troubleshooting “it worked yesterday” problems.

Infrastructure as Code

Here’s a small Terraform snippet that mirrors part of what you built manually — this is how you’d start turning today’s console clicks into Infrastructure as Code:

Everything you clicked through today should be codified in Terraform or CloudFormation for production. Here’s a Terraform snippet for the VPC you just built:

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "tutorial-vpc"
  }
}

resource "aws_subnet" "public_a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = true

  tags = {
    Name = "public-a"
  }
}

The manual console approach is perfect for learning, but production infrastructure needs version control and repeatability.

When to Use VPC Endpoints

If your private instances need to access S3, DynamoDB, or other AWS services, use VPC Endpoints instead of routing through NAT Gateway. It’s cheaper, faster, and more secure.

Transit Gateway for Complex Architectures

Once you have multiple VPCs needing to communicate, Transit Gateway replaces the spaghetti of VPC Peering connections. It’s your central hub for all VPC-to-VPC and VPC-to-on-premises traffic.

Conclusion

You’ve just built a production-ready VPC — the exact foundation that runs real applications at real companies. This three-tier architecture with public, private, and database subnets is the starting point for almost every AWS deployment I’ve designed.

More importantly, you now understand why each component exists. You know why route tables determine public vs. private, why Security Group references beat CIDR rules, and why NAT Gateways cost money but solve a real problem.

This isn’t just exam knowledge. This is the stuff that makes the difference between a junior engineer who follows tutorials and a senior engineer who designs systems.

👉 What’s Next?

Read the AWS VPC Fundamentals & Network Design Guide (2025)

Learn CIDR planning strategies, multi-VPC design patterns, Transit Gateway architecture, VPC Peering scenarios, and exam-level networking questions. It’s the theory behind everything you built today.

Now go build something. Tear this VPC down and recreate it from memory. Then do it again in a different region. Then automate it with Terraform. That’s how you cement this knowledge. You’ve got this.

FAQs

Written by Srikanth Ch, Senior DevOps Engineer at thedevopstooling.com