AWS Networking Concepts Explained: VPC, Subnets, CIDR, Route 53, and CloudFront

If you are working through the AWS Cloud Practitioner certification or are new to Cloud Computing, the networking part is where a lot of people slow down. Terms like CIDR, subnets, Internet Gateway, NAT Gateway, and Route 53 get thrown around quickly, and it is easy to feel like you are memorising definitions without actually understanding what anything does.

This post breaks down every core networking concept in the module using plain language and diagrams. It assumes you have basic IT knowledge; you know what a server is, you have heard of IP addresses, but you are new to how AWS structures its networking layer.

This post is also a companion to the lab walkthrough: Build Your VPC and Launch a Web Server on AWS. Read this first, then do the lab.

Computer Networks and Subnets

A computer network is two or more devices connected together to share resources. In a typical office, every laptop, printer, and server is part of the same network.

Networks are divided into subnets: logical groupings of devices that can communicate directly with each other. Devices on different subnets communicate through a router, which decides where to send traffic based on the destination address.

Think of a network like a city. The city is the network. Neighbourhoods are subnets. The post office is the router; it reads the address on every piece of mail and decides which neighbourhood to deliver it to.

In AWS, this concept maps directly to how a VPC is structured: the VPC is the city, subnets are the neighbourhoods, and the router is managed automatically by AWS.

IP Addresses

Every device on a network has a unique IP address – a numerical label that identifies it, the same way a postal address identifies a house.

There are two versions in use today:

IPv4 is the original format. It consists of four groups of numbers separated by dots. For example, 192.168.1.100. Each group represents 8 bits, giving a total of 32 bits. This allows for approximately 4.3 billion unique addresses. That sounds like a lot, but the internet has run out of them, which is why IPv6 exists.

IPv6 uses 128 bits written as eight groups of hexadecimal characters. For example, 2001:0db8:85a3:0000:0000:8a2e:0370:7334. This allows for a practically unlimited number of addresses.

CIDR (Classless Inter-Domain Routing)

When setting up a VPC or subnet on AWS, address ranges are defined using CIDR notation. This is the format you will see everywhere in networking: 10.0.0.0/16, 10.0.1.0/24, 0.0.0.0/0.

CIDR notation is written as an IP address followed by a forward slash and a number. For example, 10.0.0.0/24. The number after the slash tells you how many bits of the address are fixed (shared by all addresses in the block). The remaining bits are flexible and represent individual addresses within the block.

Here is how to read the most common CIDR blocks:

Two special cases worth memorising for the exam:

• /32 – all bits are fixed, meaning it refers to exactly one IP address. Used in security group rules to allow access from a single specific host.
• 0.0.0.0/0 – all bits are flexible, meaning it covers every possible IP address. Used in route tables to say “send all other traffic to the Internet Gateway.”

AWS enforces limits on CIDR block sizes within a VPC. The largest VPC allowed is /16 (65,536 addresses). The smallest subnet allowed is /28 (16 addresses, of which only 11 are usable. AWS reserves 5 in every subnet for internal routing, DNS, and future use).

Amazon VPC (Virtual Private Cloud)

An Amazon VPC is your own isolated section of the AWS cloud. It is a virtual network that you define; you choose the IP address range, divide it into subnets, and control what traffic can enter or leave.

Think of AWS as a massive office building with thousands of companies sharing the space. A VPC is your company’s private floor. You have your own walls, your own rooms, your own lock on the door. Other companies in the same building cannot see into your floor at all.

Public vs Private Subnets

A VPC is typically divided into public and private subnets:

Public subnets are internet-facing. Resources placed here, web servers, load balancers, can receive traffic directly from the internet. A public subnet has a route table entry that sends internet-bound traffic (0.0.0.0/0) to an Internet Gateway.

Private subnets are internal. Resources placed here: databases, application servers; are not directly reachable from the internet. They can still make outbound requests (for software updates, API calls) through a NAT Gateway, but no unsolicited inbound traffic can reach them.

A subnet is only “public” because of its route table. If the route table has a path to an Internet Gateway, the subnet is public. There is no other distinction; the subnet itself has no inherent public or private property.

Internet Gateway

The Internet Gateway is the front door of the VPC. It sits at the edge and handles all traffic between the VPC and the public internet. Every VPC has at most one Internet Gateway.

NAT Gateway

The NAT Gateway (Network Address Translation Gateway) sits inside a public subnet and acts as a proxy for private subnet resources. When a database server in a private subnet needs to download an update, the request goes to the NAT Gateway, which forwards it to the internet on behalf of the private instance. The response comes back to the NAT Gateway, which passes it along. At no point does the private instance have a public IP address.

Route Tables

A route table is a set of rules that tells AWS where to send network traffic. Every subnet must be associated with a route table.

A typical public subnet route table looks like this:

The first rule says: traffic destined for any address within the VPC stays local. The second rule says: everything else goes to the Internet Gateway.

A private subnet route table replaces the Internet Gateway with the NAT Gateway:

VPC Security – Security Groups and Network ACLs

AWS provides two layers of traffic control within a VPC.

Security Groups

A security group is a virtual firewall applied at the instance level. When an EC2 instance is launched, one or more security groups are attached to it. Every inbound and outbound connection is checked against the security group rules before being allowed through.

Key characteristics:

• Instance level – applied to individual EC2 instances, not subnets
• Stateful – if inbound traffic is allowed, the corresponding reply is automatically allowed out. There is no need to write a matching outbound rule
• Allow rules only – there are no deny rules. Anything not explicitly allowed is blocked by default

A typical web server security group would have a single inbound rule: allow TCP on port 80 from 0.0.0.0/0. This permits HTTP traffic from any IP address. All other traffic is blocked automatically.

Network ACLs

A Network ACL (Access Control List) operates at the subnet level. It checks traffic entering and leaving an entire subnet before it reaches any instances inside.

Key characteristics:

• Subnet level – applied to all instances in a subnet
• Stateless – inbound and outbound traffic are evaluated independently. If inbound HTTP is allowed, an explicit outbound rule must also allow the response
• Allow and deny rules – unlike security groups, Network ACLs support explicit deny rules

In most configurations, security groups do the heavy lifting. Network ACLs are used as an additional layer when stricter subnet-level control is needed.

Amazon Route 53

Amazon Route 53 is AWS’s managed DNS (Domain Name System) service. DNS is the system that translates human-readable domain names, like frankremmy.com, into IP addresses that computers use to connect.

The name comes from port 53, which is the standard network port for DNS traffic.

When a user types a domain name into their browser, the following happens:

1. The browser sends a DNS query asking “what is the IP address for this domain?”
2. Route 53 looks up the domain record and returns the corresponding IP address
3. The browser connects directly to that IP address
4. The website loads

Beyond basic DNS resolution, Route 53 supports several routing policies that control how traffic is distributed:

• Simple routing – one record, one destination
• Weighted routing – split traffic between multiple destinations by percentage. Useful for gradual deployments
• Latency-based routing – sends users to the AWS region with the lowest latency for their location
• Failover routing – automatically redirects traffic to a backup resource if the primary becomes unhealthy
• Geolocation routing – routes users based on their geographic location

Route 53 also performs health checks on your resources and can automatically remove unhealthy endpoints from DNS responses.

Amazon CloudFront

Amazon CloudFront is AWS’s Content Delivery Network (CDN). A CDN solves a simple problem: if your server is in the United States and a user is in Portugal, every request they make has to travel across the Atlantic and back. That takes time.

CloudFront solves this by caching copies of your content at over 400 Edge Locations distributed around the world. When a user makes a request, CloudFront serves the content from the nearest Edge Location rather than from your origin server.

Think of it like a popular book published in the US. Instead of every international reader ordering directly from the US warehouse, the publisher puts copies in local bookshops around the world. Someone in Portugal orders from the Portuguese bookshop, not from across the ocean.

How it works

1. A user requests content – an image, a video, a web page
2. CloudFront checks if the content is cached at the nearest Edge Location
3. Cache hit – the content is served immediately from the Edge Location. Fast
4. Cache miss – CloudFront fetches the content from the origin server, caches it at the Edge Location for future requests, and returns it to the user

CloudFront integrates directly with Route 53. Route 53 resolves the domain, and CloudFront delivers the content from the nearest edge. Combined, they are the standard setup for globally distributed, low-latency web applications on AWS.

How It All Fits Together

These services do not operate independently; they form a layered architecture:

1. Route 53 resolves the domain name to an IP address
2. CloudFront serves cached content from the nearest Edge Location, forwarding cache misses to the origin
3. The Internet Gateway receives traffic entering the VPC
4. Route tables direct that traffic to the correct subnet
5. Network ACLs check traffic at the subnet boundary
6. Security groups check traffic at the instance level
7. The EC2 instance receives and responds to the request
8. For private resources, the NAT Gateway handles outbound-only internet access

Understanding this flow is what makes a VPC lab make sense. Every component you create in that lab exists to handle one specific step in this chain.

Key Terms Reference