AWS Networking Fundamentals: VPCs, Subnets, Routing, IGWs, NACLs, and Security Groups

In this post, we'll explore some of the fundamental concepts behind AWS networking and understand how they work together.

The goal is to build a clear mental model of how network communication works inside AWS. By the end of this post, you should be able to explain the role of components such as Regions, Availability Zones (AZs), VPCs, Subnets, Route Tables, Internet Gateways (IGWs), Network ACLs (NACLs), and Security Groups (SGs).

At its core, networking is about enabling devices and resources to communicate and exchange data. In AWS, the same principle applies, but the network is defined and managed through cloud infrastructure.

Consider a simple example: an EC2 instance hosting an application that needs to be accessible from the internet. For a user to reach that instance, AWS needs a valid network path and a set of rules controlling how traffic moves through the infrastructure.

Understanding these components and how they interact provides the foundation for designing and troubleshooting AWS networks.

Documentation often uses abbreviations instead of full names. To become more familiar with this terminology, we'll use the abbreviations introduced throughout this post, such as AZ, VPC, IGW, NACL, and SG.

Region and Availability Zone

An AWS Region is a geographic area where AWS operates its cloud infrastructure.

Each Region is independent from the others and contains multiple Availability Zones (AZs). When you create resources in AWS, one of the first decisions you make is which Region they should belong to. For example, us-east-1 represents the US East (N. Virginia) Region, while sa-east-1 represents South America (São Paulo).

A useful way to visualize the hierarchy is:
AWS Global Infrastructure → Region → Availability Zones

Choosing a Region can affect factors such as latency, cost, service availability, and data residency requirements.

Something to keep in mind is that the closest Region is not always the best choice. When selecting a Region, you should evaluate trade-offs such as latency, cost, service availability, capacity, and reliability requirements.

For example, even if your users are located in South America, you might choose a Region in North America if the additional latency is acceptable and that Region provides better pricing, service availability, or other advantages for your workload.

VPC

Amazon VPC allows you to create a logically isolated virtual network within an AWS Region, where you can launch and manage AWS resources.

Inside a VPC, you define how your network should behave, including its IP address range, subnets, routing rules, internet connectivity, and network security. Resources such as EC2 instances, databases, and load balancers can then be deployed inside this network according to the level of connectivity and isolation they require.

Amazon VPC allows you to create a logically isolated virtual network within an AWS Region, where you can launch and manage AWS resources. Also, a VPC can span multiple Availability Zones.

In practice, the VPC acts as the main network boundary for your AWS resources.

Subnets

Subnets are used to divide a VPC into smaller network segments and organize resources according to their networking requirements.

Each subnet belongs to a single AZ. This allows you to distribute resources across isolated locations for better availability and fault tolerance.

A subnet can be designed as public or private, depending on how its routing is configured.

A private subnet is commonly used for resources that should not be directly accessible from the internet, such as databases containing customer or transactional data.

A public subnet is commonly used for resources that need direct internet connectivity, such as public-facing web servers or load balancers.

What determines whether a subnet is public or private is mainly its routing configuration.

A public subnet has a route to an Internet Gateway (IGW), which provides a path between the subnet and the internet. However, this does not automatically make every resource inside the subnet publicly accessible. For example, an EC2 instance also needs a public IP address and appropriate security rules to communicate directly with the internet.

A private subnet does not have a direct route to an IGW. It can still access the internet for outbound traffic through a NAT Gateway.

So, in practice, the distinction between public and private subnets comes primarily from how their route tables are configured.

It is very common to place compute resources, such as EC2 instances or load balancers, in a public subnet and databases in a private subnet.

In this architecture, users can reach the public-facing compute layer from the internet, while the database remains inaccessible directly from the internet. The database can still be reached by the application through the VPC's private network.

Internet Gateway

An Internet Gateway (IGW) is a VPC component that enables communication between resources inside the VPC and the internet.

An IGW is attached to a VPC and can be used as a target in a route table. For example:

0.0.0.0/0 → Internet Gateway

This route provides a path from the subnet to the internet. However, a resource such as an EC2 instance also needs a public IP address and appropriate security rules to communicate directly with the internet.

Route Table

A Route Table defines where network traffic from a subnet should be sent.

Each route contains two main pieces of information:

Field	Purpose
Destination	The IP range the traffic is trying to reach
Target	Where AWS should send that traffic

For example:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	Internet Gateway

The local route allows resources inside the VPC to communicate with each other. AWS automatically adds this route to every route table.

A route such as:

0.0.0.0/0 → Internet Gateway

means that traffic destined for addresses outside the VPC can be sent to the internet.

Each subnet must be associated with a route table. A route table can be associated with multiple subnets, but each subnet uses only one route table at a time. If no explicit association is defined, the subnet automatically uses the VPC's main route table.

Route tables are also what primarily distinguish public and private subnets:

• A public subnet has a route to an Internet Gateway (IGW).
• A private subnet does not have a direct route to an IGW. It may instead route outbound internet traffic through a NAT Gateway.

When multiple routes could match a destination, AWS uses the most specific matching route.

In short, a route table answers a simple question:

"Where should this packet go next?"

Network ACLs

A Network ACL (NACL) is a virtual firewall that controls inbound and outbound traffic at the subnet level.

You can think of it like passport control at an airport. Travelers represent network packets, while the passport control officer represents the NACL. Every time a traveler enters or leaves the country, their credentials are checked. Similarly, a NACL evaluates traffic whenever it enters or leaves a subnet.

NACLs are stateless, meaning inbound and outbound traffic are evaluated independently. If you allow traffic in one direction, you must also explicitly allow the corresponding traffic in the opposite direction.

The default behavior of a Network ACL (NACL) depends on whether it is the default NACL or a custom one.

NACL type	Default behavior
Default NACL	Allow all inbound and outbound traffic
Custom NACL	Deny all inbound and outbound traffic

Because NACLs are stateless, inbound and outbound traffic must be allowed independently.

NACL rules are evaluated in numerical order, starting with the lowest rule number. AWS stops evaluating rules as soon as it finds the first matching rule.

NACLs do not distinguish between requests and responses. They only evaluate whether a packet is entering or leaving the subnet. Because NACLs are stateless, both directions must be explicitly allowed. This applies both to response traffic and to new connections initiated by resources inside the subnet.

Security Groups

A Security Group (SG) is a virtual firewall attached to specific AWS resources, such as EC2 instances. While a NACL controls traffic at the subnet level, an SG controls traffic at the resource level.

Security Groups define which traffic is allowed to enter or leave a resource through inbound and outbound rules.

By default, a newly created SG:

• denies all inbound traffic;
• allows all outbound traffic.

SGs only support allow rules. Any traffic that does not match an allowed rule is implicitly denied.

One of the most important characteristics of Security Groups is that they are stateful. This means AWS keeps track of established connections.

For example, suppose an EC2 instance allows inbound HTTPS traffic on port 443:

Client → EC2
1.2.3.4:52000 → 10.0.1.10:443

If this connection is allowed by the SG, the response is automatically allowed:

EC2 → Client
10.0.1.10:443 → 1.2.3.4:52000

You do not need to create a separate outbound rule specifically for that response.

The same principle applies to connections initiated by the EC2 instance: if the outbound connection is allowed, the corresponding response traffic is automatically permitted.

By default, a new Security Group (SG) denies all inbound traffic and allows all outbound traffic.

Direction	Default behavior
Inbound	Deny all
Outbound	Allow all

If all outbound rules are removed, new outbound connections are denied. Because SGs are stateful, response traffic for an already allowed connection is still permitted automatically.

Differences between SGs and NACLs

Feature	Security Group (SG)	Network ACL (NACL)
Scope	Resource level	Subnet level
Association	Attached to resources such as EC2 instances	Associated with subnets
State	Stateful	Stateless
Rules	Allow rules only	Allow and deny rules
Rule evaluation	All rules are evaluated together	Rules are evaluated in numerical order
Return traffic	Automatically allowed for an established connection	Must be explicitly allowed in the opposite direction
Inbound traffic	Controlled by inbound rules	Controlled by inbound rules
Outbound traffic	Controlled by outbound rules	Controlled by outbound rules
Default behavior	New SGs deny inbound and allow outbound traffic	Default NACL allows all traffic; custom NACLs deny all traffic until rules are added
Typical use	Fine-grained protection of individual resources	Broad traffic control across an entire subnet
Best suited for	Defining which resources or clients can communicate with a workload	Subnet-wide restrictions, explicit deny rules, and additional network filtering

In short: use Security Groups as the primary resource-level firewall, and use NACLs when you need subnet-level controls or explicit deny rules.