What is AWS VPC?

What is AWS VPC?

When you launch resources in AWS — an EC2 instance, an RDS database, a Lambda function with VPC access — those resources need to live somewhere on a network. That network is your VPC.

VPC stands for Virtual Private Cloud. It's your own logically isolated section of the AWS cloud where you define the network topology. You control the IP address ranges, create subnets, configure route tables, and set up gateways. Think of it as building your own data center network, except there's no physical hardware to manage.

Every AWS account comes with a default VPC in each region. It's preconfigured so you can launch resources immediately without worrying about networking. But once you move beyond experimentation, understanding VPC is essential. It's the foundation that determines how your resources communicate with each other and the outside world.

The Building Blocks

Subnets

A subnet is a range of IP addresses within your VPC. You create subnets in specific Availability Zones, which gives you the ability to distribute resources across physically separate data centers for resilience.

Subnets come in two flavors:

• Public subnets — these have a route to the internet via an Internet Gateway. Resources here can be accessed from the outside world (if their security rules allow it). Web servers and load balancers typically live here.
• Private subnets — these have no direct route to the internet. Databases, application servers, and anything that shouldn't be publicly accessible go here. If resources in a private subnet need outbound internet access (for updates, API calls, etc.), you route them through a NAT Gateway.

Internet Gateway

An Internet Gateway (IGW) is what connects your VPC to the public internet. You attach one to your VPC and then add a route in your public subnet's route table pointing internet-bound traffic to the IGW. Without it, nothing in your VPC can reach the internet and nothing on the internet can reach your VPC.

Route Tables

Route tables contain rules (routes) that determine where network traffic is directed. Every subnet is associated with a route table. The default route table handles traffic within the VPC. You add routes to direct traffic to the Internet Gateway, NAT Gateway, VPN connections, or VPC peering connections.

A simple public subnet route table looks like this:

The first rule keeps traffic within the VPC local. The second rule sends everything else to the Internet Gateway.

Security Groups

Security groups are virtual firewalls that control inbound and outbound traffic at the instance level. Every EC2 instance, RDS instance, and other VPC resource is associated with one or more security groups.

Key characteristics:

• Stateful — if you allow inbound traffic on port 443, the response traffic is automatically allowed out. You don't need a separate outbound rule for responses.
• Default deny — inbound traffic is denied by default. You explicitly allow what you need.
• Instance-level — they attach to individual resources, not subnets.

Network ACLs

Network Access Control Lists (NACLs) operate at the subnet level. Unlike security groups, they are stateless — you need to define both inbound and outbound rules. NACLs provide an additional layer of defense and are useful for broad deny rules that apply to an entire subnet.

For most workloads, security groups are your primary tool. NACLs are the safety net.

Why VPC Matters

If you're running anything beyond a single test instance, VPC design directly impacts your security and architecture. A well-designed VPC:

• Isolates your databases and application logic from the public internet
• Controls traffic flow between services with precision
• Enables multi-AZ architectures for high availability
• Supports hybrid connectivity to on-premises networks via VPN or Direct Connect

A poorly designed VPC — or worse, relying on the default VPC for production — can lead to security gaps and operational headaches down the road.

A Practical Starting Point

For most applications, here's a solid starting architecture:

1. Create a VPC with a /16 CIDR block (e.g., 10.0.0.0/16)
2. Create two public subnets across two Availability Zones
3. Create two private subnets across the same two AZs
4. Attach an Internet Gateway for public subnet internet access
5. Set up a NAT Gateway for private subnet outbound access
6. Configure security groups to allow only the traffic your application requires

This gives you a fault-tolerant, secure network foundation that covers the majority of web application use cases.

Where VPC Fits in the Bigger Picture

VPC is one of the core services you should understand alongside IAM and the AWS fundamentals. Every other networking decision in AWS — load balancers, peering, Transit Gateway, PrivateLink — builds on top of your VPC configuration.

In a future post, I'll walk through setting up a production-ready VPC with Terraform, including the NAT Gateway configuration and multi-AZ layout. If you're looking to move beyond the default VPC, that will be a practical next step.

Got questions about VPC design? Drop a comment or reach out directly.

-- Nat