VPC Basics

You want the control of your own data center without owning a data center. You want private networks, custom IP addressing, firewalls you control—but you don't want to buy hardware, lease space, or hire people to swap failed drives at 3 AM.

A Virtual Private Cloud gives you exactly that. It's your own isolated network carved out of a cloud provider's infrastructure. Your private data center inside someone else's building—without the building.

What Is a VPC?

A VPC is a logically isolated section of a cloud provider's network dedicated to your account. Within this space, you launch virtual machines, databases, load balancers—whatever you need. Your resources. Your network. Your rules.

The isolation is real. Resources in your VPC can't communicate with resources in other customers' VPCs unless you explicitly allow it. You're neighbors sharing physical infrastructure, but you can't see through the walls.

This isolation lets you use private IP addresses, configure routing tables, create gateways, and apply security controls—all without affecting or being affected by anyone else on the platform.

IP Address Ranges and Subnets

When creating a VPC, you claim an IP address range using CIDR notation. Typically you choose from the private ranges defined in RFC 1918:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

For example, you might create a VPC with 10.0.0.0/16—that's 65,536 IP addresses that belong to you within this VPC.

Within the VPC, you carve out subnets—smaller IP ranges that organize your resources. A typical setup:

• 10.0.1.0/24 for web servers (256 addresses)
• 10.0.2.0/24 for application servers (256 addresses)
• 10.0.3.0/24 for databases (256 addresses)

Subnets let you apply different security policies to different parts of your infrastructure. Your web servers need different rules than your databases.

Public and Private Subnets

Subnets are classified as public or private based on one thing: where the door is.

Public subnets have a route to an Internet Gateway. Resources there with public IP addresses can talk directly to the Internet. Web servers and load balancers live here.

Private subnets have no direct route to the Internet. Resources there can only reach the outside world through a NAT Gateway—or not at all. Application servers and databases live here, protected from direct Internet exposure.

Same VPC, same physical infrastructure. The only difference is routing.

Route Tables

Route tables determine where traffic goes. Each subnet associates with a route table containing rules like:

The first rule keeps VPC-internal traffic local—packets destined for other resources in your VPC stay inside. The second rule sends everything else to the Internet Gateway.

Private subnet route tables look different. They might point 0.0.0.0/0 to a NAT Gateway instead, or omit the default route entirely.

Internet Gateways

An Internet Gateway connects your VPC to the public Internet. It does two things:

1. Serves as the routing target for Internet-bound traffic
2. Performs NAT for instances with public IPs, translating between private and public addresses

You attach one to your VPC and it works. The cloud provider handles making it redundant and scalable—that's their problem, not yours.

NAT Gateways

Private resources sometimes need to reach out. A database server needs to download security patches. An application server needs to call an external API.

NAT Gateways solve this. They sit in public subnets with public IP addresses. Private subnet route tables point their default route to the NAT Gateway, which translates private source IPs to its own public IP before forwarding traffic to the Internet.

Return traffic flows back through the NAT Gateway, which translates back to the original private IP.

The result: outbound connections work, but nothing from the Internet can initiate a connection to your private resources. One-way glass.

Security Groups

Security Groups are virtual firewalls that wrap individual resources. Each virtual machine can have one or more Security Groups controlling what traffic gets in and out.

They're stateful—allow inbound traffic and the return traffic is automatically permitted.

A web server Security Group might look like:

Inbound:

• TCP 443 from 0.0.0.0/0 (HTTPS from anywhere)

Outbound:

• All traffic to 0.0.0.0/0

Security Groups follow the resource. Move a VM to a different subnet and its Security Groups come with it.

Network ACLs

Network Access Control Lists operate at the subnet level. Unlike Security Groups, they're stateless—you must explicitly allow both request and response traffic.

Rules are evaluated in order by rule number. First match wins.

NACLs add defense in depth. Security Groups protect individual resources; NACLs protect entire subnets. They're particularly useful for broadly blocking traffic at the network edge.

VPC Flow Logs

Flow Logs capture metadata about traffic flowing through your VPC—source, destination, ports, whether traffic was accepted or rejected.

They're essential for:

• Security analysis (who tried to connect?)
• Troubleshooting (why can't this reach that?)
• Compliance (prove what happened)

You can enable them at the VPC, subnet, or individual network interface level.

Multi-Tier Architecture

VPCs naturally support the classic three-tier pattern:

Public tier: Load balancers and bastion hosts—the only things the Internet can see.

Application tier: Application servers in private subnets, reachable only from the public tier.

Data tier: Databases in private subnets, reachable only from the application tier.

Each tier has its own subnets, Security Groups, and routing rules. Compromise the web tier and you still have walls to breach before reaching the data.

High Availability

Cloud regions contain multiple availability zones—physically separate data centers. Good VPC design spans them:

• Create subnets in multiple availability zones
• Run resources redundantly across zones
• Use load balancers to distribute traffic

One availability zone fails? Traffic shifts to the others. Your application stays up.

Default VPCs

Cloud providers create a default VPC in each region for new accounts. It comes pre-configured with public subnets, an Internet Gateway, and permissive defaults.

Default VPCs work for getting started. Production workloads deserve custom VPCs with deliberate design.

Key Takeaways

A VPC is your isolated network within a cloud provider's infrastructure—your own data center without the data center.

You define your IP space and carve it into subnets. Public subnets have Internet access; private subnets don't.

Route tables control where traffic flows. Internet Gateways provide the path out; NAT Gateways let private resources reach the Internet without being reachable from it.

Security Groups wrap individual resources. NACLs wrap subnets. Together they provide layered defense.

Span availability zones for high availability. Design deliberately for production.