Understanding Virtual Private Clouds

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

Think of a VPC as your own private data center within AWS. It provides the network foundation upon which all your cloud resources operate. Every AWS account comes with a default VPC in each region, but for production workloads, you'll want to design custom VPCs tailored to your specific requirements.

Why Custom VPCs Matter

Default VPCs are convenient for getting started, but production workloads require custom VPCs. They give you full control over IP addressing, network isolation, security boundaries, and enable advanced architectures like multi-tier applications and hybrid cloud connectivity.

CIDR Blocks and IP Addressing

When you create a VPC, you must specify an IPv4 CIDR block. This defines the range of IP addresses available within your VPC. The CIDR block size must be between /16 (65,536 addresses) and /28 (16 addresses). Choosing the right CIDR block is one of the most important decisions you'll make — it's difficult to change later.

CIDR Block	IP Addresses	Typical Use Case
/16	65,536	Large enterprise VPC
/20	4,096	Medium-sized production workload
/24	256	Small application or test environment
/28	16	Minimal isolated subnet

Common CIDR Block Sizes and Their Use Cases

network-topology.txt

Plain Text

VPC CIDR: 10.0.0.0/16
├── Public Subnet A (us-east-1a):   10.0.1.0/24   [256 addresses]
├── Public Subnet B (us-east-1b):   10.0.2.0/24   [256 addresses]
├── Private Subnet A (us-east-1a):  10.0.10.0/24  [256 addresses]
├── Private Subnet B (us-east-1b):  10.0.20.0/24  [256 addresses]
├── Database Subnet A (us-east-1a): 10.0.100.0/24 [256 addresses]
└── Database Subnet B (us-east-1b): 10.0.200.0/24 [256 addresses]

Understanding Subnets

Subnets are subdivisions of your VPC's IP address range. Each subnet must reside entirely within one Availability Zone and cannot span zones. This is a critical architectural constraint — it means you need multiple subnets across AZs for high availability.

The key distinction in AWS networking is between public and private subnets. A public subnet has a route to an Internet Gateway, allowing resources with public IPs to communicate directly with the internet. A private subnet routes internet-bound traffic through a NAT Gateway, allowing outbound connections while preventing inbound access.

Public subnets: Route 0.0.0.0/0 to Internet Gateway — for load balancers, bastion hosts, NAT Gateways
Private subnets: Route 0.0.0.0/0 to NAT Gateway — for application servers, workers, internal services
Isolated subnets: No route to internet — for databases, secrets, highly sensitive workloads

“The subnet architecture you choose determines your security posture. Every resource in a public subnet is potentially exposed to the internet. Design with the principle of least privilege — keep resources private unless they absolutely need to be public.”
A
AWS Well-Architected Framework

2Chapter

Securing Your Network

AWS provides multiple layers of network security that work together to protect your resources. Understanding how Security Groups and Network ACLs interact is essential for building secure architectures.

Security Groups: Instance-Level Firewalls

Security Groups act as virtual firewalls at the instance level. They control inbound and outbound traffic for EC2 instances, RDS databases, Lambda functions, and most other AWS resources. The key characteristic of Security Groups is that they are stateful — if you allow inbound traffic, the response is automatically allowed outbound.

web-server-sg.json

JSON

{
  "SecurityGroupName": "web-server-sg",
  "Description": "Security group for web servers",
  "InboundRules": [
    {
      "Protocol": "TCP",
      "Port": 443,
      "Source": "0.0.0.0/0",
      "Description": "HTTPS from anywhere"
    },
    {
      "Protocol": "TCP",
      "Port": 80,
      "Source": "0.0.0.0/0",
      "Description": "HTTP from anywhere (redirect to HTTPS)"
    },
    {
      "Protocol": "TCP",
      "Port": 22,
      "Source": "sg-bastion-xxxxx",
      "Description": "SSH from bastion only"
    }
  ],
  "OutboundRules": [
    {
      "Protocol": "-1",
      "Port": "All",
      "Destination": "0.0.0.0/0",
      "Description": "Allow all outbound"
    }
  ]
}

Network ACLs: Subnet-Level Defense

Network Access Control Lists (NACLs) operate at the subnet level and provide an additional layer of defense. Unlike Security Groups, NACLs are stateless — you must explicitly allow both inbound and outbound traffic. They process rules in numerical order, stopping at the first match.

Feature	Security Group	Network ACL
Level	Instance/Resource	Subnet
State	Stateful	Stateless
Rules	Allow only	Allow and Deny
Processing	All rules evaluated	Rules in order, first match wins
Default	Deny all inbound, allow all outbound	Allow all

Security Groups vs Network ACLs

Defense in Depth

Use both Security Groups AND NACLs. Security Groups are your primary defense — fine-grained, easy to manage. NACLs provide a secondary layer, useful for blocking known malicious IPs or creating explicit deny rules that Security Groups can't provide.

VPC Flow Logs

VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. They're essential for security monitoring, troubleshooting connectivity issues, and compliance auditing. Flow logs can be published to CloudWatch Logs, S3, or Kinesis Data Firehose.

terminal

Bash

# Create a VPC Flow Log that captures all traffic
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-1234567890abcdef0 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/flowlogsRole

3Chapter

Connecting to the Internet

Internet connectivity in AWS VPCs is not automatic — you must explicitly configure the components that enable communication between your VPC and the public internet. Understanding these components is crucial for designing secure, functional architectures.

Internet Gateway

An Internet Gateway (IGW) is a horizontally scaled, redundant, highly available VPC component that enables communication between your VPC and the internet. It serves two purposes: providing a target in your route tables for internet-routable traffic, and performing network address translation (NAT) for instances with public IP addresses.

1Create and attach an Internet Gateway to your VPC
2Create a route table with a route to 0.0.0.0/0 pointing to the IGW
3Associate public subnets with this route table
4Ensure instances have public IP addresses (auto-assign or Elastic IP)
5Configure Security Groups to allow the required traffic

NAT Gateway

A NAT Gateway enables instances in private subnets to connect to the internet or other AWS services, while preventing the internet from initiating connections to those instances. This is essential for private instances that need to download updates, access external APIs, or connect to AWS services that aren't available via VPC endpoints.

route-tables.yaml

YAML

# Route Table Configuration

PublicRouteTable:
  Routes:
    - Destination: 10.0.0.0/16
      Target: local
    - Destination: 0.0.0.0/0
      Target: igw-abc123  # Internet Gateway

PrivateRouteTable:
  Routes:
    - Destination: 10.0.0.0/16
      Target: local
    - Destination: 0.0.0.0/0
      Target: nat-xyz789  # NAT Gateway

Complete Architecture

A production-ready VPC architecture combines all these concepts. The following diagram shows a typical three-tier application setup with proper network segmentation, security, and high availability.

architecture-diagram.txt

Plain Text

┌────────────────────────────────────────────────────────────────────┐
│                         VPC: 10.0.0.0/16                           │
│  ┌─────────────────────────────┐ ┌─────────────────────────────┐   │
│  │      Availability Zone A    │ │      Availability Zone B    │   │
│  │  ┌───────────────────────┐  │ │  ┌───────────────────────┐  │   │
│  │  │   Public: 10.0.1.0/24 │  │ │  │   Public: 10.0.2.0/24 │  │   │
│  │  │  [ALB] [NAT Gateway]  │  │ │  │  [ALB] [NAT Gateway]  │  │   │
│  │  └───────────────────────┘  │ │  └───────────────────────┘  │   │
│  │  ┌───────────────────────┐  │ │  ┌───────────────────────┐  │   │
│  │  │  Private: 10.0.10.0/24│  │ │  │  Private: 10.0.20.0/24│  │   │
│  │  │   [App Servers]       │  │ │  │   [App Servers]       │  │   │
│  │  └───────────────────────┘  │ │  └───────────────────────┘  │   │
│  │  ┌───────────────────────┐  │ │  ┌───────────────────────┐  │   │
│  │  │Database: 10.0.100.0/24│  │ │  │Database: 10.0.200.0/24│  │   │
│  │  │   [RDS Primary]       │  │ │  │   [RDS Standby]       │  │   │
│  │  └───────────────────────┘  │ │  └───────────────────────┘  │   │
│  └─────────────────────────────┘ └─────────────────────────────┘   │
│                                                                     │
│  ◄──────────────────── Internet Gateway ────────────────────────►  │
└────────────────────────────────────────────────────────────────────┘

“The best network architectures are boring. They follow patterns, they're predictable, and they're well-documented. Save your creativity for your application — your network should just work.”
S
Sarah Chen