AWS VPC Tutorial: Virtual Private Cloud Setup, Subnets, Security Configuration [2025]

Why shouldn't your database have a public IP? Why should Web Servers and Databases be in different subnets? Why do identical security group settings sometimes allow connections and sometimes not? The answers to all these questions lie in VPC.

VPC is the foundation of AWS network architecture. Understanding VPC enables you to design secure, reliable cloud architectures. This article will guide you through VPC from the ground up—from basic concepts and core components to actually building a standard three-tier architecture.

---

What is AWS VPC?

VPC (Virtual Private Cloud) is your private network in the AWS cloud. Think of it as carving out a dedicated area just for you within AWS's data center, with your own IP range, subnets, and routing rules.

Core Value of VPC

1. Isolation

VPCs are completely isolated from each other. Your resources can't be seen or accessed by other users.

2. Control

You have complete control over network settings:

• IP address ranges
• Subnet divisions
• Route tables
• Network gateways
• Security rules

3. Connectivity

VPCs can connect to:

• Internet (via Internet Gateway)
• Corporate networks (via VPN or Direct Connect)
• Other VPCs (via VPC Peering or Transit Gateway)

VPC vs Traditional Networks

Aspect	Traditional Enterprise Network	AWS VPC
Setup Time	Weeks to months	Minutes
Scalability	Limited by hardware	Virtually unlimited
Configuration	Physical devices + CLI	AWS Console / API
Cost	Hardware + maintenance	Pay as you go
Cross-region	Requires dedicated lines	Native support

Why Do You Need VPC?

When you create EC2, RDS, Lambda, and other resources on AWS, they need a network environment. VPC is that environment.

Problems without VPC:

• All resources exposed to public internet
• Can't control access between resources
• Can't connect to corporate networks
• Can't meet compliance requirements

Benefits of VPC:

• Database in private subnet, only application layer can access
• Web Server in public subnet, can receive internet traffic
• Clear security boundaries and traffic control
• Compliance with finance, healthcare, and other industry regulations

---

VPC Core Components

To understand VPC, you need to know these core components:

Subnets

A subnet is an IP address block within a VPC. Each subnet maps to one Availability Zone (AZ).

Public Subnet vs Private Subnet

Feature	Public Subnet	Private Subnet
Can receive internet traffic	Yes	No
Can initiate internet connection	Yes (via IGW)	Need NAT Gateway
What to place here	Web Server, Bastion Host	Database, App Server
Route table points to	Internet Gateway	NAT Gateway

Subnet Planning Example:

VPC: 10.0.0.0/16 (65,536 IPs)
│
├── Public Subnet 1:  10.0.1.0/24 (256 IP) - AZ-a
├── Public Subnet 2:  10.0.2.0/24 (256 IP) - AZ-b
├── Private Subnet 1: 10.0.11.0/24 (256 IP) - AZ-a
├── Private Subnet 2: 10.0.12.0/24 (256 IP) - AZ-b
├── DB Subnet 1:      10.0.21.0/24 (256 IP) - AZ-a
└── DB Subnet 2:      10.0.22.0/24 (256 IP) - AZ-b

Route Tables

Route tables determine where network traffic should go. Each subnet is associated with one route table.

Public Subnet Route Table:

Destination	Target
10.0.0.0/16	local (within VPC)
0.0.0.0/0	igw-xxxxx (Internet Gateway)

Private Subnet Route Table:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	nat-xxxxx (NAT Gateway)

Internet Gateway (IGW)

Internet Gateway allows resources within VPC to communicate with the internet.

Features:

• Each VPC can have only one IGW
• Highly available, managed by AWS
• Free (no gateway fee itself)
• Supports IPv4 and IPv6

Requirements for use:

1. VPC has IGW attached
2. Subnet route table has route pointing to IGW
3. Instance has Public IP or Elastic IP
4. Security group allows traffic

NAT Gateway

NAT Gateway allows private subnet resources to initiate connections to the internet (e.g., download updates), but internet cannot initiate connections in.

Features:

• One-way: only from inside to outside
• Deployed in public subnet
• Highly available (single AZ), recommend one per AZ
• Pricing: $0.045/hour + data processing fee

Architecture Diagram:

                    Internet
                        │
                        ▼
                ┌───────────────┐
                │Internet Gateway│
                └───────┬───────┘
                        │
        ┌───────────────┼───────────────┐
        │               │               │
        ▼               ▼               ▼
   ┌─────────┐    ┌─────────┐    ┌─────────┐
   │ Public  │    │ Public  │    │   NAT   │
   │ Subnet  │    │ Subnet  │    │ Gateway │
   │(Web Tier)│   │(Web Tier)│   │         │
   └─────────┘    └─────────┘    └────┬────┘
                                      │
                    ┌─────────────────┘
                    ▼
              ┌─────────┐
              │ Private │
              │ Subnet  │
              │(App/DB) │
              └─────────┘

Security Groups

Security Groups are instance-level firewalls that control traffic entering and leaving instances.

Features:

• Stateful: If inbound traffic is allowed, response is automatically allowed out
• Default denies all inbound traffic
• Default allows all outbound traffic
• Can only set allow rules, not deny rules

Common Configuration Examples:

Type	Protocol	Port	Source	Description
SSH	TCP	22	10.0.0.0/16	Only allow SSH from within VPC
HTTP	TCP	80	0.0.0.0/0	Allow everyone HTTP
HTTPS	TCP	443	0.0.0.0/0	Allow everyone HTTPS
MySQL	TCP	3306	sg-app	Only allow from App tier security group

Network ACL (NACL)

NACL is a subnet-level firewall, serving as a second line of defense.

Features:

• Stateless: Inbound and outbound rules must be configured separately
• Rules have sequence numbers, evaluated from lowest to highest
• Can set both allow and deny rules
• Default NACL allows all traffic

Security Group vs NACL:

Aspect	Security Group	NACL
Level	Instance	Subnet
State	Stateful	Stateless
Rule Types	Allow only	Allow and Deny
Rule Evaluation	All evaluated	Sequential evaluation
Default	Deny all in, allow all out	Allow all

General recommendation: Primarily use Security Groups for control, with NACL as an additional protection layer.

---

Subnet Planning

Good subnet planning is key to VPC design.

CIDR Block Planning

CIDR (Classless Inter-Domain Routing) defines IP address ranges.

Common CIDRs:

CIDR	IP Count	Use Case
/16	65,536	VPC
/20	4,096	Large subnet
/24	256	Standard subnet
/28	16	Small subnet

Private IP Ranges (RFC 1918):

• 10.0.0.0 - 10.255.255.255 (10.0.0.0/8)
• 172.16.0.0 - 172.31.255.255 (172.16.0.0/12)
• 192.168.0.0 - 192.168.255.255 (192.168.0.0/16)

Planning Recommendations:

• VPC uses /16 (reserve enough space)
• Subnets use /24 (256 IPs, 251 actually usable)
• Avoid overlapping with corporate network IP ranges

Public vs Private Subnets

Public Subnets:

• Route table has 0.0.0.0/0 route pointing to IGW
• Instances can get public IPs
• Suitable for: Web Server, Bastion Host, NAT Gateway

Private Subnets:

• Route table has no direct route to IGW
• Instances only have private IPs
• Suitable for: Application Server, Database, internal services

Multi-AZ Design

For high availability, deploy resources in at least two AZs.

Standard Three-Tier Architecture:

                     VPC: 10.0.0.0/16
    ┌─────────────────────────────────────────────┐
    │                                             │
    │   AZ-a                      AZ-b            │
    │   ┌─────────────┐          ┌─────────────┐  │
    │   │ Public      │          │ Public      │  │
    │   │ 10.0.1.0/24 │          │ 10.0.2.0/24 │  │
    │   │   [ALB]     │──────────│   [ALB]     │  │
    │   └──────┬──────┘          └──────┬──────┘  │
    │          │                        │         │
    │   ┌──────▼──────┐          ┌──────▼──────┐  │
    │   │ Private     │          │ Private     │  │
    │   │ 10.0.11.0/24│          │ 10.0.12.0/24│  │
    │   │   [EC2]     │──────────│   [EC2]     │  │
    │   └──────┬──────┘          └──────┬──────┘  │
    │          │                        │         │
    │   ┌──────▼──────┐          ┌──────▼──────┐  │
    │   │ DB Subnet   │          │ DB Subnet   │  │
    │   │ 10.0.21.0/24│          │ 10.0.22.0/24│  │
    │   │   [RDS]     │◄─────────│   [RDS]     │  │
    │   └─────────────┘ Primary   └─────────────┘  │
    │                   Standby                   │
    └─────────────────────────────────────────────┘

---

VPC Security Configuration

Security Group Design Principles

1. Principle of Least Privilege

Only open necessary ports, restrict sources as much as possible.

❌ Wrong: Open 0.0.0.0/0 access to database
✓ Correct: Only allow application layer security group to access database

2. Layered Design

Each tier has its own security group:

Tier	Security Group	Allow Source
Web Tier	sg-web	0.0.0.0/0 (80, 443)
App Tier	sg-app	sg-web (8080)
DB Tier	sg-db	sg-app (3306)

3. Use Security Group References

Don't use IPs, use security group IDs as sources:

❌ Source: 10.0.11.0/24
✓ Source: sg-app

Benefit: Rules remain effective even if IPs change.

Security Group Examples

Web Server (sg-web):

Direction	Type	Port	Source/Destination
Inbound	HTTP	80	0.0.0.0/0
Inbound	HTTPS	443	0.0.0.0/0
Inbound	SSH	22	sg-bastion
Outbound	All	All	0.0.0.0/0

Application Server (sg-app):

Direction	Type	Port	Source/Destination
Inbound	Custom	8080	sg-web
Inbound	SSH	22	sg-bastion
Outbound	MySQL	3306	sg-db
Outbound	HTTPS	443	0.0.0.0/0

Database (sg-db):

Direction	Type	Port	Source/Destination
Inbound	MySQL	3306	sg-app
Outbound	All	All	0.0.0.0/0

NACL Best Practices

Usually keep default NACL (allow all), primarily rely on Security Groups for control.

Scenarios needing NACL:

• Need to explicitly deny specific IPs
• Compliance requires subnet-level control
• As an additional security layer

NACL Configuration Example:

Rule #	Direction	Type	Port	Source	Action
100	Inbound	HTTP	80	0.0.0.0/0	Allow
110	Inbound	HTTPS	443	0.0.0.0/0	Allow
120	Inbound	SSH	22	10.0.0.0/16	Allow
130	Inbound	Custom	1024-65535	0.0.0.0/0	Allow
*	Inbound	All	All	0.0.0.0/0	Deny

Note: Because it's stateless, you need to allow ephemeral ports (1024-65535) for response traffic.

Get the network architecture right, and security naturally improves

VPC design seems simple, but the devil is in the details. How to divide subnets? How to design security groups? How many NAT Gateways? These decisions affect security, performance, and cost.

The CloudInsight team has extensive VPC architecture experience. Schedule a free consultation and let us design a secure, efficient network architecture for you.

---

VPC Creation Tutorial

Here are complete steps to create a standard three-tier architecture VPC.

Step 1: Create VPC

1. Go to AWS Console > VPC
2. Click "Create VPC"
3. Select "VPC and more" (automatically creates subnets, route tables, etc.)

Settings:

• Name tag: my-vpc
• IPv4 CIDR: 10.0.0.0/16
• Number of AZs: 2
• Number of public subnets: 2
• Number of private subnets: 2
• NAT gateways: In 1 AZ (cost-saving) or 1 per AZ (high availability)
• VPC endpoints: None (add later as needed)

4. Click "Create VPC"

Step 2: Review Created Resources

AWS automatically creates:

• 1 VPC
• 2 public subnets
• 2 private subnets
• 1 Internet Gateway
• 1-2 NAT Gateways
• Corresponding route tables

Step 3: Verify Route Tables

Public subnet route table should have:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	igw-xxxxx

Private subnet route table should have:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	nat-xxxxx

Step 4: Create Security Groups

Web Tier Security Group (sg-web):

1. VPC > Security Groups > Create security group
2. Settings:
   • Name: sg-web
   • VPC: my-vpc
3. Inbound rules:
   • HTTP (80) from 0.0.0.0/0
   • HTTPS (443) from 0.0.0.0/0

App Tier Security Group (sg-app):

1. Settings:
   • Name: sg-app
   • VPC: my-vpc
2. Inbound rules:
   • Custom TCP (8080) from sg-web

DB Tier Security Group (sg-db):

1. Settings:
   • Name: sg-db
   • VPC: my-vpc
2. Inbound rules:
   • MySQL (3306) from sg-app

Step 5: Test Connectivity

Create Test EC2:

1. Create EC2 in public subnet (select sg-web)
2. Verify you can SSH from internet
3. Verify you can ping external websites

Test Private Subnet:

1. Create EC2 in private subnet (select sg-app)
2. Connect via jump from public subnet EC2
3. Verify you can ping external websites (via NAT Gateway)
4. Verify external cannot connect directly

---

VPC Best Practices

Network Design

1. Reserve Enough IP Space

• VPC uses /16
• Reserve subnets for future expansion

2. Deploy Across Multiple AZs

• At least 2 AZs
• Critical services consider 3 AZs

3. Use VPC Flow Logs

• Record all network traffic
• Used for security analysis and troubleshooting

Security Design

1. Layered Protection

• Security Group: Primary control
• NACL: Additional defense
• WAF: Application layer protection

2. Limit SSH/RDP Access

• Use Bastion Host
• Or use Systems Manager Session Manager (more secure)

3. Regularly Review Security Groups

• Remove unnecessary rules
• Avoid 0.0.0.0/0 access to sensitive ports

Cost Optimization

1. NAT Gateway Costs

• $0.045/hour + $0.045/GB
• May be the largest cost item in VPC
• Consider NAT Instance (cheaper but self-managed)

2. VPC Endpoints

• Access S3, DynamoDB, etc. without going through NAT Gateway
• Gateway Endpoint: Free (S3, DynamoDB)
• Interface Endpoint: Charged

3. Cross-AZ Traffic

• Traffic within same AZ is free
• Cross-AZ traffic $0.01/GB
• Consider data flow direction when designing

---

FAQ

Why can't EC2 connect to the internet?

Checklist:

1. ✓ EC2 in public subnet?
2. ✓ Subnet route table has route pointing to IGW?
3. ✓ EC2 has Public IP or Elastic IP?
4. ✓ Security group allows outbound traffic?
5. ✓ NACL allows traffic?

How does private subnet access the internet?

Use NAT Gateway:

1. Create NAT Gateway in public subnet
2. Add 0.0.0.0/0 → NAT Gateway to private subnet route table

VPC Peering vs Transit Gateway?

• VPC Peering: 1-to-1 connection, free but doesn't support transitive routing
• Transit Gateway: Central hub, supports multiple VPCs, charged

Use Peering for few VPCs, Transit Gateway for many VPCs.

How to connect to corporate network?

Options:

1. Site-to-Site VPN: Encrypted connection over internet
2. Direct Connect: Dedicated line, more stable but higher cost
3. Client VPN: Remote users connect to VPC

---

Next Steps

VPC is the foundation of all AWS architecture. Master VPC, and you can design secure, reliable cloud environments.

Recommended Learning Path:

1. Hands-on: Build three-tier architecture VPC, deploy simple application
2. Security: Design layered security groups
3. Connectivity: Try VPC Peering
4. Advanced: Transit Gateway, Direct Connect

Need a second opinion on your VPC architecture?

Network architecture mistakes can lead to security vulnerabilities or unexpectedly high costs. The CloudInsight team has helped hundreds of enterprises design VPC architectures, with rich experience in both new builds and migrations.

Schedule a free architecture consultation and let us review and optimize your VPC design.

---

Further Reading

• AWS Complete Guide: Services, Pricing, Certifications, Resources Explained
• AWS EC2 Complete Tutorial: Instance Types, Pricing, Implementation Guide
• AWS S3 Complete Tutorial: Storage Classes, Pricing, Implementation Guide
• AWS Lambda Getting Started Guide: Serverless Computing Tutorial, Pricing, Use Cases
• AWS Pricing Complete Guide: Pricing Models, Calculator Tutorial, Cost Saving Tips

---

Illustration: VPC Architecture Overview

Scene Description: VPC architecture overview diagram. A large box represents the VPC, internally divided into public and private subnets. Shows Internet Gateway at VPC boundary connecting to internet, NAT Gateway in public subnet, arrows showing traffic direction.

Visual Focus:

• Main content clearly presented

Required Elements:

• Key elements as described

Required Text: None

Color Scheme: Professional, clear

Avoid: Abstract graphics, gears, glowing effects

Slug: vpc-architecture-overview

Illustration: Security Group vs NACL Comparison

Scene Description: Security Group vs NACL comparison diagram. Left side shows Security Group surrounding a single EC2 instance (instance-level), right side shows NACL surrounding entire subnet (subnet-level). Highlights stateful vs stateless difference.

Visual Focus:

• Main content clearly presented

Required Elements:

• Key elements as described

Required Text: None

Color Scheme: Professional, clear

Avoid: Abstract graphics, gears, glowing effects

Slug: security-group-vs-nacl

Illustration: Three-Tier Architecture Detailed Diagram

Scene Description: Three-tier architecture detailed diagram. Vertically arranged three tiers: Web tier (public subnet with ALB), App tier (private subnet with EC2), DB tier (private subnet with RDS). Arrows show traffic flow, security groups at each tier boundary.

Visual Focus:

• Main content clearly presented

Required Elements:

• Key elements as described

Required Text: None

Color Scheme: Professional, clear

Avoid: Abstract graphics, gears, glowing effects

Slug: vpc-three-tier-architecture

Illustration: VPC Routing Explained

Scene Description: VPC routing explanation diagram. Flowchart showing a packet's journey from internet to private subnet EC2, passing through IGW, route table, NAT Gateway, with decision points at each step.

Visual Focus:

• Main content clearly presented

Required Elements:

• Key elements as described

Required Text: None

Color Scheme: Professional, clear

Avoid: Abstract graphics, gears, glowing effects

Slug: vpc-routing-explained