Security groups vs NACLs decision in AWS - CLI Comparison

Introduction

When you want to control who can talk to your cloud servers, you use security groups and network ACLs. They both protect your network but work in different ways and places.

When you want to control traffic to and from individual cloud servers (instances).

When you need to set rules that apply to all servers in a subnet.

When you want to allow only certain IP addresses to access your web app.

When you want to block specific IP addresses from reaching your network.

When you want to add an extra layer of protection by combining both controls.

Commands

This command shows the rules of the security group named 'my-app-sg' to understand what traffic is allowed.

Terminal

aws ec2 describe-security-groups --group-names my-app-sg

Expected Output

{

    "SecurityGroups": [

        {

            "GroupName": "my-app-sg",

            "GroupId": "sg-0abc1234def567890",

            "IpPermissions": [

                {

                    "IpProtocol": "tcp",

                    "FromPort": 80,

                    "ToPort": 80,

                    "IpRanges": [

                        {

                            "CidrIp": "0.0.0.0/0"

                        }

                    ]

                }

            ],

            "IpPermissionsEgress": [

                {

                    "IpProtocol": "-1",

                    "IpRanges": [

                        {

                            "CidrIp": "0.0.0.0/0"

                        }

                    ]

                }

            ]

        }

    ]

}

→

--group-names - Specify the name of the security group to describe

This command shows the rules of the network ACL named 'my-app-nacl' to see what traffic is allowed or denied at the subnet level.

Terminal

aws ec2 describe-network-acls --filters Name=tag:Name,Values=my-app-nacl

Expected Output

{

    "NetworkAcls": [

        {

            "NetworkAclId": "acl-0abc1234def567890",

            "Entries": [

                {

                    "RuleNumber": 100,

                    "Protocol": "6",

                    "RuleAction": "allow",

                    "Egress": false,

                    "CidrBlock": "0.0.0.0/0",

                    "PortRange": {

                        "From": 80,

                        "To": 80

                    }

                },

                {

                    "RuleNumber": 110,

                    "Protocol": "-1",

                    "RuleAction": "deny",

                    "Egress": false,

                    "CidrBlock": "192.168.1.0/24"

                }

            ]

        }

    ]

}

→

--filters - Filter network ACLs by tag name

This command adds a rule to the security group to allow SSH access only from the IP range 203.0.113.0/24.

Terminal

aws ec2 authorize-security-group-ingress --group-id sg-0abc1234def567890 --protocol tcp --port 22 --cidr 203.0.113.0/24

Expected Output

No output (command runs silently)

→

--group-id - Specify the security group ID to update

→

--protocol - Specify the protocol for the rule

→

--port - Specify the port number to allow

→

--cidr - Specify the IP range allowed

This command adds a rule to the network ACL to deny inbound SSH traffic from all IP addresses, blocking it at the subnet level.

Terminal

aws ec2 create-network-acl-entry --network-acl-id acl-0abc1234def567890 --rule-number 120 --protocol 6 --port-range From=22,To=22 --egress false --rule-action deny --cidr-block 0.0.0.0/0

Expected Output

No output (command runs silently)

→

--network-acl-id - Specify the network ACL ID to update

→

--rule-number - Set the priority of the rule

→

--protocol - Specify the protocol (6 means TCP)

→

--port-range - Specify the port range for the rule

→

--egress - Set to false for inbound rules

→

--rule-action - Set to deny to block traffic

→

--cidr-block - Specify the IP range to block

Key Concept

If you remember nothing else from this pattern, remember: security groups control traffic at the server level and allow only what you permit, while network ACLs control traffic at the subnet level and can explicitly allow or deny traffic.

Common Mistakes

Trying to allow traffic in a network ACL without allowing it in the security group.

Security groups are stateful and must allow the traffic for it to reach the server, so network ACLs alone are not enough.

Always configure security groups to allow desired traffic in addition to network ACL rules.

Using the same rule number for multiple network ACL entries.

Rule numbers must be unique to avoid conflicts and unexpected behavior.

Assign unique rule numbers for each network ACL entry.

Assuming network ACLs are stateful like security groups.

Network ACLs are stateless, so you must create separate rules for inbound and outbound traffic.

Create matching inbound and outbound rules in network ACLs to allow return traffic.

Summary

Use 'aws ec2 describe-security-groups' to check server-level traffic rules.

Use 'aws ec2 describe-network-acls' to check subnet-level traffic rules.

Add or update rules with 'authorize-security-group-ingress' for security groups and 'create-network-acl-entry' for network ACLs.

Remember security groups are stateful and network ACLs are stateless with unique rule numbers.