Demystifying AWS VPC: From Layman to Cloud Architect

AWS Networking Series | Part 1 — Building secure, cost-optimised, cloud-native infrastructure on AWS

Why Do We Need a VPC?

Think of a VPC as your own private data center in the cloud. Without it, your resources would be floating in a shared space. A VPC gives you isolation, security, and complete control over your virtual networking environment, including your own IP address range, subnets, and route tables.

IP Addressing & The "Rule of 5"

Every VPC has a primary IPv4 CIDR block. As seen in our architecture diagram above, we are using the 10.0.0.0/16 network address block, which supports 65,536 IP addresses.

Strategic CIDR Planning: Beyond the /16

While many engineers default to a 10.0.0.0/16, high-level architecture requires more nuance. If you are part of a large organization, you must avoid overlapping with corporate data centers (often using RFC 1918 ranges like 10.x.x.x).

• Secondary CIDRs: If you run out of space, you can associate additional CIDR blocks with your VPC.
• The /17 Split: A common enterprise pattern is splitting a /16 into two /17s—one for production and one for non-production—ensuring clear separation while staying within a manageable range.
• Non-Routable Ranges: Consider using the 100.64.0.0/10 range (CGNAT) for internal VPC resources that don't need to be routable from your corporate network.

The Silent Killer: VPC DNS Attributes

Two often-overlooked attributes are critical for connectivity: enableDnsSupport and enableDnsHostnames. If these are disabled, your resources won't resolve AWS service endpoints privately. This is a common "day 1" troubleshooting issue when PrivateLink or Interface Endpoints fail to work as expected.

The Foundational Components

• Subnets: Segments of your VPC's IP range. You use them to group resources (like Web, App, and DB tiers) based on security needs.
• Availability Zones (AZs): Data centers within a region. Always spread subnets across multiple AZs to achieve High Availability (HA).
• Route Tables: The "GPS" of your VPC. They contain a set of rules that determine where network traffic is directed.

Provisioning with Infrastructure as Code (Terraform)

In modern cloud engineering, we never create VPCs via the console. Here is the standard "Golden Template" for a multi-AZ VPC using Terraform:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway     = true
  single_nat_gateway     = false
  one_nat_gateway_per_az = true # Provisions one NAT Gateway per AZ, eliminating cross-AZ charges and single points of failure
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Environment = "production"
    Owner       = "Architecture-Team"
  }
} # End of Module Block

Under the Hood: While modules are great, an architect should understand the raw resources. Here is the manual breakdown of what that module is doing:

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eu-west-1a"
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
}

Public vs. Private Subnets: The "Internet Gateway" Rule

A subnet is Public if its route table has a path to an Internet Gateway (IGW). A Private Subnet has no direct path to the IGW and must use a NAT Gateway located in a public subnet to reach the outside world securely.

Two Layers of Firewalls

AWS provides a layered defense approach to network security:

• Security Groups (Stateful): These act at the Instance level. They are "smart"—if you allow traffic in, the response is automatically allowed out.
• Network ACLs (Stateless): These act at the Subnet level. They are "rigid"—you must explicitly allow both inbound and outbound traffic separately.

Visibility & Troubleshooting: VPC Flow Logs

For high-authority environments, VPC Flow Logs are non-negotiable. They capture information about the IP traffic going to and from network interfaces in your VPC.

• Athena for Querying: Send your logs to S3 and use Amazon Athena to run SQL queries. A classic "Top Talkers" query to find bandwidth hogs looks like this:

SELECT srcaddr, dstaddr, sum(bytes) as total_bytes
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
GROUP BY srcaddr, dstaddr
ORDER BY total_bytes DESC
LIMIT 10;

-- Top talkers by source IP (useful for detecting noisy or compromised instances)
SELECT srcaddr, COUNT(*) as request_count 
FROM flow_logs 
GROUP BY srcaddr 
ORDER BY request_count DESC 
LIMIT 10;

• The REJECT Action: This is your primary debugging tool. If an application is failing, check if NACLs are rejecting packets before blaming the code.

VPC Sharing (Resource Access Manager)

In large enterprises, we often use **VPC Sharing** via AWS RAM. Instead of every team creating their own VPC (leading to a networking mess), a central Cloud Platform team manages a single VPC and "shares" specific subnets with different accounts. This centralizes control over IP space and connectivity while letting teams remain autonomous.

VPC Architecture Decision Matrix

Need	Solution	Best Practice
Isolation	Subnets	Web / App / DB tiering
Internet Access	NAT Gateway	Deploy one per AZ
Private AWS Access	VPC Endpoints	Gateway for S3/Dynamo (Free)
Compliance	Flow Logs	Log to S3 + Athena

Common Pitfalls & Production Lessons Learned

These are the mistakes that appear repeatedly in real AWS environments — including during migrations, audits, and post-incident reviews.