Security Group vs NACL in AWS

By Ravindra Bagale, trainer · LinkedIn · Last updated: 18 October 2026

1. Why a custom VPC

Why: a real application has three tiers: web, app and database. Only the web tier should face the internet. The app and database servers hold the code and the data, so nobody outside should be able to reach them at all.

What: a custom VPC is a VPC you design yourself: your own CIDR, your own subnets, and your own decision about which subnet is public. AWS also gives every account a default VPC, and the two behave very differently.

2. Default VPC vs custom VPC

Why the default VPC exists: so that a beginner can launch a server in the first minute, without knowing anything about networks.

1. AWS makes one default VPC in every Region, with CIDR 172.31.0.0/16.
2. It has a default /20 subnet in every Availability Zone.
3. An internet gateway is already attached.
4. Its main route table already has 0.0.0.0/0 → internet gateway, so every default subnet is public.

A custom VPC starts empty:

1. No subnets until you create them.
2. No internet gateway until you attach one.
3. Its main route table has only the local route, so everything is private until you add a route.

Rule: the default VPC is for learning and quick tests. For production, build a custom VPC, so that only the subnets you choose are public.

3. Route tables: a quick reminder

A route table has two columns, read left to right: Destination (a CIDR) and Target (where to send it). The details are in Route tables: Destination and Target. For this chapter you need three facts:

1. Every route table has 10.0.0.0/16 → local, so all subnets of the VPC can talk to each other.
2. The public route table adds 0.0.0.0/0 → igw-.... The private route table does not.
3. A subnet without an explicit association uses the main route table.

4. What a VPC costs

Why it matters: students leave things running and get a bill. Know which parts are free.

Free:

1. The VPC itself, subnets and route tables.
2. The internet gateway.
3. Security groups and network ACLs.

You pay for:

1. Data going out of AWS to the internet. The first 100 GB per month are free; after that it is charged per GB.
2. Public IPv4 addresses, charged by the hour for every public IP, used or not.
3. NAT gateways, charged per hour and per GB of data they process.

5. A custom VPC for three tiers

The plan (VPC 10.0.0.0/16, one /20 per tier):

1. Public subnet 10.0.0.0/20: the web server with Nginx and the HTML pages, such as signup.html.
2. Private subnet 10.0.16.0/20: the app server with PHP.
3. Private subnet 10.0.32.0/20: the database server with MySQL (MariaDB).
4. Public route table: 10.0.0.0/16 → local and 0.0.0.0/0 → internet gateway. Associate only the web subnet.
5. Private route table: 10.0.0.0/16 → local only. The app and DB subnets use it.

The app and DB servers have no route to the internet and no public IP, so nobody outside can reach them. They can still talk to the web server through the local route.

6. The path of one request

Suppose we are Instagram, hosted in the Mumbai Region (ap-south-1), and a user opens the signup page on a phone. The request travels:

1. Phone → mobile tower → internet.
2. Internet → AWS Mumbai Region.
3. Internet gateway: the door of the VPC.
4. Route table: sends it to the web subnet.
5. NACL: the firewall of the subnet.
6. Security group: the firewall of the server.
7. Nginx on the web server answers.

So a request passes two firewalls: first the NACL at the subnet door, then the security group at the server door.

7. Security group vs NACL

Security group: a firewall on the instance (on its network card). You met it in Security groups chained tier by tier.

NACL (network access control list): a firewall on the subnet. Every server in the subnet is behind it.

Why have both: suppose one IP is attacking us. A /20 subnet can hold 4,091 servers. With security groups only, you would have to touch the rules of every server, and the bad traffic would still reach each server. One deny rule in the NACL stops it at the subnet door, before it reaches any server.

More comparisons are in Security group vs NACL.

8. Stateful vs stateless

Stateful (security group): it remembers each connection. If a request was allowed in, its reply is allowed out automatically. You write the inbound rule only.

Stateless (NACL): it remembers nothing. The request coming in and the reply going out are checked separately, so you need an inbound rule for the request and an outbound rule for the reply.

9. Ephemeral ports: where the reply goes

Why it matters: if you write the NACL outbound rule for the wrong port, the page never loads.

Worked example: a phone opens https:// on our web server.

1. The phone picks a random high port for this connection, for example 41296. This is an ephemeral (short-lived) port.
2. The request goes from phone port 41296 to server port 443.
3. The server replies from its own port 443 to the phone's port 41296. The server does not switch to another port.
4. Security group: stateful, so the reply is allowed automatically.
5. NACL: stateless, so the reply needs an outbound rule. The phone's port is random, so allow the whole ephemeral range: outbound 1024-65535 to 0.0.0.0/0.

The other direction: when the server itself makes a call, for example sudo yum install nginx -y, the server is the client. It picks the ephemeral port, and the replies come back to it. So the NACL inbound rules must also allow 1024-65535.

10. The defaults

1. Security group: all inbound denied, all outbound allowed. You add allow rules only; there is no deny rule.
2. Default NACL (made together with the VPC): allows all traffic in and out. Every new subnet uses it until you choose another one.
3. A NACL you create: denies all traffic in and out until you add rules.

So to block one IP, a security group can't help: it has no deny. You need a NACL deny rule.

11. NACL rules: the lowest number wins

Each NACL rule has: Rule number, Type, Protocol, Port range, Source (inbound) or Destination (outbound), and Allow or Deny.

How a NACL decides:

1. It checks the rules from the lowest rule number up.
2. The first rule that matches decides. The rest are not read.
3. The last rule, *, denies everything that matched nothing. You can't delete it.

Worked example. Suppose we are Instagram. Attacker 3.3.3.3 is flooding port 80; a normal user is 7.7.7.7.

Wrong order:

1. Rule 1: allow HTTP 80 from 0.0.0.0/0.
2. Rule 2: deny HTTP 80 from 3.3.3.3/32.
3. The attacker's request matches rule 1 first: allowed. Rule 2 is never read.

Right order:

1. Rule 1: deny HTTP 80 from 3.3.3.3/32.
2. Rule 2: allow HTTP 80 from 0.0.0.0/0.
3. 3.3.3.3 matches rule 1: denied.
4. 7.7.7.7 doesn't match rule 1, matches rule 2: allowed.

Rule: the deny rule must get a smaller number than the allow rule it should beat.

12. Leave gaps between rule numbers

Why: the site is live. Next week the attacker moves to 4.4.4.4. If your rules are 1, 2, 3 there is no room for a new deny above the allow rule, and renumbering live rules is risky.

How: number rules in steps, for example 10, 20 ... 100.

1. Live rules: 10 deny 3.3.3.3/32, 100 allow 0.0.0.0/0, * deny.
2. The attacker moves to 4.4.4.4: add rule 20 deny HTTP 80 from 4.4.4.4/32.
3. Rule 20 fits between 10 and 100. No live rule changes.

Limits: rule numbers go from 1 to 32766. A NACL can have 20 inbound and 20 outbound rules by default; AWS can raise that to 40 each. Rules can be edited or deleted any time.

13. One public server: send .php to the app server

Why: in this design the web server is the only server the internet can reach. HTML, images and CSS can be served from it directly. But the PHP code lives on the private app server.

Suppose we are Instagram: the page asks for /get_reels.php. The public Nginx must hand that request to the app server and send the answer back to the browser. This is a reverse proxy, as in Put Nginx in front as the reverse proxy.

How (on the web server):

1. Open the config: sudo nano /etc/nginx/nginx.conf.

2. Inside the server { ... } block, add:

   location ~ \.php$ {
       proxy_pass http://10.0.16.7;
   }
   

3. ~ means "the next part is a regular expression". \.php$ means "the path ends with .php" (\. is a real dot, $ is the end).

4. 10.0.16.7 is the app server's private IP. Use the IP of your own app server; it must be inside the app subnet 10.0.16.0/20.
5. Test the config: sudo nginx -t.
6. Reload: sudo service nginx reload.

Now /signup.html is served by the web server itself, and /get_reels.php goes to the app server.

14. The app server answers the request too

The request reaches the app server over HTTP, so the app server also needs a web server to receive it: its own private Nginx with php-fpm, set up as in The server: Nginx, php-fpm and MariaDB. That Nginx passes the .php file to php-fpm, PHP builds the HTML, and the answer goes back through the public Nginx to the browser.

Security group of the app server: allow HTTP 80 with the source = web server's security group. Nobody else can call it.

15. PHP connects to the database on a private IP

PHP needs four values to connect: server name, username, password, database name (The four connection values). When the database is on the same server, the server name is localhost. Now it is on its own server, so only the server name changes, to the DB server's private IP:

$servername = "10.0.32.10";         // DB server's private IP (example)
$username   = "appuser";
$password   = "YOUR_APP_PASSWORD";
$database   = "insta";

10.0.32.10 is an example inside the DB subnet 10.0.32.0/20; use your own DB server's private IP.

Three must-dos on the DB server:

1. Listen on the network. In /etc/my.cnf.d/mariadb-server.cnf, bind-address must not be 127.0.0.1 (remove that line or set bind-address=0.0.0.0). Then sudo service mariadb restart.

2. A user for the app server's IPs, not for localhost:

   CREATE USER 'appuser'@'10.0.16.%' IDENTIFIED BY 'YOUR_APP_PASSWORD';
   GRANT ALL PRIVILEGES ON insta.* TO 'appuser'@'10.0.16.%';
   

   10.0.16.% means "any IP that starts with 10.0.16.", that is, from the app subnet. 3. Security group of the DB server: allow MySQL/Aurora 3306 with the source = app server's security group.

The chain: web SG allows 80/443 from 0.0.0.0/0 → app SG allows 80 from the web SG only → DB SG allows 3306 from the app SG only.

16. Build it in the console

Part A: the network (as in Build it in the console)

1. VPC > Your VPCs > Create VPC, VPC only, name my-vpc, IPv4 CIDR 10.0.0.0/16.
2. Create subnets web-a (10.0.0.0/20, ap-south-1a), app-b (10.0.16.0/20, ap-south-1b), db-c (10.0.32.0/20, ap-south-1c).
3. Create and attach the internet gateway my-igw.
4. Create public-rt: add 0.0.0.0/0 → my-igw, associate web-a only.
5. Leave app-b and db-c on the main route table, which has local only.

Part B: security groups (EC2 > Security Groups > Create security group, VPC my-vpc)

1. web-sg: inbound HTTP 80 and HTTPS 443 from 0.0.0.0/0, SSH 22 from My IP.
2. app-sg: inbound HTTP 80, source web-sg.
3. db-sg: inbound MySQL/Aurora 3306, source app-sg.

Part C: servers

1. Launch the web server in web-a with web-sg, Auto-assign public IP: Enable.
2. Launch the app server in app-b with app-sg, Auto-assign public IP: Disable.
3. Launch the DB server in db-c with db-sg, Auto-assign public IP: Disable.

Part D: a NACL deny rule

1. VPC > Network ACLs, select the NACL associated with web-a (the default one). It has rule 100 allowing all traffic, and * denying.
2. Inbound rules > Edit inbound rules > Add new rule: Rule number 10, Type HTTP (80), Source 3.3.3.3/32, Deny. Save changes.
3. Rule 10 is smaller than 100, so it is checked first.

More on NACL rules: Network ACL: inbound and outbound rules.

17. When something goes wrong

1. The page loads nothing after you created your own NACL: a new NACL denies everything. Add inbound 80/443 and outbound 1024-65535.
2. sudo yum install hangs on the web server with a custom NACL: the replies come back to ephemeral ports. Allow inbound 1024-65535.
3. The blocked IP still gets in: its deny rule has a bigger number than an allow rule that matches first.
4. .php pages give 502 Bad Gateway: the app server is not answering on port 80. Check its Nginx and php-fpm, and that app-sg allows 80 from web-sg.
5. PHP can't connect to the database: check the private IP in $servername, bind-address, the user 'appuser'@'10.0.16.%', and that db-sg allows 3306 from app-sg.
6. nginx -t fails: a missing ; or } in the location block.

18. Puzzle: PHP on a private server

The web server was easy:

1. SSH from the laptop to its public IP.
2. sudo yum install nginx -y
3. sudo service nginx start
4. Copy the HTML files with scp.

Now install PHP on the app server. Two things block you:

1. No public IP: you can't SSH to it from your laptop.
2. No route to the internet: even inside it, sudo yum install php -y can't download anything.

Think about it before you read on: how would you reach that server, and how would it download packages without becoming public? The answer, a bastion host and a NAT gateway, is the next chapter: How to Access a Private EC2 with a Bastion Host and NAT Gateway.

19. The whole class on one page

1. Default VPC: 172.31.0.0/16, a subnet in every AZ, IGW attached, public main route table. Custom VPC: empty and private until you build it.
2. Free: VPC, subnets, route tables, IGW, SGs, NACLs. Paid: data out after 100 GB/month, public IPv4, NAT gateways.
3. Three tiers: web in a public subnet, app and DB in private subnets on a local-only route table.
4. Request path: internet → IGW → route table → NACL (subnet) → SG (instance) → server.
5. SG: instance level, allow only, stateful. NACL: subnet level, allow and deny, stateless.
6. Replies go from the server's port (443) to the client's ephemeral port; NACLs need 1024-65535 allowed for replies.
7. Defaults: SG denies all in, allows all out; default NACL allows all; a new NACL denies all.
8. NACL: lowest rule number first, first match wins, * denies the rest. Put denies before allows, and number in steps.
9. Rule numbers 1-32766; 20 inbound + 20 outbound rules by default.
10. Public Nginx: location ~ \.php$ { proxy_pass http://<app private IP>; }, then sudo nginx -t and reload.
11. PHP's $servername becomes the DB's private IP; the DB must listen on the network and have a user for 10.0.16.%; SGs chained web → app → DB.

20. Try at home

Recap

Quick revision cards

Revise this chapter in two minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens its lesson.

More cards: Ravi Sir's Cards: AWS VPC and Subnets.