Amazon Virtual Private Cloud (VPC) is the foundation for building secure and controlled networks in AWS. Understanding VPC networking is important when deploying EC2 instances, web applications, APIs, databases, and other cloud services.
In this guide, we will cover some of the most important AWS VPC concepts: public and private subnets, Internet Gateway, NAT Gateway, route tables, security groups, Network ACLs, VPC peering, VPC endpoints, and launching EC2 instances inside a VPC.
1. Public and Private Subnets
A subnet is a logical section of an AWS VPC where resources such as EC2 instances can be placed.
Public Subnet
A public subnet is associated with a route table that contains a route to an Internet Gateway. Resources in the subnet can potentially communicate with the internet when they also have the required public addressing and security rules.
Private Subnet
A private subnet does not have a direct route to an Internet Gateway. Private subnets are commonly used for databases, internal applications, backend services, and other resources that should not be directly accessible from the internet.
A common architecture is to place web servers in public subnets and application or database servers in private subnets.
2. Internet Gateway
An Internet Gateway (IGW) allows resources in a VPC to communicate with the internet when the appropriate routing, addressing, and security configuration is in place.
For example, a public subnet can use a route such as:
0.0.0.0/0 → Internet Gateway
This route tells the subnet's route table where internet-bound IPv4 traffic should go.
3. NAT Gateway
A NAT Gateway allows resources in a private subnet to initiate outbound connections to the internet without allowing unsolicited inbound internet connections directly to those resources.
A typical architecture places the NAT Gateway in a public subnet and configures the private subnet's route table to send internet-bound traffic through the NAT Gateway.
Private Subnet
↓
NAT Gateway
↓
Internet Gateway
↓
Internet
NAT Gateway is commonly useful when private servers need to download updates, packages, or access external services.
One thing worth planning for early: a NAT Gateway is billed hourly plus a per-GB data processing charge, and that cost applies per Availability Zone if you deploy one for high availability. On projects where outbound traffic from private subnets is mostly small API calls or package installs, this cost is easy to overlook until the first monthly bill arrives.
4. Route Tables and Traffic Control
Route tables determine where network traffic from a subnet should be sent. Each route contains a destination and a target.
For example, a public subnet may have:
Destination Target 10.0.0.0/16 local 0.0.0.0/0 Internet Gateway
A private subnet may instead use a NAT Gateway for internet-bound traffic. Route tables are therefore an important part of controlling how resources communicate inside and outside the VPC.
5. Creating a Custom VPC
AWS provides a default VPC, but production environments often require a custom VPC designed according to the application's networking and security requirements.
A basic custom VPC design can include:
- VPC with a private CIDR range
- Public subnets
- Private subnets
- Internet Gateway
- NAT Gateway
- Public and private route tables
- Security Groups
- Network ACLs
Careful IP address planning is important because changing network architecture later can be more difficult than designing it correctly from the beginning. A layout that works well for most small to mid-sized applications looks like this:
VPC CIDR: 10.0.0.0/16 Public Subnet (AZ-a): 10.0.0.0/24 Public Subnet (AZ-b): 10.0.1.0/24 Private Subnet (AZ-a): 10.0.10.0/24 Private Subnet (AZ-b): 10.0.11.0/24
Leaving gaps between subnet ranges (for example, jumping from
10.0.1.0/24 to 10.0.10.0/24) gives you room to
add more subnets later — for a database tier or a Kubernetes cluster, say
— without re-architecting the whole VPC.
6. Launching EC2 Instances in a VPC
When launching an EC2 instance, you can select the VPC and subnet where the instance will be deployed.
The subnet selection affects the instance's network connectivity. For example, a web server might be deployed in a public subnet, while a database server can be placed in a private subnet.
Other important settings include the security group, private IP address, public IP configuration, and availability zone.
7. Security Groups vs Network ACLs
AWS provides two important network security mechanisms: Security Groups and Network Access Control Lists (NACLs).
| Feature | Security Group | Network ACL |
|---|---|---|
| Level | Resource/ENI level | Subnet level |
| State | Stateful | Stateless |
| Rules | Allow rules | Allow and deny rules |
Security Groups are commonly used to control access to individual resources, while NACLs provide an additional layer of subnet-level traffic control. A typical web server security group might allow:
Type Port Source HTTP 80 0.0.0.0/0 HTTPS 443 0.0.0.0/0 SSH 22 Your office/VPN CIDR only
Because Security Groups are stateful, you don't need a matching outbound rule for return traffic — the response to an allowed inbound request is automatically permitted. NACLs, being stateless, require explicit rules in both directions, which is the detail that trips up most people the first time they configure one.
8. VPC Peering
VPC Peering allows two VPCs to communicate with each other using private IP addresses, as if they were part of the same network. This is commonly used when different teams, environments (staging vs. production), or even separate AWS accounts each have their own VPC but need to share resources — for example, a shared internal API or a central logging VPC.
A peering connection has a few constraints worth knowing before you plan around it:
-
The two VPCs cannot have overlapping CIDR ranges. If both VPCs were
created using the default
10.0.0.0/16, they cannot be peered without re-addressing one of them first. - Peering is non-transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, resources in VPC A cannot reach VPC C through that chain. Each pair needs its own direct peering connection.
- Route tables in both VPCs must be updated manually to point traffic for the peer's CIDR range across the peering connection — creating the connection alone does not route any traffic.
For anything beyond a small number of VPCs that all need to talk to each other, AWS Transit Gateway is usually a better fit than a mesh of individual peering connections, since peering connections don't scale well past a handful of VPCs.
9. VPC Endpoints
A VPC Endpoint lets resources in a private subnet reach certain AWS services without routing traffic through an Internet Gateway or NAT Gateway. This keeps traffic to services like S3 or DynamoDB inside the AWS network instead of going out over the public internet, which is both a security improvement and, since it avoids NAT Gateway data processing charges, often a meaningful cost saving.
There are two types:
- Gateway endpoints — supported only for S3 and DynamoDB. These work by adding a route to your route table and don't incur an hourly charge.
- Interface endpoints (AWS PrivateLink) — used for most other AWS services (such as Secrets Manager, SNS, or SQS). These create an elastic network interface with a private IP in your subnet, and do carry an hourly charge plus data processing fees.
A common pattern: an application server in a private subnet with no NAT Gateway at all, using a Gateway endpoint to reach S3 for file storage and an Interface endpoint to reach Secrets Manager for credentials — fully isolated from the public internet.
Common Mistakes to Watch For
A few issues come up repeatedly when setting up a VPC from scratch:
- Creating a subnet and forgetting to associate it with the intended route table — it silently falls back to the VPC's main route table, which can unintentionally make a "private" subnet public or vice versa.
- Not reserving room in the CIDR plan for future subnets, which forces a disruptive re-addressing project later.
- Placing a NAT Gateway in only one Availability Zone to save cost, which creates a single point of failure for every private subnet that depends on it.
- Assuming a Security Group change takes effect only on new connections — existing connections are also affected since Security Group evaluation is stateful and ongoing.
Final Thoughts
A VPC is more than a networking checkbox — the subnet layout, routing, and peering decisions you make early on shape how easily the application can scale and how exposed it is by default. Getting the basics above right before deploying EC2 instances, databases, or APIs will save you from most of the rework that comes from bolting on network architecture after the fact.