What is a VPC?

A VPC, which stands for Virtual Private Cloud, is your own private, logically isolated section of the AWS cloud where you launch resources like servers and databases. Think of it as your personal data center, except it is software-defined: you control the IP address ranges, how traffic is routed, and which doors are open to the public internet. Everything you build in AWS that needs a network, from a single web server to a large multi-tier application, lives inside a VPC. Getting the network right early matters, because some choices, like the size of your address space, are hard to change later.

Why a VPC exists

In the early days of computing, a network meant physical cables, switches, and routers in a room you owned. A VPC gives you the same control without any hardware. AWS runs the physical machines; you draw the network map on top of them. Your VPC is completely separate from every other customer’s VPC, even though you may share the same underlying servers. That isolation is the “Private” in Virtual Private Cloud.

The big benefit is control combined with safety. You decide what is reachable from the internet and what stays internal. A database can be made invisible to the outside world while still being reachable by your application servers. This lets you follow the security principle of “least exposure” by default.

The core building blocks

A VPC is made of several pieces that work together. Here is what each one does, in plain English.

Building block	What it is	What it does
CIDR block	The range of private IP addresses for the VPC (e.g. 10.0.0.0/16)	Defines how many addresses are available inside the network
Subnet	A slice of the VPC’s IP range tied to one Availability Zone	Groups resources; you mark each as public or private
Route table	A list of rules (“send traffic for X to Y”)	Decides where network traffic goes
Internet Gateway (IGW)	A door between your VPC and the public internet	Allows resources in public subnets to send and receive internet traffic
NAT Gateway	A one-way door for outbound internet access	Lets private resources reach the internet without being reachable from it
Security group	A firewall attached to a resource (like a server)	Controls allowed inbound and outbound traffic per instance
Network ACL (NACL)	A firewall attached to a subnet	Controls allowed traffic at the subnet boundary

A few of these need a fuller definition. An Availability Zone (AZ) is one or more physically separate data centers within an AWS Region. A subnet is a portion of your VPC’s address range; you place it in a single AZ so you can spread resources across zones for resilience. A security group is a stateful firewall, meaning if you allow a request in, the reply is automatically allowed out. A NACL is stateless, meaning you must explicitly allow both directions.

Tip: A common beginner mistake is confusing security groups and NACLs. Use security groups as your main firewall (they are simpler and stateful). Treat NACLs as a coarse, optional second layer at the subnet level. See Security groups vs NACLs for the full comparison.

Region-scoped, and the CIDR you cannot shrink

This is the single most important gotcha to understand before you create anything.

A VPC lives in exactly one AWS Region (for example, us-east-1 or eu-west-1). It can span all the Availability Zones within that Region, but it cannot stretch across Regions. If you need a presence in another Region, you create a separate VPC there and connect them.

When you create a VPC you give it a primary CIDR block, such as 10.0.0.0/16 (which provides about 65,000 addresses). Here is the catch: you can later add more CIDR blocks to expand the address space, but you can never shrink or remove the primary CIDR. If you start too small, you may run out of room for subnets and be forced into messy workarounds.

Warning: Pick a generous, private CIDR up front that does not overlap with your office network, your on-premises data center, or any other VPC you might peer with later. Overlapping ranges make VPC peering and VPN connections impossible without re-architecting. A /16 from the private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) is a safe, roomy default.

For a deeper look at choosing ranges, see CIDR and IP addressing.

When to use a custom VPC (and when not to)

Every AWS account comes with a default VPC in each Region, pre-wired with public subnets and an internet gateway so you can launch a server in minutes. That is great for quick experiments and learning.

For anything real, create your own VPC. A custom VPC lets you separate public-facing resources from private ones, control exactly which ranges you use, and meet security or compliance requirements. The only time you should lean on the default VPC is throwaway testing. Production workloads belong in a purpose-built VPC. See The default VPC for the differences.

Creating a VPC

You can create a VPC in the AWS Management Console or with the AWS CLI (version 2). The example below creates a VPC with a 10.0.0.0/16 range.

Console steps

1. Open the VPC console at console.aws.amazon.com/vpc.
2. In the left menu, choose Your VPCs, then Create VPC.
3. Select VPC only (or VPC and more to auto-create subnets, route tables, and gateways).
4. Enter a Name tag, for example my-app-vpc.
5. Under IPv4 CIDR, enter 10.0.0.0/16.
6. Leave tenancy as Default and choose Create VPC.

AWS CLI

aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=my-app-vpc}]'

Output:

{
    "Vpc": {
        "CidrBlock": "10.0.0.0/16",
        "DhcpOptionsId": "dopt-0a1b2c3d",
        "State": "pending",
        "VpcId": "vpc-0a1b2c3d",
        "OwnerId": "123456789012",
        "InstanceTenancy": "default",
        "IsDefault": false
    }
}

Infrastructure as Code

For repeatable, version-controlled networks, define the VPC in code. Here it is in Terraform:

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "my-app-vpc"
  }
}

A quick note on cost

The VPC itself is free: creating a VPC, subnets, route tables, internet gateways, and security groups costs nothing. You pay for the resources you run inside it (like EC2 instances) and for a few specific networking add-ons. The biggest one to watch is the NAT Gateway, which costs roughly $0.045 per hour (about $32 per month) plus a per-gigabyte data processing charge. Plan for that if your private subnets need outbound internet access. See NAT Gateway for details.

Best practices

• Choose a large, non-overlapping private CIDR (such as a /16) so you never run out of room and can peer or connect on-prem later.
• Spread subnets across at least two Availability Zones for high availability. See Multi-AZ networking.
• Keep databases and internal services in private subnets; only put load balancers and bastion hosts in public subnets.
• Use security groups as your primary firewall and reserve NACLs for coarse, account-wide guardrails.
• Enable DNS support and DNS hostnames so resources can resolve each other by name.
• Turn on VPC Flow Logs early so you can audit and troubleshoot traffic later. See VPC Flow Logs.
• Use Infrastructure as Code (Terraform or CloudFormation) so your network is reviewable, repeatable, and easy to recreate.

Related Topics

• The default VPC
• Create a VPC
• CIDR and IP addressing
• Subnets
• Security groups vs NACLs