AWS VPC, Security Groups, and NACLs: A Beginner’s Guide

KirtiKirti
5 min read

What is AWS ? Why is it needed?

AWS stands for Amazon web services . It is one of the leading cloud service provider (CSP) as it offers compute power (VMs) , database, storage solution , networking capabilities for individual. organisations , startups as a on demand service . AWS is architected to be the most flexible and secure cloud computing environment available today.

When you deploy applications in the cloud, it's not just about servers and storage but it's also about how your resources communicate with each other and with the internet. That’s where networking comes in.

At the heart of AWS networking is the Amazon VPC (Virtual Private Cloud) that is a logically isolated network where you can launch and manage your AWS resources. Along with VPC, Security Groups and Network ACLs (NACLs) help define how traffic flows in and out of your cloud environment.

In this blog, we'll break down these core networking concepts:

  • What is a VPC and how does it work?

  • How do Security Groups protect your EC2 instances?

  • What role do NACLs play in subnet-level security?

And when should you use each one?

Understanding AWS VPC ?

VPC stands for Virtual Private Cloud which is exactly like it sounds your personal virtual and private space within the cloud where you can place all your resources, like EC2 instances, databases, and other services. Think of it like this: a VPC is your private network space in the cloud — you decide the rules, the structure, and who gets access.

Think of a VPC like your own gated community:

  • The main gate (Internet Gateway) controls who goes in and out.

  • Houses inside are like subnets — some are open to visitors (public), others are locked down (private).

  • You decide the rules — who can visit, who can leave, and which roads (route tables) connect them.

Essential Basics :

  • IP Range : You define a IP range using CICR block . This tells us how many IP address we can use inside the VPC.

  • Subnets : It is used to divide the VPC in smaller chunks/parts . It can either be Public (internet access) or Private (doesnt have direct internet access)

  • Route tables : These decide how traffic moves between subnets and to the internet.

  • Internet Gateway : It is used when you want your public subnet to have access to the internet.

  • NAT Gateway : It is used by Private subnet (like backend servers) for outgoing internet access but block incoming traffic.

You know the best part ? AWS gives you a default VPC in every region, so you can start deploying right away but you should create custom VPCs for real-world projects.

Security Groups in AWS

Once your VPC is set up, the next thing to focus on is security — and that’s where Security Groups (SGs) come in.

A Security Group is like a virtual firewall that controls the traffic going in and out of your EC2 instances. It works at the instance level, deciding who can connect and who can't.

Fun fact: Security Groups are stateful — if you allow inbound traffic (e.g., SSH on port 22), the outbound response is automatically allowed. You don’t need to write two rules for one connection.

  • SGs only work with allow rules — if a rule isn’t specified, the traffic is blocked by default.

  • This makes your setup simpler and more secure.

Network Access Control Lists (NACLs) in AWS

A NACL is like a traffic filter for your subnet. It controls inbound and outbound traffic at the subnet boundary, before it even reaches your EC2 instances.

While Security Groups are attached to instances, NACLs are attached to subnets. So anything inside that subnet follows the same rules.

Allow and Deny Rules (Yep, Both!)

Unlike Security Groups, which only allow traffic, NACLs can be configured to both allow and explicitly deny traffic. This gives you more control — especially if you want to block specific IPs or ports. NACLs are stateless which means you have to define both inbound as well as outbound rule .

Rule Evaluation by Number

Each rule in a NACL has a rule number, and traffic is checked in the order of those numbers. Once a match is found, AWS stops checking further.

For example, you can set up rules like:

  • Rule #100: Block traffic from a specific IP range

  • Rule #200: Allow HTTP traffic from anywhere

And Deny always wins — if a deny rule matches, the traffic is blocked no matter what.

Comparing Security Groups and NACLs

Say you’re running a web app — your frontend might be in a public subnet, while the backend and database live in private subnets protected by a NAT Gateway

When Should You Use Each?

✅ Use Security Groups when:

  • You want to control access to a specific EC2 instance.

  • You're building an application with multiple tiers (web, app, DB), each needing different rules.

  • You prefer simplicity — SGs are easier to manage and troubleshoot.

✅ Use NACLs when:

  • You need to block specific IP addresses or ports.

  • You want subnet-wide protection (e.g., block SSH to a subnet completely).

  • You need to set global deny rules that apply before SGs are even evaluated.

Final Thoughts

AWS networking can feel confusing at first — there’s a lot of new terms and moving parts. But once you get the hang of it, you’ll realize it’s really just about controlling how your stuff talks to other stuff — inside your cloud and with the outside world.

Here’s a quick recap:

  • VPC is your own private space in the AWS cloud — like your own network.

  • Security Groups act like bodyguards for your EC2 instances, only letting in traffic you allow.

  • NACLs sit at the gate of your subnet, filtering traffic at a higher level.

  • Use both — so you have security at both the house and the neighborhood level.

Once you understand how these pieces fit together, you’ll be able to build cloud environments that are not just functional, but secure, well-structured, and ready for real-world use.

0
Subscribe to my newsletter

Read articles from Kirti directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Kirti
Kirti

Hi, I'm KirtiI’m actively learning AWS, Python automation, and cloud best practices through real-world projects. Every challenge is a step forward, and every solution is something worth sharing. On this blog, you’ll find: Simplified guides on AWS core services Lessons from my journey breaking into cloud engineering I believe in learning in public—and this blog is where I document my progress, challenges, and wins.