Amazon VPC – The Complete Guide to AWS Networking (2026)

Amazon Virtual Private Cloud (VPC) is your own private, software-defined network inside AWS. Every EC2 instance, container, load balancer, and managed database runs inside a VPC, and you control its IP address ranges, how it's subdivided, how traffic is routed, and which firewalls protect it. Understanding VPC is essential to building secure, production-grade systems — it's the network layer everything else sits on.

For many beginners, VPC is the most intimidating AWS service because it brings together networking concepts — CIDR blocks, subnets, routing, gateways, firewalls — that you may not have configured by hand before. But each piece has a clear job, and once you see how they fit together into the classic public/private architecture, the whole picture clicks.

This guide explains every core VPC component, how they connect, the difference between security groups and network ACLs, advanced connectivity like endpoints and peering, and a reference architecture for a secure multi-tier application.

What Is a VPC?

A VPC is a logically isolated section of the AWS cloud, defined by an IP range in CIDR notation such as 10.0.0.0/16 (about 65,000 addresses). Within it you create subnets, attach gateways for connectivity, and define routing and firewall rules. It behaves like a traditional data-center network, but entirely software-defined and provisioned in seconds.

CIDR and IP Address Planning

The VPC's CIDR block determines how many private IP addresses are available and how you can carve it into subnets. A /16 gives you room for many subnets; each subnet gets a smaller slice like /24 (256 addresses). Plan ranges carefully and avoid overlaps — especially if you'll later peer VPCs or connect to an on-premise network, where overlapping ranges make routing impossible.

Subnets: Public and Private

A subnet is a range of IPs within the VPC, tied to one Availability Zone. The distinction that matters is:

• Public subnet — its route table sends internet-bound traffic to an Internet Gateway, so resources here (like load balancers) can be reached from and reach the internet.
• Private subnet — has no direct route to the internet; ideal for application servers and databases that should never be publicly reachable.

For high availability, create subnets in at least two Availability Zones.

Route Tables and Gateways

• Route tables — rules that decide where traffic goes based on its destination. A subnet is "public" precisely because its route table points internet traffic at an Internet Gateway.
• Internet Gateway (IGW) — allows two-way communication between public subnets and the internet.
• NAT Gateway — lets resources in private subnets make outbound connections (for updates or API calls) while remaining unreachable from the internet.

Security Groups vs Network ACLs

VPC has two firewall layers that are often confused:

• Security groups — operate at the resource level (attached to instances/ENIs), are stateful (return traffic is automatically allowed), and support allow rules only. This is where most day-to-day access control happens.
• Network ACLs (NACLs) — operate at the subnet level, are stateless (you must allow both inbound and outbound), and support both allow and deny rules. Useful as a coarse, subnet-wide guardrail.

VPC Endpoints (Private Access to AWS Services)

By default, reaching S3 or DynamoDB from a private subnet would route through a NAT gateway and the public internet. VPC endpoints create a private connection to AWS services that never leaves the AWS network — improving security and reducing NAT costs. Gateway endpoints serve S3 and DynamoDB; interface endpoints (powered by PrivateLink) serve most other services.

Connecting VPCs and Networks

• VPC Peering — a direct, private connection between two VPCs.
• Transit Gateway — a hub that connects many VPCs and on-premise networks at scale.
• Site-to-Site VPN / Direct Connect — link your VPC to an on-premise data center over an encrypted tunnel or a dedicated line.

A Secure Multi-Tier Architecture

The classic, well-architected web app uses public and private subnets across two AZs:

• Public subnets — the load balancer and NAT gateways.
• Private app subnets — the application servers (no public IPs).
• Private data subnets — the RDS database, reachable only from the app tier.

Traffic flows: internet → load balancer (public) → app servers (private) → database (private). The database is never exposed to the internet, and each tier's security group allows only the previous tier to reach it.

Creating a VPC and Subnet (AWS CLI)

# Create the VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16

# Create a public subnet in one AZ
aws ec2 create-subnet \
  --vpc-id vpc-0123456789 \
  --cidr-block 10.0.1.0/24 \
  --availability-zone us-east-1a

# Create a private subnet in another AZ
aws ec2 create-subnet \
  --vpc-id vpc-0123456789 \
  --cidr-block 10.0.2.0/24 \
  --availability-zone us-east-1b

Monitoring with VPC Flow Logs

VPC Flow Logs capture metadata about the traffic going to and from network interfaces — source/destination IPs, ports, and whether traffic was accepted or rejected. They're invaluable for troubleshooting connectivity ("why can't my app reach the database?") and for security investigations. Send them to CloudWatch Logs or S3 for analysis.

Common Mistakes to Avoid

• Putting databases in public subnets — keep data tiers private.
• Overly permissive security groups (0.0.0.0/0) — restrict source IPs and ports.
• Overlapping CIDR ranges — plan IPs before peering or connecting on-prem.
• Forgetting a NAT gateway — private instances then can't get updates or call external APIs.
• Single-AZ design — spread subnets across AZs for resilience.

Frequently Asked Questions

Security group or NACL? Use security groups for nearly all control (stateful, per-resource); use NACLs only for coarse subnet-level rules.

Do I need a NAT gateway? Only if private resources need outbound internet access; VPC endpoints can avoid it for AWS-service traffic.

What makes a subnet public? A route in its route table pointing internet traffic to an Internet Gateway.

Is there a default VPC? Yes — every account gets one per Region to start quickly, but production systems usually use a custom VPC.

How many subnets and AZs should I use? For production, use at least two Availability Zones, each with a public and a private subnet, so the loss of a single AZ doesn't take down your application. You can add more subnets per AZ to separate tiers (web, app, data) for clearer security boundaries.

Can a VPC span multiple Regions? No — a VPC is scoped to a single Region (but spans the AZs within it). To connect VPCs in different Regions, use VPC peering or Transit Gateway across Regions.

Summary Table

Watching VPC Costs

The VPC itself, subnets, route tables, security groups, and internet gateways are free — but a few components do cost money and surprise beginners. NAT gateways charge both an hourly rate and a per-GB data-processing fee, so a chatty private subnet can run up a real bill; consolidating NAT gateways or replacing them with VPC endpoints for AWS-service traffic cuts cost. Interface VPC endpoints also carry an hourly and per-GB charge, while gateway endpoints (for S3 and DynamoDB) are free. Inter-AZ data transfer is billed too, so keeping chatty components in the same Availability Zone where appropriate can help. Reviewing these line items early prevents the classic "why is my mostly-idle network costing money?" moment.

Default VPC vs Custom VPC

Every AWS account comes with a default VPC in each Region, pre-configured with public subnets, an internet gateway, and permissive defaults so you can launch an instance immediately. That's convenient for learning, but production systems should use a custom VPC you design deliberately — with private subnets for sensitive tiers, tightly scoped security groups, and a planned IP layout. Treating the default VPC as throwaway and building a purpose-built network for real workloads is a hallmark of a well-architected account.

Bastion Hosts vs Session Manager

To administer instances in private subnets, the traditional approach is a bastion host (jump box) — a hardened instance in a public subnet that you SSH into first, then hop to private instances. The modern, more secure approach is AWS Systems Manager Session Manager, which gives you a shell to private instances with no bastion, no open SSH port, and no key management at all — access is controlled entirely through IAM and fully logged. For most teams, Session Manager has made the bastion host obsolete.

IPv6 and Dual-Stack VPCs

VPCs support IPv6 alongside IPv4 (dual-stack). Because IPv6 addresses are globally unique and effectively unlimited, they sidestep the address-exhaustion and overlap problems that plague large IPv4 networks. For internet-facing workloads expecting IPv6 clients, or very large networks, enabling dual-stack subnets is increasingly common — though IPv4 remains the default and is still required by some services.

Reference

This article follows the official AWS documentation. Read the full reference here: Amazon VPC documentation.

Conclusion

A VPC is the secure network foundation for everything you run on AWS. Plan your IP ranges, split resources into public and private subnets across multiple AZs, route traffic deliberately, keep databases private, and use security groups for tight stateful control. Add VPC endpoints to keep AWS traffic off the public internet, and Flow Logs to see what's happening. Get the network right and the rest of your architecture becomes far simpler and safer.