AWS: Understanding VPC, Subnets, and Networking Basics


Introduction

Behind every AWS application — from a simple EC2 instance to a complex microservices architecture — lies a foundation of networking.

The Virtual Private Cloud (VPC) is the backbone of that foundation, giving you full control over how resources connect, communicate, and stay secure.

In this blog, we’ll break down VPCs, subnets, routing, and essential AWS networking concepts that every developer, architect, and cloud enthusiast should understand.


What Is a VPC?

A Virtual Private Cloud (VPC) is a logically isolated network within the AWS cloud where you can launch and manage your resources.

Think of it as your own private data center — hosted inside AWS — with customizable IP ranges, routing, and security boundaries.

Each AWS account comes with a default VPC, but production environments typically use custom VPCs to tailor networking, segmentation, and security rules.


Key Features of a VPC

  • Custom IP addressing: Define your own CIDR block (e.g., 10.0.0.0/16).
  • Subnet segmentation: Divide networks for different availability zones or functions.
  • Routing control: Manage traffic flow using route tables.
  • Internet connectivity: Attach an Internet Gateway (IGW) or NAT Gateway.
  • Security layers: Use Security Groups and Network ACLs (NACLs) to protect traffic.

CIDR Blocks Explained

CIDR (Classless Inter-Domain Routing) defines the IP address range of your VPC.

Example:

10.0.0.0/16 → provides 65,536 IPs (from 10.0.0.0 to 10.0.255.255).

The smaller the suffix number, the larger the range.

For subnets, you create smaller blocks within your VPC, e.g.:

  • 10.0.1.0/24 → 256 IPs
  • 10.0.2.0/24 → another 256 IPs

AWS reserves 5 IPs in every subnet (first 4 + last 1) for internal operations.


Subnets: Dividing the VPC

Subnets are logical divisions of your VPC used to group and isolate resources.

Each subnet resides in one Availability Zone (AZ) — this improves fault tolerance and scalability.

Two Major Types

  1. Public Subnet:
    • Connected to the Internet via an Internet Gateway (IGW).
    • Used for resources that need public access (e.g., web servers).
    • Example route: 0.0.0.0/0 → Internet Gateway.
  2. Private Subnet:
    • No direct Internet access.
    • Communicates externally via a NAT Gateway (for outbound traffic).
    • Ideal for databases, internal APIs, and sensitive workloads.

Internet Gateway vs NAT Gateway

Feature Internet Gateway (IGW) NAT Gateway
Purpose Enables Internet access for public subnets Allows outbound traffic from private subnets
Direction Inbound + Outbound Outbound only
Attached To Entire VPC Specific private subnet
Used By EC2 instances with public IPs EC2 instances without public IPs

Route Tables

Route Tables define how traffic flows inside the VPC.

Each subnet must be associated with exactly one route table, which determines where packets go based on destination CIDR ranges.

Example:

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

Here, 10.0.0.0/16 traffic stays within the VPC (local), and 0.0.0.0/0 goes to the Internet Gateway.

You can also set routes to VPC Peering, Transit Gateway, or VPN connections for hybrid setups.


Security Layers in AWS Networking

AWS provides two key network security controls:

1. Security Groups (SGs)

  • Operate at the instance level.
  • Stateful — if inbound traffic is allowed, the response is automatically allowed.
  • Example rule: Allow inbound SSH (port 22) from your IP.

2. Network ACLs (NACLs)

  • Operate at the subnet level.
  • Stateless — both inbound and outbound rules must be defined.
  • Useful for restricting subnet-level access or adding extra layers of defense.

Availability Zones and Multi-AZ Design

AWS regions are made up of multiple Availability Zones (AZs) — physically separated data centers with redundant networking and power.

When designing your VPC:

  • Create subnets across multiple AZs for high availability.
  • Deploy load balancers and redundant resources across AZs to prevent single points of failure.

Example:

Region: ap-south-1
- Subnet A: 10.0.1.0/24 (AZ a)
- Subnet B: 10.0.2.0/24 (AZ b)

This setup ensures your application stays available even if one AZ experiences downtime.


Diagram: AWS VPC Architecture – How It Works

AWS VPC Architecture – How It Works

Figure: Illustration showing how an Amazon Virtual Private Cloud (VPC) connects subnets, route tables, gateways, and instances to enable secure networking within AWS. Source: AWS Documentation – Amazon VPC User Guide


Example VPC Architecture

Scenario: A basic 3-tier AWS network.

VPC (10.0.0.0/16)
│
├── Public Subnet (10.0.1.0/24) → EC2 Web Servers + Load Balancer
│      └── Route → Internet Gateway
│
├── Private App Subnet (10.0.2.0/24) → EC2 App Tier
│      └── Route → NAT Gateway
│
└── Private DB Subnet (10.0.3.0/24) → RDS Database
       └── No direct Internet access

This simple setup covers:

  • Separation of public and private traffic
  • Controlled Internet access
  • Secure database isolation

Best Practices

  • Use least privilege network design — restrict traffic by need.
  • Always log and monitor with VPC Flow Logs.
  • Use PrivateLink for secure service-to-service communication.
  • Prefer NAT Gateway over NAT Instance for better scalability.
  • Implement multi-AZ redundancy for production VPCs.

Conclusion

The VPC is the backbone of AWS networking — defining how securely and efficiently your resources interact.

Mastering subnets, route tables, and gateways gives you the power to build networks that are not only performant but also resilient and compliant.

Understanding these fundamentals is the first step toward architecting scalable, secure, and cloud-native infrastructures on AWS.


References

  • AWS VPC Documentation (🔗 Link)
  • AWS Subnets and CIDR Blocks Guide (🔗 Link)
  • AWS Route Tables and Internet Gateway (🔗 Link)
  • AWS Security Groups vs Network ACLs (🔗 Link)
  • AWS Architecture Blog: Designing VPCs for Scalability and Security (🔗 Link)

Rethought Relay:
Link copied!

Comments

Add Your Comment

Comment Added!