Home > AWS Networking

ELI5: VPC, Subnets, and Security Groups - Building Your Private Neighborhood

Understanding AWS Networking Through City Planning

AWS VPC Networking Architecture Illustration

Imagine you're a city planner designing a new residential neighborhood from scratch. You need to decide where to put houses, which streets should be public vs private, and how to control traffic flow. This is exactly what you're doing when you set up a VPC (Virtual Private Cloud) in AWS - except instead of houses, you're placing servers, databases, and applications.

VPC: Your Private Gated Community

A VPC is like purchasing a large plot of land where you'll build your entire neighborhood. It's your private space within the larger AWS "city."

Key VPC Characteristics:

Private Address Space: Your own IP range (like 10.0.0.0/16)
Isolated Environment: Completely separated from other AWS customers
Custom Networking: You control all routing and access rules
Regional Scope: Each VPC exists in one AWS region

Default VPC vs Custom VPC:

Default VPC (pre-built neighborhood):

Pre-configured subnets in each availability zone
Internet gateway already attached
Good for: Quick prototypes, learning, simple apps

Custom VPC (design your own):

Complete control over layout and security
Better for: Production apps, complex requirements, compliance needs

Subnets: The Streets and Neighborhoods

Subnets are like individual streets within your VPC community:

Layout example:

VPC: 10.0.0.0/16 (Your entire community)
├── Public Subnet: 10.0.1.0/24 (Main Street - visible to internet)
├── Private Subnet: 10.0.10.0/24 (Residential street - internal only)
└── Database Subnet: 10.0.20.0/24 (High-security area)

Public vs Private Subnets

Public Subnets (Front Yard):

Connected to Internet Gateway
Resources get public IP addresses
Perfect for: Web servers, load balancers

Private Subnets (Backyard):

No direct internet connection
Access internet through NAT Gateway
Perfect for: Application servers, databases

Multi-AZ Design for High Availability:

VPC: 10.0.0.0/16
├── us-west-2a
│   ├── Public: 10.0.1.0/24 (Load balancers)
│   └── Private: 10.0.10.0/24 (App servers)
└── us-west-2b  
    ├── Public: 10.0.2.0/24 (Load balancers)
    └── Private: 10.0.11.0/24 (App servers)

Subnet sizing tip: AWS reserves 5 IP addresses in each subnet, so a /24 subnet (256 total) gives you 251 usable addresses.

Security Groups: Your Personal Security Guards

Security Groups are like having a personal security guard for each resource with a specific guest list.

Key Characteristics:

Stateful: Allow traffic in, response automatically allowed out
Default Deny: Block everything unless explicitly allowed
Instance Level: Apply to individual resources
Reference Other Groups: Create security chains

Real-World Security Group Example

Three-tier web application:

Internet → Load Balancer (Public-SG) → Web Servers (Web-SG) → App Servers (App-SG) → Database (DB-SG)

Web Server Security Group:

{
  "WebServer-SG": {
    "Inbound": [
      {"Port": 80, "Source": "0.0.0.0/0", "Note": "HTTP from anywhere"},
      {"Port": 443, "Source": "0.0.0.0/0", "Note": "HTTPS from anywhere"},
      {"Port": 22, "Source": "Office-IP-Range", "Note": "SSH from office only"}
    ]
  }
}

Application Server Security Group:

{
  "AppServer-SG": {
    "Inbound": [
      {"Port": 8080, "Source": "WebServer-SG", "Note": "Only from web servers"},
      {"Port": 22, "Source": "Bastion-SG", "Note": "SSH through bastion only"}
    ]
  }
}

Database Security Group:

{
  "Database-SG": {
    "Inbound": [
      {"Port": 3306, "Source": "AppServer-SG", "Note": "MySQL from app servers only"}
    ]
  }
}

Security Group Chaining Benefits

Automatic scaling: Add instances without updating security rules
Clear separation: Each tier only talks to its neighbors
Better security: No hardcoded IP addresses that might change

Cost Optimization Through Smart Networking

What's Free vs What Costs Money

Free:

VPC creation and basic operations
Security Groups and Network ACLs
Route tables and internal routing
Communication within same AZ

Costs Money:

NAT Gateways: $0.045/hour + $0.045/GB processed
VPC Endpoints: $0.01/hour + $0.01/GB (for interface endpoints)
Cross-AZ data transfer: $0.01/GB
Internet data transfer: $0.09/GB

Cost-Saving Strategies

Strategy 1: Smart NAT Gateway Usage

{
  "NATOptimization": {
    "Production": {
      "Setup": "Multi-AZ NAT Gateways",
      "Cost": "$97/month",
      "Justification": "High availability required"
    },
    "Development": {
      "Setup": "Single NAT Gateway with scheduling",
      "Schedule": "8 AM - 6 PM weekdays only",
      "Cost": "$16/month (75% savings)",
      "Justification": "Dev work only during business hours"
    }
  }
}

Strategy 2: VPC Endpoints for AWS Services

{
  "S3AccessExample": {
    "ViaNATGateway": "$45/month (NAT + data processing + transfer)",
    "ViaVPCEndpoint": "$0/month (S3 Gateway endpoint is free)",
    "AnnualSavings": "$540/year per heavy S3 user"
  }
}

Strategy 3: Same-AZ Placement

{
  "CrossAZOptimization": {
    "Problem": "Cross-AZ traffic costs $0.01/GB",
    "Solution": "Place frequently communicating resources in same AZ",
    "Example": {
      "BadDesign": "Web server in 2a, Database in 2b → $10/month data transfer",
      "GoodDesign": "Both in 2a → $0/month (use read replicas for HA)"
    }
  }
}

Common Networking Mistakes

Mistake 1: The "Open SSH" Security Hole

Wrong:

{"Port": 22, "Source": "0.0.0.0/0"}  // SSH open to entire internet!

Better options:

{"Port": 22, "Source": "Office-IP-Range"}  // Office only
{"Port": 22, "Source": "Bastion-SG"}       // Through bastion host  
{"Method": "AWS Systems Manager"}           // No SSH ports needed

Mistake 2: Poor Subnet Planning

Short-sighted design:

VPC: 10.0.0.0/24 (Only 254 addresses total!)

Growth-friendly design:

VPC: 10.0.0.0/16 (65,534 addresses)
├── Reserved space for future growth
└── Room for multiple environments

Mistake 3: Forgetting Outbound Rules

Security groups control BOTH inbound and outbound traffic:

Problem:

{
  "WebServer-SG": {
    "Inbound": [{"Port": 80, "Source": "0.0.0.0/0"}],
    "Outbound": []  // Forgot to allow outbound HTTPS!
  }
}

Result: Web server can receive requests but can't make API calls or download updates.

Step-by-Step: Building Your First VPC

Quick VPC Setup

# 1. Create VPC
VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query 'Vpc.VpcId' --output text)

# 2. Create Internet Gateway
IGW_ID=$(aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --vpc-id $VPC_ID --internet-gateway-id $IGW_ID

# 3. Create Public Subnet
PUBLIC_SUBNET=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.1.0/24 --query 'Subnet.SubnetId' --output text)

# 4. Create Private Subnet  
PRIVATE_SUBNET=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.10.0/24 --query 'Subnet.SubnetId' --output text)

# 5. Create Security Groups
WEB_SG=$(aws ec2 create-security-group --group-name WebServer-SG --description "Web servers" --vpc-id $VPC_ID --query 'GroupId' --output text)

# 6. Configure Security Group Rules
aws ec2 authorize-security-group-ingress --group-id $WEB_SG --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id $WEB_SG --protocol tcp --port 443 --cidr 0.0.0.0/0

Troubleshooting Common Issues

"My instance can't reach the internet"

Check:

Is instance in public or private subnet?
Does route table point to Internet Gateway (public) or NAT Gateway (private)?
Are security group outbound rules allowing HTTPS (443)?
Is Network ACL blocking traffic?

"Database connection timeouts"

Check:

Security group allows database port from application servers
Both resources are in same VPC
Network ACL isn't blocking traffic
Database is actually running and healthy

"High data transfer costs"

Solutions:

Place communicating resources in same AZ
Use VPC Endpoints for AWS service calls
Implement caching to reduce database queries
Monitor VPC Flow Logs to identify traffic patterns

Advanced Patterns

Bastion Host Pattern

Internet → Bastion (Public Subnet) → Private Servers (Private Subnet)

Instead of opening SSH to internet, use secure jump host:

{
  "Bastion-SG": {
    "Inbound": [{"Port": 22, "Source": "Office-IP"}],
    "Outbound": [{"Port": 22, "Target": "PrivateServers-SG"}]
  }
}

VPC Peering for Multi-Environment Access

{
  "VPCPeering": {
    "Production": "10.0.0.0/16",
    "Staging": "10.1.0.0/16", 
    "Use": "Share databases or monitoring between environments",
    "Cost": "$0.01/GB for data transfer"
  }
}

Your VPC Implementation Checklist

Week 1: Planning

Design IP address space with growth in mind
Plan public/private/database subnet layout
Map security requirements to security groups
Estimate networking costs

Week 2: Basic Setup

Create VPC with appropriate CIDR block
Set up public/private subnets across multiple AZs
Configure Internet Gateway and route tables
Create basic security groups

Week 3: Security & Optimization

Implement defense in depth (NACLs + Security Groups)
Set up VPC Flow Logs for monitoring
Configure VPC Endpoints for cost savings
Test connectivity and troubleshoot issues

Week 4: Monitoring & Documentation

Set up CloudWatch alerts for security events
Document network architecture for team
Plan for disaster recovery and scaling
Review and optimize costs

Key Takeaways

Understanding VPC networking is like mastering neighborhood design - it balances security, efficiency, and cost:

Security Benefits:

Defense in depth: Multiple security layers protect your resources
Isolation: Your environment is completely separate from other AWS customers
Controlled access: Only authorized traffic reaches your applications

Cost Benefits:

Smart NAT usage: Save $500-2000/month with scheduled NAT instances
VPC Endpoints: Save $200-1000/month on AWS service calls
Same-AZ placement: Eliminate cross-AZ data transfer charges

Operational Benefits:

Scalability: Add resources without redesigning network
Troubleshooting: Clear network boundaries simplify problem isolation
Compliance: Built-in logging and access controls support audit requirements

The investment in proper VPC design pays dividends in reduced costs, improved security, and better operational efficiency.

Need help optimizing your VPC costs while maintaining security? Huskar provides intelligent resource scheduling that works within your VPC security boundaries. Our network-aware optimization ensures cost-saving automation never compromises your carefully designed security architecture. Try our free tier to see how smart scheduling reduces AWS networking costs.

Tags:

AWS, VPC, Networking, Subnets, Security Groups, Cloud Architecture, Cost Optimization, ELI5

Ready to Cut Your Cloud Bill?

Join teams who are saving up to 65% — effortlessly.

Get Started Today