Amazon VPC (Virtual Private Cloud) is a logically isolated section of the AWS cloud where you launch AWS resources in a virtual network that you define. You have full control over the IP address range, subnet layout, route tables, network gateways, and security settings — just like operating a traditional on-premises network, but entirely in software.

Before VPC existed, all AWS resources ran in a flat, shared network called EC2-Classic. Today every AWS account automatically gets a Default VPC in each region so you can launch resources immediately. For production workloads, architects create Custom VPCs with a deliberate design that enforces security and network separation.

VPC isolation works at the network layer. Even if two EC2 instances exist in the same AWS region, they cannot communicate unless they share the same VPC (or explicit peering is configured). This is enforced by the underlying AWS hypervisor network — it is not just a firewall rule.

Every AWS account has a Default VPC automatically created in each region. It is designed for quick experimentation — you can launch an EC2 instance immediately without any network setup. Custom VPCs are created by architects for production workloads where you control every network decision.

A VPC is like a private office building that only your company occupies, inside a large public commercial district (AWS region):

When you create a VPC there are several building blocks that work together. Each chapter deep-dives into one, but here is the map:

Nearly every AWS compute, database, and integration service runs inside or connects to a VPC. Understanding VPC is foundational for everything else in AWS networking:

CIDR (Classless Inter-Domain Routing) is the notation used to define a range of IP addresses. A CIDR block looks like 10.0.0.0/16 — the number after the slash tells you how many bits are fixed (the network part), and the rest are free for hosts.

When you create a VPC, you assign a primary CIDR block. This is the total IP address space for your VPC — you carve it up into subnets. Getting this right matters because you cannot shrink a CIDR after creation and changing it requires rebuilding the VPC.

A subnet (sub-network) is a range of IP addresses carved out of your VPC's CIDR block. Every EC2 instance, RDS database, and Lambda function in VPC mode must be placed in a subnet. Subnets are the fundamental unit of network placement in AWS.

A common misconception: there is no "public" flag on a subnet. What makes a subnet public or private is purely its route table. A subnet whose route table has a route to an Internet Gateway (IGW) is public. A subnet with no IGW route is private.

In every subnet, AWS reserves the first 4 and last 1 IP address. For 10.0.1.0/24:

A well-planned VPC for a 3-AZ production deployment using 10.0.0.0/16:

A route table is a set of rules (called routes) that tells VPC network traffic where to go. Every subnet in a VPC is associated with exactly one route table. When traffic leaves a resource in a subnet, the VPC router consults the route table to decide the next hop.

The local route is automatically created when you create a VPC and cannot be removed. It ensures all resources within the VPC can communicate with each other using private IP addresses — regardless of which subnet they are in.

An Internet Gateway is a horizontally scaled, redundant, highly available VPC component that allows resources in your VPC to communicate with the internet. It serves two purposes: providing a target in route tables for internet-routable traffic, and performing NAT for instances with public IPs.

For IPv6-enabled VPCs, AWS provides an Egress-Only Internet Gateway. Since all IPv6 addresses are public (no NAT in IPv6), the egress-only IGW allows outbound-only IPv6 traffic — the same role that NAT Gateway plays for IPv4 private subnets.

AWS VPC provides two independent firewall layers that work at different levels of your network. Used together they give defence-in-depth — if one is misconfigured, the other still protects you.

A Security Group acts as a virtual firewall for your AWS resources. You attach one or more Security Groups to an EC2 instance (or any resource with a network interface), and all traffic to/from that resource is evaluated against the group's rules.

A Network ACL (NACL) is an optional, stateless security layer for your subnets. Every subnet must have a NACL — if you don't create a custom one, AWS attaches the default NACL which allows all traffic.

A VPC is isolated by default — nothing outside it can reach your resources unless you explicitly configure a connectivity path. AWS provides several mechanisms to connect your VPC to the internet, to other VPCs, or to on-premises environments.

A VPC Peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 or IPv6 addresses. The VPCs can be in the same account, different accounts, or different regions (inter-region peering).

AWS Site-to-Site VPN creates an encrypted IPSec tunnel between your on-premises network and your AWS VPC over the public internet. It is the fastest and cheapest way to establish hybrid connectivity — setup takes minutes.

AWS Direct Connect provides a dedicated private physical network connection from your data centre to AWS. Traffic does not go over the internet — it flows through a private fiber link to an AWS Direct Connect location, then into your VPC.

AWS Transit Gateway acts as a central hub to interconnect multiple VPCs and on-premises networks. Instead of setting up n*(n-1)/2 peering connections for n VPCs, you attach each VPC to one Transit Gateway — and all attached VPCs can route to each other through the hub.

A NAT Gateway (Network Address Translation) allows EC2 instances in private subnets to initiate outbound connections to the internet or other AWS services, while preventing the internet from initiating connections to those instances. It lives in a public subnet and uses an Elastic IP.

A VPC Endpoint allows you to connect your VPC directly to AWS services (S3, DynamoDB, SQS, SNS, etc.) without going through the internet, NAT Gateway, or IGW. Traffic stays on the AWS private backbone — more secure and often cheaper.

VPC Endpoints can have endpoint policies — JSON IAM-style policy documents that control which actions and resources can be accessed through the endpoint. This lets you restrict a private subnet to only access specific S3 buckets, preventing data exfiltration.

{
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::my-company-bucket",
      "arn:aws:s3:::my-company-bucket/*"
    ]
  }]
}

Every VPC has a built-in DNS resolver available at the VPC base address + 2 (e.g., 10.0.0.2 for a 10.0.0.0/16 VPC). This resolver, called AmazonProvidedDNS, handles all DNS queries from your VPC resources.

AWS PrivateLink lets you expose a service running in your VPC to consumers in other VPCs — or other AWS accounts — without peering, without internet, and without CIDR conflicts. The consumer sees an ENI in their own VPC; they don't need to know anything about your network topology.

VPC Flow Logs capture metadata about the IP traffic going to and from network interfaces in your VPC. They do NOT capture packet contents — only metadata like source/destination IP, ports, protocol, bytes, and whether the traffic was accepted or rejected.

This chapter brings everything together. These are the real-world VPC architecture blueprints used in production — from a simple 2-tier web app to a full HA multi-AZ enterprise design. Each pattern builds on the VPC primitives covered in earlier chapters.

The simplest production-ready pattern: a web/app server in a public subnet talks directly to a database in a private subnet. Good for MVPs, internal tools, and single-AZ applications.

The standard production pattern. An Application Load Balancer in the public subnet receives traffic and distributes it to app servers in a private subnet. App servers talk to a database in an isolated private subnet. Clear separation of concerns at every layer.

The full production HA pattern. Every tier is spread across at least 2 AZs. Auto Scaling Groups manage EC2 capacity automatically. RDS Multi-AZ handles synchronous replication and automatic failover. NAT Gateways are per-AZ so losing one AZ doesn't affect others.