A Comprehensive Guide to AWS VPCs

If you’re new to cloud computing and want to understand how Amazon Web Services Virtual Private Cloud (AWS VPC) works, this post is for you. I’ll walk through the key components of a VPC and share some practical tips along the way.

What is an AWS VPC?

An AWS VPC is a virtual network that lives inside AWS’s infrastructure. It lets you control how your applications talk to each other, how traffic flows, and who can access what. The main point is isolation: your VPC is separate from other networks in the cloud, so you don’t have to worry about someone else poking around your resources.

Five characteristics worth knowing

AWS VPCs have a few properties that make them useful:

1. Isolation - Each VPC is separate, so you can keep different parts of your environment sealed off from each other.
2. Scalability - You can expand or shrink your network as needed.
3. Customizability - You pick the IP ranges, subnets, and routing rules.
4. Cost - The VPC itself is free. You pay for what you put inside it.
5. Reliability - AWS builds redundancy into the underlying infrastructure.

What is a default VPC?

When you create an AWS account, you get a default VPC pre-configured with subnets, route tables, and security groups across the availability zones in your region. It’s there so you can start launching instances immediately without setting anything up yourself.

The benefit is obvious: less work getting started. The tradeoff is that the defaults aren’t necessarily optimized for your specific needs, so most people eventually create their own custom VPCs once they understand what they’re doing.

How it works

You manage your VPC through the AWS console, CLI, or API. Here’s the basic flow: create the VPC, add subnets, set up route tables, configure security groups, then launch resources like EC2 or RDS instances into those subnets.

One thing that trips people up: subnets are tied to a single availability zone. But the VPC itself spans all AZs in that region. So if you want high availability, you’d create subnets in multiple AZs and distribute your instances across them.

Key features

Ingress Routing

Ingress routing handles traffic coming into your VPC from outside. You can route this traffic through several options:

• AWS Direct Connect - a dedicated connection from your data center to AWS
• VPN - encrypted tunnel over the public internet
• IPsec tunnels - another encrypted tunnel option

All of these give you a private path into your VPC rather than exposing services directly to the internet.

Egress Routing

Egress routing is about traffic leaving your VPC. If you need your VPC to reach the internet or your corporate data center, you configure egress through a Virtual Private Gateway or NAT gateway.

Traffic Mirroring

Traffic mirroring copies network packets from your VPC so you can send them to security or monitoring tools. Common destinations include Kinesis Data Firehose for analytics, Lambda for real-time processing, or your own packet collection system. This is useful when you want to inspect traffic without slowing down production.

Is VPC public or private?

Both, depending on how you configure it. A subnet becomes “public” when it has a route to an internet gateway. A subnet without that route is effectively private, though “private” is a bit of a misnomer since it’s still reachable from within your VPC.

The public/private label applies to subnets, not the VPC as a whole.

Connecting a VPC to the internet

You need two things: an internet gateway (IGW) attached to your VPC, and a route table that sends internet-bound traffic to it. Without the IGW, nothing in your VPC can reach the outside world. Without the route, the IGW doesn’t know where to send traffic.

A Virtual Private Gateway (VPG) does something different: it connects your VPC to an external network, like an on-premises data center, through VPN or Direct Connect.

VPN vs. VPC

This trips up a lot of people. A VPN connects two networks over the internet. A VPC is an isolated network environment within AWS. You can use a VPN to connect your office to a VPC, but the VPC itself is the thing that gives you a private slice of AWS infrastructure.

Is VPC IaaS or PaaS?

VPC is infrastructure-as-a-service. You get virtualized computing resources, networking, and storage, and you manage the configuration. AWS handles the physical hardware; you handle everything else.

Components of a VPC

Four pieces hold everything together:

1. Subnets - Collections of IP addresses within the VPC. You split your IP range into smaller chunks here.
2. Route tables - Rules that determine where network traffic goes. Each subnet needs to be associated with a route table.
3. Network gateways - The bridge between your VPC and other networks. Internet Gateway for internet, Virtual Private Gateway for VPN/Direct Connect.
4. Security groups - Instance-level firewalls. They control what traffic can reach your individual EC2 instances.

Limitations to know

VPCs have some hard limits:

• VPCs are scoped to a single region
• Subnets live in a single availability zone
• 500 security groups per VPC
• 60 inbound rules + 60 outbound rules per security group (120 total)
• 200 subnets per VPC
• 5 VPCs per region by default (you can request more)

For IPv4 subnets, a /24 gives you 256 addresses, but AWS reserves 5 of them, leaving you with 251 usable. IPv6 subnets are fixed at 65,536 addresses.

Security

Security groups are your first line of defense. Some基本原则:

• Block everything by default, then open only what you need
• Don’t leave ports like SSH or RDP open to the world
• Use security groups to restrict traffic between services, not just external access
• Monitor with VPC Flow Logs

Network ACLs add another layer at the subnet level. Think of them as a second checkpoint.

Linking your VPC to an on-premises data center

AWS Direct Connect gives you a dedicated private connection between your data center and AWS. No traffic goes over the public internet. This matters if you have applications that need consistently low latency or high bandwidth, like large data transfers or legacy systems that don’t handle variable latency well.

Connecting two VPCs

VPC Peering lets you connect two VPCs so they can communicate directly. It works across accounts and regions. You just create a peering connection, accept it, and update route tables.

For connecting more than two VPCs, Transit Gateway is the better choice. It acts as a hub and handles routing between all connected VPCs and on-premises networks without you having to manage individual peering connections.

Costs

The VPC itself is free. What you pay for:

• NAT Gateways: about $0.045 per hour
• VPN Connections: about $0.05 per hour per connection
• VPC Peering: free for cross-AZ traffic, small charge for inter-region
• Data transfer: standard EC2 data transfer rates apply

Saving money on data transfer

Avoid going over the public internet for AWS-to-AWS traffic when possible. VPC endpoints let your instances talk to S3 and DynamoDB privately, without leaving AWS’s network. This avoids internet data transfer charges.

VPC Flow Logs

Flow Logs capture information about the IP traffic going to and from network interfaces in your VPC. You can send them to CloudWatch Logs or S3.

What can you do with them? Debug why a service isn’t reachable, spot unusual traffic patterns, or feed them into a SIEM for security analysis. Combined with CloudWatch Logs Insights, you can query your network traffic in real time.

Creating an AWS VPC

Here’s the short version of setting one up through the console:

1. Go to the VPC dashboard in the AWS console
2. Click “Create VPC”
3. Choose “VPC and more” if you want the wizard to create subnets, route tables, and such automatically
4. Pick a name, CIDR block, and tenancy preference
5. Click Create

That’s the two-minute version. The details (availability zones, subnet CIDRs, NAT vs. bastion) depend on your architecture.

Infrastructure as code

Creating VPCs by hand through the console doesn’t scale. If you need the same setup across multiple environments or regions, use Terraform or CloudFormation.

Terraform

resource "aws_vpc" "example" {
  cidr_block = var.vpc_cidr

  tags = {
    Name = var.vpc_name
  }
}

resource "aws_subnet" "example" {
  cidr_block = var.subnet_cidrs
  vpc_id     = aws_vpc.example.id

  tags = {
    Name = var.subnet_name
  }
}

After writing your .tf file, run terraform init, then terraform plan to review, then terraform apply to create the resources.

CloudFormation

With CloudFormation, you define everything in a JSON or YAML template. The stack is the unit of deployment.

 aws cloudformation create-stack --stack-name my-test-stack \
--template-body file://my_templates/vpc.yaml \
--parameters ParameterKey=VPCName,ParameterValue=MyVPC \
ParameterKey=VPCCidrBlock,ParameterValue=10.0.1.0/20

Once the stack exists, you can update it or delete it as a unit. That’s useful for spinning up identical environments for dev, staging, and production.

AWS VPC Limits

AWS sets default limits on several resources. These can be increased by requesting a quota adjustment:

You can view and request increases through the AWS console or by filing a support ticket.

Deleting a VPC

Before deleting a VPC, clean up everything attached to it:

• Terminate EC2 instances
• Delete load balancers
• Remove security group rules and security groups
• Delete VPC endpoints
• Remove VPC peering connections
• Detach and delete the internet gateway

Then select the VPC in the dashboard and delete it. If anything is still attached, AWS will tell you what needs to go first.

Best practices

A few things I keep coming back to:

• Use multiple AZs - Spread your resources across at least two availability zones so a single AZ failure doesn’t take everything down.
• Separate environments - Keep production and development in different VPCs.
• Pick your CIDR carefully - Make sure it doesn’t overlap with your on-premises network if you plan to connect them.
• Restrict security groups - Default-deny, then add only what you need. Review them periodically.
• Prefer NAT Gateways over NAT Instances - AWS manages NAT Gateways for you, and they scale automatically.
• Use VPC endpoints for S3 and DynamoDB - Keeps traffic off the public internet.
• Monitor everything - Flow Logs, CloudWatch, and GuardDuty give you visibility into what’s happening in your network.

CLI basics

You can create a VPC and its components entirely from the command line:

aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id vpc-xxxxxxxx --cidr-block 10.0.1.0/24
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxxxxxxx --internet-gateway-id igw-xxxxxxxx
aws ec2 create-route-table --vpc-id vpc-xxxxxxxx
aws ec2 create-route --route-table-id rtb-xxxxxxxx --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxxxxxxx
aws ec2 associate-route-table --subnet-id subnet-xxxxxxxx --route-table-id rtb-xxxxxxxx

The exact IDs will differ, but this shows the sequence: create the VPC, subnet, gateway, route table, routes, then associate the subnet with the route table.

Troubleshooting with Reachability Analyzer

AWS Reachability Analyzer tests whether a packet can travel from source to destination in your VPC. It simulates traffic and reports where the path breaks.

What it checks:

• Security group rules
• Network ACL rules
• Route table entries
• Gateway configurations

It won’t tell you why an application is slow, but it will tell you why traffic can’t reach something at all.

Studying for the Solutions Architect exam

If you’re preparing for the AWS Solutions Architect Associate certification, VPC comes up constantly. Focus on:

• How subnets, route tables, and security groups work together
• The difference between security groups and network ACLs
• When to use NAT Gateway vs. NAT Instance
• VPC Peering limitations and Transit Gateway as an alternative
• How to design for high availability across AZs

The exam tests whether you can make good architectural decisions, not just memorize features.

Learning with mind maps

Mind maps help me see how VPC components relate to each other. I find it easier to remember “internet gateway connects to route table, route table sends traffic to subnet, subnet launches instance” when you can see it laid out visually.

That’s a quick tour of AWS VPCs. The service isn’t complicated once you understand what each piece does, but there’s definitely a learning curve. Start with the basics (VPC, subnet, route table, security group), get comfortable with those, then add the more advanced pieces like Direct Connect or Transit Gateway as you need them.

Once you have the fundamentals down, the next step is designing VPCs for real production environments. I put together a guide on AWS VPC design patterns in 2026 covering multi-account landing zones, Transit Gateway hub-and-spoke, IPv6 dual-stack, and the NAT Gateway cost traps most teams don’t see coming.