> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Security Groups and NACLs > Explains AWS Security Groups versus Network ACLs, covering stateful versus stateless firewall behavior, rule processing, scope, configuration differences, and practical VPC usage. This article explains how AWS Security Groups and Network Access Control Lists (NACLs) act as firewalls inside a VPC. First we cover general firewall concepts — inbound vs outbound rules, and the difference between stateless and stateful behavior — then map those concepts to NACLs and security groups in AWS. ## Firewall fundamentals A firewall inspects network traffic and permits only traffic that matches a set of rules. Rules are categorized as: * Inbound (ingress): controls traffic entering a resource. * Outbound (egress): controls traffic leaving a resource. Two common firewall behaviors: * Stateless: evaluates each packet independently; the firewall does not track connection state. * Stateful: tracks connection state (for example, TCP sessions) and implicitly allows return traffic for an established connection. Example scenario — HTTPS web server: * Client sends a request to the server with destination port 443. * Server replies from source port 443 to the client's ephemeral source port (typically in the range 1024–65535). Stateless firewall behavior: * You must explicitly allow the inbound request (destination port 443) and also allow the outbound response (destination ephemeral port range). * If the server initiates an outbound connection (for example, to an update server on port 80), you need rules allowing outbound port 80 and inbound ephemeral ports for the response. * Key point: the firewall does not infer that a response should be allowed just because the request was allowed. Stateful firewall behavior: * Allowing inbound HTTPS (port 443) causes the firewall to track the TCP session and automatically permit the outbound response to the client’s ephemeral port. * If the server initiates an outbound connection on port 80, only an outbound rule for port 80 is required; the corresponding inbound response is implicitly allowed. A colorful infographic explaining stateful firewalls, showing inbound port 443 allowed and outbound ephemeral ports 1024–65535 allowed, with arrows through a firewall icon to a server. Speech bubbles note the firewall recognizes responses and the server is listening on port 443. ## How this maps to AWS AWS exposes two complementary firewall mechanisms within a VPC: * Network Access Control Lists (NACLs): operate at the subnet level and are stateless. * Security Groups: act at the resource level (ENIs, EC2, RDS, LBs) and are stateful. Below we describe each service and practical configuration notes. ### Network Access Control Lists (NACLs) Key characteristics: * NACLs filter traffic entering and leaving a subnet in a VPC. * Each subnet is associated with exactly one network ACL at a time, but a NACL can be associated with multiple subnets. * NACLs are stateless — you must explicitly configure both inbound and outbound rules for each flow. * NACLs do not evaluate traffic between instances within the same subnet. An infographic showing Network Access Control Lists (NACLs) in a Virtual Private Cloud with public and private subnets. It illustrates inbound/outbound arrows and notes that NACLs are stateless and filter traffic entering and leaving a subnet but not traffic within a subnet. NACL rules are processed in ascending numeric order; the first matching rule is applied. Unlike security groups, NACL rules can explicitly `Allow` or `Deny` traffic. ### Security Groups Key characteristics: * Security groups act as virtual firewalls for individual resources (EC2 instances, ENIs, load balancers, RDS instances, etc.). * Security groups are stateful: return traffic for an allowed request is automatically permitted. * Security group rules are allow-only — there is no explicit deny rule. All traffic not explicitly allowed is implicitly denied. A slide titled "Security Groups" showing a VPC diagram with public and private subnets where security groups (firewall icons) control access to resources (chip icons) in the 172.16.0.0/24 network. The text explains security groups act as firewalls for individual resources (EC2, LB, RDS) and are stateful so only the request needs to be allowed. ## Configuring Security Group rules (AWS Console) Security groups show separate Inbound and Outbound sections; the rule fields look identical for both directions. Common rule fields: * Name / description (optional) — human-friendly label. * Rule ID (internal) — unique identifier. * IP version — IPv4 or IPv6. * Type / Protocol / Port range — e.g., HTTP → TCP port 80, HTTPS → TCP port 443, or a custom rule. * Source (inbound) or Destination (outbound) — a CIDR range like `0.0.0.0/0` or a single IP like `1.1.1.1/32`. Example: inbound rules that allow HTTP (TCP port 80) from everywhere and a custom TCP port 200 from a specific IP. Screenshot of an "Inbound Rules" panel (likely an AWS security group) showing two entries. One rule allows HTTP (TCP port 80) from 0.0.0.0/0 and a highlighted custom TCP rule allows port 200 from 1.1.1.1/32. By default, a new security group includes an outbound rule that allows all outbound traffic (`0.0.0.0/0`). You can remove or tighten that rule depending on your security posture. A screenshot of an "Outbound Rules" page in a cloud console showing a single security group outbound rule. The rule allows all IPv4 traffic (all protocols/ports) to destination 0.0.0.0/0, with a blue arrow pointing at the destination. Security groups use allow-only rules; unspecified traffic is implicitly denied. Newly created security groups include a default outbound rule that allows all outbound traffic — remove or restrict it if you need tighter egress controls. ## NACL rule differences * Rules are numbered and processed in ascending order; the first matching rule applies. * NACLs can explicitly `Allow` or `Deny` traffic. * Being stateless, NACLs require explicit, matching entries for both directions of a connection. A screenshot of a "NACL Rules" inbound rules table showing rule numbers, types (HTTP, SSH, All traffic), protocols, port ranges, source CIDR blocks and Allow/Deny status. The list includes rules for ports 80 and 22 with various sources and allow/deny icons. ## Multiple security groups and effective ruleset * You can attach multiple security groups to a resource (for example, an EC2 instance). * The effective ruleset is the union of all rules from attached security groups. If any attached group permits a flow, it is allowed (subject to NACLs and routing). A presentation slide titled "Multiple Security Groups" explaining that you can assign multiple security groups to a single instance. It shows an instance with "web" and "mgmt" groups and a table of merged port/IP rules (e.g., ports 80, 443, 3389, 22 with their IP ranges). ## Default behaviors, associations, and exceptions * By default, security groups allow all outbound traffic until you change the outbound rules. * Every subnet in a VPC must be associated with a network ACL. * A network ACL can be associated with multiple subnets, but each subnet can only be associated with one NACL at a time. NACLs do not filter certain AWS-managed traffic that is required for core VPC functionality. Examples include: * Amazon DNS * DHCP traffic * EC2 instance metadata and ECS task metadata endpoints * Windows license activation * Amazon Time Sync Service * Reserved VPC router IP addresses A presentation slide titled "Network ACLs do not filter traffic destined to and from the following:" showing seven colorful rounded boxes listing services: Amazon DNS, DHCP, EC2 instance metadata, ECS task metadata endpoints, Windows license activation, Amazon Time Sync Service, and reserved VPC router IP addresses. Because NACLs are stateless and can explicitly deny traffic, be careful when adding deny rules: rule order matters. If you add a deny that blocks legitimate return traffic, you must also add matching allow rules for the reverse flow. ## Quick comparison tables | Feature | Network ACL (NACL) | Security Group | | - | - | - | | Scope | Subnet-level | Resource-level (ENI, EC2, LB, RDS) | | Stateful? | No (stateless) | Yes (stateful) | | Rule action | Allow or Deny | Allow only (implicit deny) | | Rule processing | Numbered, earliest match applies | All rules evaluated; effective is union of allows | | Default behavior | Custom NACLs may be restrictive | Default outbound allow for new SGs | | Use case | Network-level filtering, cross-subnet policies | Host/resource-level security controls | | Concept | Practical implication | | - | - | | Stateless | Must configure matching ingress + egress rules for return traffic | | Stateful | Allowing one side of the flow permits return traffic automatically | | Multiple SGs | The union of attached SG rules becomes the effective allowlist | ## Summary * Stateless firewalls (like NACLs) evaluate each packet independently and require explicit ingress and egress rules for a complete flow. * Stateful firewalls (like Security Groups) track connections and automatically allow return traffic for established sessions. * NACLs filter traffic at the subnet boundary, are stateless, and can explicitly allow or deny traffic (rule-number order matters). * Security Groups are stateful, attached to resources, and only contain allow rules; multiple security groups combine their rules into an effective allowlist. * Every subnet must be associated with a network ACL; a NACL can cover multiple subnets, but a subnet can only have one NACL association. A presentation slide titled "Summary" with a turquoise left panel and four colored numbered bullets on the right. The bullets summarize firewall concepts: stateless firewalls need explicit inbound/outbound rules, stateful firewalls track requests to allow responses, and network ACLs filter subnet traffic (they are stateless). * Security groups act as stateful firewalls for resources, only allow traffic (no deny), and multiple security groups' rules are merged to form the effective allowlist. A presentation slide titled "Summary" with a teal gradient panel on the left and numbered colorful icons down the right. The right side lists points about security groups — they act as stateful firewalls for resources, only "allow" traffic (NACLs can "allow" or "deny"), and multiple security groups' rules are merged. * Remember: every subnet in a VPC must be associated with a network ACL; an ACL can be used by multiple subnets, but a subnet may be associated with only one ACL at a time. A presentation slide with a turquoise left panel labeled "Summary" and two numbered points on the right stating VPC network ACL rules: every subnet must be associated with a network ACL, and while an ACL can cover multiple subnets, a subnet can be associated with only one ACL at a time. ## Links and references * AWS Security Groups — [https://docs.aws.amazon.com/vpc/latest/userguide/VPC\_SecurityGroups.html](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) * AWS Network ACLs — [https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) * TCP/IP ephemeral port ranges — (varies by OS; commonly 1024–65535) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.