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

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

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?

💡 Key Takeaway: 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

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

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:

Private Subnet Route Table:

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:

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:

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:

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:

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):

Application Server (sg-app):

Database (sg-db):

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:

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 CloudSwap 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:

Private subnet route table should have:

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 CloudSwap 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

Need Professional Cloud Advice?

Whether you're evaluating cloud platforms, optimizing existing architecture, or looking for cost-saving solutions, we can help

Book Free Consultation