AWS Builder Center

Builder Center

Amazon VPC Explained: Build a Secure Network for Your AWS Applications

Understand how Amazon VPC works with subnets, route tables, internet gateways, NAT gateways, security groups, and network ACLs. This guide explains how these components work together to build secure AWS architectures.

Amazon VPC Explained: Build a Secure Network for Your AWS Applications

When we deploy applications on AWS, we often focus on services like EC2, RDS, S3, Lambda, and ECS.
But there is another layer connecting many of these services together:
Networking.
This is where Amazon Virtual Private Cloud (VPC) becomes important.
A VPC allows us to create a logically isolated network environment in AWS where we can launch and connect resources according to our architecture and security requirements.
Understanding VPC is one of the most important steps toward understanding AWS architecture.

What Is Amazon VPC?

Amazon VPC stands for Amazon Virtual Private Cloud.
In simple terms, a VPC is your own logically isolated network inside AWS.
You can control things such as:
  • IP address ranges
  • Subnets
  • Routing
  • Internet connectivity
  • Network access
  • Security boundaries
A simplified architecture looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
AWS Region
|
v
 VPC
|
┌─────────┴─────────┐
| |
 Public Subnet Private Subnet
| |
v v
 Load Balancer Application
|
v
 RDS
The VPC provides the networking foundation for the architecture.

1. Understanding IP Addresses

Before understanding subnets, it's useful to understand IP addresses.
When creating a VPC, you specify an IP address range using CIDR notation.
For example:
1
10.0.0.0/16
This gives the VPC a private IP address range that can be divided into smaller subnet ranges.
For example:
1
2
3
4
5
6
7
8
9
VPC
10.0.0.0/16

|
+---- Public Subnet
| 10.0.1.0/24
|
+---- Private Subnet
10.0.2.0/24
The exact CIDR ranges depend on the architecture.
The important concept is:
A VPC provides the overall network, while subnets divide that network into smaller segments.

2. What Is a Subnet?

A subnet is a smaller network inside your VPC.
For example:
1
2
3
4
5
6
7
8
VPC: 10.0.0.0/16

|
├── Public Subnet
| 10.0.1.0/24
|
└── Private Subnet
10.0.2.0/24
Resources are launched into subnets.
This allows us to organize resources according to their networking requirements.
For example:
1
2
3
4
5
6
7
8
Public Subnet
|
└── Application Load Balancer

Private Subnet
|
├── EC2
└── RDS

3. Public vs Private Subnets

This is one of the most important VPC concepts.
A public subnet has a route that provides a path to an Internet Gateway.
A private subnet does not have a direct route to the Internet Gateway.
A common architecture looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Internet
|
v
 Internet Gateway
|
┌────────────┴────────────┐
| |
v v
 Public Subnet Private Subnet
| |
v v
 Load Balancer Application
|
v
 RDS
The idea is to avoid exposing resources that don't need direct internet access.

4. Internet Gateway

An Internet Gateway (IGW) allows communication between resources in a VPC and the internet when the appropriate routing and security configuration exists.
For example:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
Internet Gateway
|
v
Public Subnet
|
v
Load Balancer
The Internet Gateway is attached to the VPC.
However, simply attaching an Internet Gateway doesn't automatically make every resource publicly accessible.
Routing and security configuration still matter.

5. Route Tables

A route table determines where network traffic should go.
Think of it as a set of instructions:
1
2
3
4
Destination Target
--------------------------------
10.0.0.0/16 Local
0.0.0.0/0 Internet Gateway
For a public subnet, a route might look conceptually like:
1
2
3
4
0.0.0.0/0
|
v
Internet Gateway
For a private subnet, the route may instead send outbound internet traffic through a NAT Gateway when required.
Route tables are therefore a fundamental part of VPC networking.

6. NAT Gateway

A common question is:
If an application is in a private subnet, how can it access the internet for things like package updates?
One solution is a NAT Gateway.
The basic architecture is:
1
2
3
4
5
6
7
8
9
10
Private Subnet
|
v
NAT Gateway
|
v
Internet Gateway
|
v
Internet
This allows resources in private subnets to initiate outbound connections while avoiding direct inbound internet connectivity to those resources through the NAT path.
A NAT Gateway is typically placed in a public subnet.

7. Security Groups

Security groups act as virtual firewalls for supported AWS resources.
For example, suppose an application server needs to connect to PostgreSQL.
Instead of allowing database traffic from everywhere, we can restrict it to the application's security group.
Conceptually:
1
2
3
4
5
Application Security Group
|
| TCP 5432
v
RDS Security Group
This is much more controlled than:
1
2
3
4
5
Internet
|
| TCP 5432
v
RDS
Security groups are stateful, meaning the return traffic for an allowed connection is automatically handled according to the stateful behavior of the security group.

8. Network ACLs

A Network Access Control List (Network ACL) operates at the subnet level.
A simplified way to remember the difference is:
1
2
3
4
5
6
7
Security Group
↓
Resource level

Network ACL
↓
Subnet level
Network ACLs are stateless, so inbound and outbound rules need to be considered separately.
For many application architectures, security groups handle most of the resource-level access control, while NACLs can provide an additional subnet-level control layer.

9. VPC and EC2

Let's connect VPC concepts to something we've already discussed: EC2.
A typical architecture could be:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Internet
|
v
 Internet Gateway
|
v
 ┌──────────────────┐
│ VPC │
│ │
│ Public Subnet │
│ | │
│ v │
│ Load Balancer │
│ │
│ Private Subnet │
│ | │
│ v │
│ EC2 │
└──────────────────┘
The EC2 instance doesn't need to be directly exposed to the internet.
The load balancer can receive external traffic and forward appropriate requests to the application.

10. VPC and RDS

RDS is another excellent example.
Instead of exposing a database publicly:
1
2
3
4
Internet
|
v
RDS
we can place the database in private subnets:
1
2
3
4
5
6
7
8
9
10
11
12
13
Internet
|
v
Load Balancer
|
v
Application
|
v
Private Subnet
|
v
RDS
This creates a stronger network boundary around the database.
The application communicates with RDS through private networking.

11. Availability Zones

AWS Regions contain multiple Availability Zones.
A VPC can span multiple Availability Zones.
For example:
1
2
3
4
5
6
7
8
9
VPC
|
┌──────────┴──────────┐
| |
v v
 Availability Zone A Availability Zone B
| |
v v
 Subnets Subnets
Using multiple Availability Zones can help design applications for higher availability.
For example:
1
2
3
4
5
6
Load Balancer
/ \
/ \
v v
EC2 A EC2 B
AZ-A AZ-B
If one Availability Zone experiences an issue, the architecture can potentially continue serving traffic from another Availability Zone, depending on the design.

12. A Real-World Three-Tier Architecture

A common architecture pattern is a three-tier application.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Users
|
v
 Application LB
|
┌────────────┴────────────┐
| |
v v
 App Server A App Server B
AZ-A AZ-B
| |
└────────────┬────────────┘
|
v
Database
RDS
The tiers can be separated into appropriate subnet layers.
For example:
1
2
3
4
5
6
7
8
9
10
11
Public Subnets
|
└── Load Balancer

Private App Subnets
|
└── Application Servers

Private Database Subnets
|
└── RDS
This separation provides a clear network architecture.

13. VPC Endpoints

Not every AWS service access pattern needs to go through the public internet.
VPC endpoints can allow resources in a VPC to access supported AWS services through private connectivity.
For example:
1
2
3
4
5
6
7
Private Subnet
|
v
VPC Endpoint
|
v
AWS Service
This can be useful when designing private application architectures.
It can also reduce the need for certain traffic to traverse public network paths.

14. DNS in a VPC

DNS is another important part of networking.
AWS provides DNS functionality within VPC environments through Amazon Route 53 Resolver and related VPC DNS features.
Applications often rely on DNS to resolve service names rather than directly using IP addresses.
For example:
1
2
3
4
5
6
7
api.example.com
|
v
DNS Resolution
|
v
Application Endpoint
Understanding DNS becomes increasingly important as your architecture grows.

15. Common VPC Mistakes

Mistake 1: Making Everything Public

A beginner might place every resource in a public subnet.
This isn't usually necessary.
Think carefully about which resources actually need internet-facing access.

Mistake 2: Opening Every Port

Avoid rules such as:
1
0.0.0.0/0
for sensitive services unless there is a clear reason.
Restrict access as much as possible.

Mistake 3: Exposing Databases

Databases generally don't need direct public access.
Keep them behind appropriate network boundaries.

Mistake 4: Forgetting Route Tables

A resource can have a valid IP address and still be unable to communicate because the routing configuration is incorrect.

Mistake 5: Confusing Security Groups and NACLs

Remember:
1
2
3
4
5
Security Group
→ Resource-level control

NACL
→ Subnet-level control
And:
1
2
3
4
5
Security Group
→ Stateful

NACL
→ Stateless

16. Troubleshooting VPC Connectivity

When something cannot connect, don't immediately change every setting.
Work through the network path.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Client
|
v
DNS
|
v
Load Balancer
|
v
Security Group
|
v
Subnet
|
v
Route Table
|
v
Application
|
v
Database
Check each layer independently.
Ask:
  1. Is DNS resolving correctly?
  2. Is the resource reachable?
  3. Is the route correct?
  4. Does the security group allow the traffic?
  5. Does the NACL allow the traffic?
  6. Is the application listening on the expected port?
  7. Is the database accepting connections?
This systematic approach makes network troubleshooting much easier.

17. A Complete Example

Imagine we're deploying a Node.js application with PostgreSQL.
A possible AWS architecture could be:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Users
|
v
 Application LB
|
┌─────────────┴─────────────┐
| |
v v
 Node.js App A Node.js App B
Private AZ-A Private AZ-B
| |
└─────────────┬─────────────┘
|
v
RDS PostgreSQL
Private Subnet
The supporting networking could include:
1
2
3
4
5
6
7
8
9
10
11
VPC
|
├── Public Subnets
│ └── Load Balancer
│
├── Private App Subnets
│ ├── Application A
│ └── Application B
│
└── Private DB Subnets
└── RDS
This is a much more realistic architecture than simply placing everything on one public EC2 instance.

18. VPC Design Checklist

Before deploying an application, consider:
  • What CIDR range should the VPC use?
  • How many Availability Zones are needed?
  • Which subnets should be public?
  • Which resources should remain private?
  • What routes are required?
  • Does the application need outbound internet access?
  • Is a NAT Gateway required?
  • Which ports need to be accessible?
  • Which security groups are required?
  • Does the database need public access?
  • Would VPC endpoints be useful?
  • How will DNS work?
  • How will the architecture handle an Availability Zone failure?
These questions help turn a collection of AWS services into an actual architecture.

What I Learned

VPC initially looked like just another AWS service.
But it is more accurate to think of it as the networking foundation around many AWS workloads.
The key concepts are:
1
2
3
4
5
6
7
8
9
10
VPC
|
├── CIDR
├── Subnets
├── Route Tables
├── Internet Gateway
├── NAT Gateway
├── Security Groups
├── Network ACLs
└── VPC Endpoints
Once these concepts become clear, services like EC2, ECS, RDS, and load balancers become much easier to understand.

Conclusion

Amazon VPC is one of the most important AWS concepts for anyone learning cloud architecture.
You don't need to memorize every networking feature on day one.
Start with the fundamentals:
VPC → Subnets → Routes → Internet Gateway → Security Groups
Then gradually add:
NAT → Load Balancers → VPC Endpoints → Multi-AZ Architecture
The real goal isn't simply to create a VPC.
It's to understand how network traffic moves through your architecture and how to control that traffic securely.
As I continue my AWS journey, I'm focusing on understanding these fundamentals by building practical architectures rather than just memorizing services.
Understand the network. Understand the architecture. Build better cloud applications. ☁️🚀
# aws-api# amazon-vpc# cloud-networking
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article