AWS Networking for Beginners: VPCs, Subnets and Traffic Flow Explained
A beginner-friendly guide to AWS networking that explains VPCs, subnets, route tables, gateways and security groups in plain language. It ends with a 30-minute hands-on project you can build in the console.
AWS Networking for Beginners: VPCs, Subnets and Traffic Flow Explained
Introduction
When I started learning AWS, the service I found most confusing was not EC2 or S3. It was networking. Terms like VPC, CIDR, route table, NAT gateway and security group all appeared at once, and every tutorial assumed I already knew what they meant.
This article is the guide I wish I had. We will build up an AWS network one piece at a time, in plain language. By the end you will understand how traffic gets from the internet to your server, and how to keep your database safely out of reach.
What you will learn:
- What a VPC is and how CIDR blocks work
- The difference between public and private subnets
- How route tables, Internet Gateways and NAT Gateways move traffic
- Security Groups vs Network ACLs
- How to connect networks together (peering, Transit Gateway, endpoints)
- A hands-on mini project you can build in the console
1. The big picture: what is a VPC?
A Virtual Private Cloud (VPC) is your own private, isolated network inside AWS. Think of it as a plot of land that belongs only to you. Nobody else can walk in unless you build a gate and give them the key.
Every VPC lives in one Region (for example, ap-south-1 in Mumbai or ap-south-2 in Hyderabad) and can span multiple Availability Zones (AZs), which are separate data centres within that Region.
CIDR blocks in plain English
When you create a VPC you choose an IP address range using CIDR notation, such as
10.0.0.0/16.- The part before the slash is the starting address.
- The number after the slash says how many bits are fixed. A smaller number means a bigger network.
/16gives you 65,536 addresses./24gives you 256.
A good habit is to pick a private range (
10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16) and avoid overlapping with other networks you may connect to later, such as your office or another VPC.2. Subnets: dividing your network
A subnet is a smaller slice of your VPC's address range, and it lives inside exactly one Availability Zone. We use subnets to separate things that need the internet from things that should not have it.
- Public subnet: has a route to the internet. Put load balancers and web servers here.
- Private subnet: has no direct route from the internet. Put databases and application servers here.
Importantly, a subnet is not "public" or "private" by a checkbox. It is public only because its route table sends internet-bound traffic to an Internet Gateway.
Good to know: AWS reserves 5 IP addresses in every subnet (the first four and the last one), so a /24 gives you 251 usable addresses, not 256.
3. Route tables: the road signs
A route table is a list of rules that tells traffic where to go. Each subnet is associated with one route table.
A public subnet's route table looks like this:
| Destination | Target |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | igw-xxxxxxxx (Internet Gateway) |
The first rule says "traffic for anything inside the VPC stays inside the VPC." The second says "everything else goes to the internet." A private subnet's route table has only the
local rule, or sends 0.0.0.0/0 to a NAT Gateway (see below).4. Gateways: the doors of your VPC
Internet Gateway (IGW)
The Internet Gateway is the door between your VPC and the public internet. It is horizontally scaled, highly available and free to attach. For an instance to be reachable from the internet it needs three things:
- A subnet whose route table points to the IGW
- A public IPv4 address (or Elastic IP)
- Security rules that allow the traffic
NAT Gateway
What if a server in a private subnet needs to download updates? It should be able to go out without letting anyone come in. A NAT Gateway sits in a public subnet and does exactly this. Private instances send outbound traffic to it, it forwards the traffic to the internet, and replies come back, but new inbound connections are blocked.
Cost tip: NAT Gateways are billed per hour plus per GB processed. For learning projects, delete them when you finish, or use VPC endpoints for AWS services (covered below) to avoid the data charges.
5. Security Groups vs Network ACLs
AWS gives you two layers of firewall. Beginners often mix them up, so here is the difference.
| Feature | Security Group | Network ACL |
|---|---|---|
| Applies to | Instance / network interface | Subnet |
| State | Stateful (replies allowed automatically) | Stateless (must allow both directions) |
| Rules | Allow only | Allow and deny |
| Evaluation | All rules together | In numbered order |
| Default | Denies all inbound, allows all outbound | Default NACL allows all |
For most projects, Security Groups do the heavy lifting. A powerful pattern is to reference one security group from another. For example, the database security group allows port 3306 only from the app server security group, rather than from an IP range. Then the database is reachable only by your app, even if IP addresses change.
6. Connecting networks together
As your architecture grows you will need to connect VPCs to each other and to AWS services.
- VPC Peering: a direct one-to-one connection between two VPCs. Simple and cheap, but not transitive (if A peers with B and B peers with C, A cannot reach C), and CIDR ranges must not overlap.
- AWS Transit Gateway: a central hub that connects many VPCs and on-premises networks. Use it when peering becomes a tangled web.
- VPC Endpoints: private connections from your VPC to AWS services such as S3 and DynamoDB, without going through the internet. Gateway endpoints for S3 and DynamoDB are free, and they keep traffic on the AWS network.
- Site-to-Site VPN and Direct Connect: connect your VPC to an office or data centre over encrypted internet tunnels or a dedicated physical link.
7. Name resolution and load balancing
Two more services complete the picture:
- Amazon Route 53 is AWS's DNS service. It translates names like
myapp.example.cominto IP addresses and can route users based on latency, health or geography. - Elastic Load Balancing (ELB) spreads traffic across multiple servers in different AZs. An Application Load Balancer sits in your public subnets and forwards requests to app servers in your private subnets.
Together, the request path for a typical web app is: User → Route 53 → Load Balancer (public subnet) → App server (private subnet) → Database (private subnet).
8. Hands-on mini project
Let's build a two-tier network in the console. This should take around 30 minutes.
- Create the VPC. In the VPC console choose Create VPC, select VPC and more, name it
demo, and set the CIDR to10.0.0.0/16. - Choose 2 AZs, 2 public subnets and 2 private subnets. The wizard builds the subnets and route tables for you.
- Add one NAT Gateway (in one AZ is fine for learning) and the S3 gateway endpoint.
- Launch a web server in a public subnet with a security group that allows HTTP (80) from anywhere and SSH (22) only from your own IP.
- Launch a second instance in a private subnet with a security group that allows traffic only from the web server's security group.
- Test it. Open the web server's public IP in your browser. Connect to the private instance through the web server and confirm it can reach the internet through the NAT Gateway but cannot be reached directly.
- Clean up. Delete the NAT Gateway, release Elastic IPs, terminate instances and delete the VPC to avoid charges.
Best practices to remember
- Plan your CIDR ranges before you build, and leave room to grow.
- Spread subnets across at least two AZs for high availability.
- Keep databases and internal services in private subnets.
- Use security group references instead of IP ranges where you can.
- Use VPC Flow Logs to see accepted and rejected traffic when debugging.
- Prefer VPC endpoints for S3 and DynamoDB to reduce NAT costs.
- Always clean up after experiments.
Common mistakes
- "My instance has a public IP but I can't reach it." Check the route table for an IGW route and the security group rules.
- "My private instance can't download packages." It needs a route to a NAT Gateway, and the NAT Gateway must itself sit in a public subnet.
- "Peering isn't working." Check for overlapping CIDRs, and make sure both sides have routes and security rules for the other VPC.
Conclusion
AWS networking looks intimidating, but it boils down to a few ideas: a VPC is your private network, subnets divide it, route tables decide where traffic goes, gateways open doors, and security groups guard each resource. Once these click, everything else in AWS becomes easier to design and debug.
If you build the mini project above, I would love to hear how it went. Share your results in the comments, and tell me which networking topic you want next: VPC Flow Logs, PrivateLink or Transit Gateway deep dive.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article