This chapter dives deep into the three fundamental security mechanisms for VPCs: Security Groups, Network ACLs (NACLs), and VPC Flow Logs. These are core to AWS networking security and appear in roughly 15–20% of SAA-C03 exam questions, often in scenarios involving traffic filtering, troubleshooting, or compliance. You will learn exactly how each works at the packet level, their key differences, and how to combine them effectively. Mastery of this topic is essential for designing secure, well-architected AWS solutions.
Jump to a section
Imagine a medieval castle with multiple layers of security. The castle itself has a massive outer wall with a single gate (the VPC). Inside, there are several buildings, each with its own door (EC2 instances). The castle employs two types of security: roving guards who check every person entering a building (Security Groups) and a stationary gatekeeper at the outer wall who checks everyone coming in or out (Network ACL). The roving guards are stateful: if they let a messenger in, they remember that messenger and allow him to leave without re-checking. The gatekeeper is stateless: he checks every single person both entering and leaving, without remembering any previous passes. Additionally, the castle keeps a detailed log (VPC Flow Logs) of every person who passes through the outer gate, recording their name, time, and direction, which is used for auditing and troubleshooting security incidents. If the gatekeeper denies entry, the log still records the attempt. The roving guards do not generate logs; they just silently block or allow.
What Are Security Groups?
Security Groups (SGs) are virtual, stateful firewalls that control inbound and outbound traffic at the instance level (ENI level, to be precise). They act as a virtual firewall for one or more instances. Each VPC can have up to 2,500 security groups (default 500, adjustable). Each security group can have up to 60 inbound and 60 outbound rules (default 50 each, adjustable). Security groups are stateful: if you allow inbound traffic on port 80, the outbound return traffic is automatically allowed, regardless of outbound rules. This is a critical exam point.
How Security Groups Work Internally
When a packet arrives at an instance's ENI, the security group rules are evaluated. The rules are evaluated in order but are effectively ANDed: all rules that match are considered, but the default is deny all. If any rule permits the traffic, it is allowed; if no rule permits, it is denied. Because SGs are stateful, they track connection state. For TCP, they maintain a connection tracking table that records the 5-tuple (source IP, source port, destination IP, destination port, protocol). When a response packet arrives with the reverse 5-tuple, it is automatically allowed if the original outbound packet was allowed. This tracking has a timeout: for established TCP connections, the timeout is 5 minutes (configurable via the tcp_established_timeout parameter in the connection tracking system, but not directly through SG settings). For UDP, the timeout is 30 seconds. For ICMP, the timeout is 10 seconds. If no traffic is seen within the timeout, the entry is removed, and subsequent packets must be explicitly allowed.
Default Security Group Rules
Each VPC comes with a default security group. Initially, it allows inbound traffic only from other instances within the same security group and allows all outbound traffic. You can modify these rules. When you create a new security group, it has no inbound rules (deny all inbound) and one outbound rule allowing all outbound traffic (0.0.0.0/0, all ports). This is a common exam detail: the default outbound allow all.
Security Group Rule Evaluation
Rules are evaluated based on the protocol, port range, and source/destination CIDR or security group ID. You can reference another security group as a source (for inbound) or destination (for outbound). This is powerful for multi-tier architectures. For example, you can allow inbound traffic only from a specific security group used by web servers. The exam often tests that security group rules do not support explicit deny; you can only allow. To deny, you must remove the allow rule. Also, security group rules are evaluated as a whole: if multiple rules match, the most permissive applies (since there is no deny, it's simply allowed).
Network ACLs (NACLs)
NACLs are stateless, subnet-level firewalls. Each subnet in a VPC must be associated with exactly one NACL (the default NACL if not specified). NACLs are numbered from 1 to 32766, and rules are evaluated in ascending order. The first rule that matches the traffic (either allow or deny) is applied; subsequent rules are ignored. This is a key difference from SGs: NACLs support explicit deny and are evaluated in order.
How NACLs Work Internally
When a packet enters or leaves a subnet, the NACL associated with that subnet processes it. Because NACLs are stateless, both inbound and outbound rules are evaluated independently. For example, if you allow inbound HTTP (port 80) from the internet, you must also allow outbound ephemeral ports (1024-65535) to the internet for the return traffic. This is a classic exam trap: candidates forget that stateless firewalls require explicit outbound rules for return traffic. NACLs have separate inbound and outbound rule sets, each with a default deny rule (rule number *). The default NACL allows all inbound and outbound traffic (rules 100 allow all). Custom NACLs start with no rules, effectively denying all traffic until you add allow rules.
NACL Rule Numbers and Evaluation
Rules are numbered. AWS recommends using increments of 10 or 100 to allow insertion of rules later. The rule number determines the order: lower numbers are evaluated first. For example, if you have a rule 100 to allow HTTP and a rule 200 to deny all, HTTP is allowed because rule 100 matches first. If you reverse the order (rule 100 deny all, rule 200 allow HTTP), all traffic is denied. This is a common exam scenario: you must ensure that allow rules come before deny rules if you want to allow specific traffic while denying other.
Default NACL vs Custom NACL
The default NACL has an inbound rule (100) that allows all IPv4 traffic (0.0.0.0/0) and an outbound rule (100) that allows all IPv4 traffic. It also has a rule * that denies all traffic, but since rule 100 matches first, it effectively allows everything. Custom NACLs have no rules initially, so they deny all traffic until you add allow rules. The exam often tests that you cannot delete the default NACL, but you can modify it.
VPC Flow Logs
VPC Flow Logs capture information about IP traffic going to and from network interfaces in a VPC. They are stored in Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose. Flow logs can be created at three levels: VPC, subnet, or network interface. Each flow log record captures a specific network flow, which is a set of packets with the same 5-tuple within a capture window (typically 10-15 minutes, but can be aggregated). The default capture window is 10 minutes, but you can set it to 1 minute or 10 minutes. Flow logs do not capture all traffic: they do not capture traffic to Amazon DNS servers, Amazon Windows license activation, Amazon Time Sync Service, DHCP traffic, and traffic to the instance metadata service (169.254.169.254). Also, traffic from 0.0.0.0/0 to the instance metadata service is not logged.
Flow Log Record Format
Each flow log record includes fields like version, account ID, interface ID, source address, destination address, source port, destination port, protocol, packets, bytes, start time, end time, action (ACCEPT or REJECT), and log status. The action field indicates whether the traffic was accepted or rejected by the security group or NACL. This is crucial for troubleshooting: if traffic is rejected, you can see which rule denied it (though not the exact rule number). The log status indicates whether the log data was published successfully.
Interaction Between Security Groups and NACLs
When traffic reaches an instance, it must pass both the NACL (at the subnet boundary) and the security group (at the instance ENI). The NACL is evaluated first for inbound traffic (since it's at the subnet level), then the security group. For outbound traffic, the security group is evaluated first, then the NACL. This layered approach provides defense in depth. A common exam scenario: if an instance cannot connect to the internet, check both the NACL (subnet outbound) and security group (instance outbound).
Key Differences Between SGs and NACLs
State: SG stateful, NACL stateless.
Scope: SG at instance/ENI level, NACL at subnet level.
Evaluation: SG all rules evaluated (no deny), NACL first match (allow or deny).
Defaults: SG default deny inbound, allow all outbound; default NACL allow all; custom NACL deny all.
Rules: SG supports allow rules only; NACL supports allow and deny.
Order: SG no order (all rules considered), NACL ordered by rule number.
Return traffic: SG automatically allowed, NACL must be explicitly allowed.
Best Practices
Use security groups for per-instance stateful filtering.
Use NACLs for subnet-level stateless filtering, e.g., to block specific IP ranges or provide a second layer of defense.
Use flow logs for auditing and troubleshooting.
When troubleshooting connectivity issues, check flow logs first to see if traffic is accepted or rejected, then check SG and NACL rules.
For web servers, allow inbound HTTP/HTTPS in SG and outbound ephemeral ports in NACL.
Exam Tips
Remember that security groups are stateful: no need to add outbound rules for return traffic.
NACLs are stateless: must add outbound rules for return traffic.
The default security group allows inbound from itself and all outbound.
The default NACL allows all inbound and outbound.
Custom NACLs deny all until rules are added.
Flow logs do not capture traffic to Amazon DNS, DHCP, metadata, etc.
Flow logs can be created for VPC, subnet, or ENI.
Flow logs can be published to CloudWatch Logs, S3, or Kinesis Data Firehose.
Flow logs capture both accepted and rejected traffic.
You cannot enable flow logs for VPCs that are peered with another VPC unless the peer VPC is in the same account and region.
Flow logs do not capture traffic generated by AWS services like ELB, RDS, etc., when the traffic is to the service itself (e.g., health checks).
Create a Security Group
First, define the security group in the VPC console or via CLI (aws ec2 create-security-group). Specify the group name, description, and VPC ID. The security group starts with no inbound rules (deny all) and one outbound rule allowing all traffic. You then add inbound rules specifying protocol, port range, and source (CIDR or another security group). For example, to allow SSH from a specific IP, add a rule for TCP port 22 with source 203.0.113.0/24. You can also reference another security group as source, which allows instances with that SG to communicate. This step is crucial for tiered architectures.
Associate Security Group with Instance
When launching an EC2 instance, you can specify one or more security groups. You can also change the security groups of a running instance via the console (Networking > Change Security Groups) or CLI (aws ec2 modify-instance-attribute). The security group is applied to the primary ENI. If you have multiple ENIs, each can have its own security groups. The association is immediate, and the new rules take effect within seconds. For an existing instance, changing the security group does not require a reboot. This step is often tested: you can change security groups on the fly.
Traffic Evaluation at Security Group
When a packet arrives at the ENI, the security group rules are evaluated. For inbound traffic, the source must match a rule; for outbound, the destination must match. Because SGs are stateful, if the packet is part of an existing connection (tracked in the connection table), it is automatically allowed. Otherwise, it is checked against inbound rules. If allowed, the connection is tracked. If denied, the packet is dropped and no ICMP unreachable is sent (by default). The evaluation is fast, as rules are cached in the hypervisor. The connection table has a timeout (5 min for TCP, 30 sec for UDP, 10 sec for ICMP). After timeout, the entry is removed.
Create and Associate a NACL
Create a custom NACL via the console or CLI (aws ec2 create-network-acl). Initially, it has no rules (deny all). Add inbound and outbound rules with rule numbers, protocols, port ranges, and CIDRs. For example, to allow HTTP inbound, add rule 100 with type HTTP (TCP 80) and source 0.0.0.0/0. For outbound, you must add rule 100 to allow ephemeral ports (TCP 1024-65535) to destination 0.0.0.0/0 for return traffic. Then associate the NACL with a subnet (one NACL per subnet). The association can be changed at any time. The default NACL is already associated with all subnets until you replace it.
Traffic Evaluation at NACL
When traffic enters or leaves a subnet, the NACL processes it. For inbound traffic, the inbound rules are evaluated in ascending order. The first rule that matches the packet's source and destination ports/protocol is applied. If it's an allow rule, the packet is allowed; if deny, it is dropped. If no rule matches, the default deny (*) applies. The same process occurs for outbound traffic separately. Because NACLs are stateless, each direction is independent. This means you must ensure that both inbound and outbound rules allow the necessary traffic for communication. The evaluation is done at the subnet boundary, not at the instance.
Enable VPC Flow Logs
To enable flow logs, specify the resource (VPC, subnet, or ENI), the destination (CloudWatch Logs log group, S3 bucket, or Kinesis Data Firehose), and the IAM role (if using CloudWatch). You can also set the capture window (1 or 10 minutes). Once enabled, flow log records are published periodically. Each record includes fields like srcaddr, dstaddr, srcport, dstport, protocol, action (ACCEPT/REJECT). Use these logs to troubleshoot connectivity: if traffic is REJECTED, check NACL and SG rules. If ACCEPTED but no response, check routing or application. Flow logs do not capture all traffic (e.g., metadata, DNS). They are a passive monitoring tool, not a firewall.
Enterprise Scenario 1: Multi-Tier Web Application
A company runs a three-tier web application: web servers, application servers, and database servers, all in a VPC. The web servers need inbound HTTP/HTTPS from the internet. The application servers need inbound traffic only from the web servers. The database servers need inbound traffic only from the application servers on port 3306 (MySQL).
Configuration: Security groups are used for instance-level stateful filtering. The web server SG allows inbound HTTP/HTTPS from 0.0.0.0/0 and outbound to the application server SG on the application port. The application server SG allows inbound from the web server SG on the application port and outbound to the database SG on port 3306. The database SG allows inbound from the application server SG on port 3306. No outbound rules are needed for return traffic because SGs are stateful. NACLs are used at the subnet level for additional stateless filtering: the web subnet NACL allows inbound HTTP/HTTPS and outbound ephemeral ports; the app subnet NACL allows inbound from the web subnet CIDR and outbound ephemeral; the db subnet NACL allows inbound from the app subnet CIDR on port 3306 and outbound ephemeral.
Problems when misconfigured: If the web server SG allows inbound HTTP but the NACL does not allow outbound ephemeral ports, the web server can receive requests but cannot send responses. This is a classic mistake: forgetting that NACLs are stateless. Flow logs show the web server receiving ACCEPT packets but sending outbound packets that are REJECTED by the NACL.
Enterprise Scenario 2: Blocking a Specific IP Range
A company wants to block traffic from a specific geographic region (e.g., 10.0.0.0/8) at the subnet level for all instances in that subnet.
Configuration: A custom NACL is associated with the subnet. An inbound deny rule with a low rule number (e.g., 10) is added to block traffic from 10.0.0.0/8 for all ports. Then allow rules are added for legitimate traffic (e.g., rule 100 allow HTTP from 0.0.0.0/0). Because NACL rules are evaluated in order, the deny rule is evaluated first, so traffic from 10.0.0.0/8 is denied before it reaches the allow rule. Security groups are left permissive for allowed traffic. This approach is more efficient than adding deny rules to each security group.
Problems when misconfigured: If the deny rule is placed after the allow rule (e.g., rule 200), the allow rule matches first, and the deny is never evaluated. The traffic from the blocked IP is allowed. Flow logs show ACCEPT for the source IP, which is unexpected.
Scenario 3: Compliance Auditing
A financial services company must log all network traffic for compliance. They enable VPC Flow Logs at the VPC level and send them to an S3 bucket for long-term storage and analysis. They also use Athena to query the logs.
Configuration: Flow logs are enabled with a capture window of 10 minutes and published to S3. The logs are partitioned by date. An IAM role allows the flow logs service to write to S3. The company queries for all REJECT traffic to identify potential attacks.
Problems when misconfigured: If the flow log is created at the subnet level instead of VPC level, traffic between subnets within the same VPC is not captured (only traffic entering/exiting the subnet). Also, if the IAM role lacks permissions, flow logs fail silently. The exam tests that flow logs do not capture traffic to Amazon DNS (169.254.169.253) or metadata (169.254.169.254), so those are missing from logs.
SAA-C03 Exam Focus
This topic falls under Domain 1: Secure Architectures, Objective 1.1: Design secure access to AWS resources. Specifically, the exam tests your ability to choose between security groups and NACLs, configure them correctly, and use flow logs for troubleshooting. Expect 2-3 questions on this subtopic per exam.
Common Wrong Answers
"Security groups are stateless." Many candidates confuse SGs with NACLs. Remember: SGs are stateful; NACLs are stateless. If a question describes a scenario where return traffic is blocked, the answer likely involves a stateless firewall (NACL) that needs an outbound rule.
"NACLs allow all traffic by default." This is true only for the default NACL. Custom NACLs deny all traffic until rules are added. The exam often presents a custom NACL and asks why traffic is blocked.
"Flow logs capture all traffic." Flow logs do not capture traffic to Amazon DNS, DHCP, metadata, Windows license activation, or traffic generated by AWS services for health checks. Also, they do not capture traffic from 0.0.0.0/0 to the metadata service.
"You can change security groups only at launch." You can change security groups on running instances. The exam may test this by presenting a scenario where a security group needs to be updated after launch.
Specific Numbers and Terms
Default security group: allows inbound from itself, all outbound.
Default NACL: inbound and outbound rules 100 allow all, rule * deny all.
Security group rule limit: 60 inbound, 60 outbound (default, adjustable).
NACL rule limit: 20 rules per NACL (default, adjustable).
NACL rule numbers: 1-32766.
Flow log capture window: 1 or 10 minutes.
Flow log fields: version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status.
Connection tracking timeout: TCP established 5 min, UDP 30 sec, ICMP 10 sec.
Edge Cases
When using a security group as source, the rule applies to all instances associated with that security group, regardless of subnet. This is useful for tiered architectures.
If both a security group and a NACL allow traffic, the traffic is allowed. If either denies, traffic is denied.
You cannot delete the default NACL, but you can modify it.
Flow logs cannot be enabled for VPCs that are peered with a VPC in another account unless the peer is in the same account and region.
Flow logs do not capture traffic to the Amazon DNS server (169.254.169.253) or the Amazon Time Sync Service (169.254.169.123).
How to Eliminate Wrong Answers
If the question mentions "stateful firewall", the answer is security group.
If the question mentions "stateless firewall" or "explicit deny", the answer is NACL.
If the question involves troubleshooting connectivity and you need to see if traffic is allowed or denied, look for flow logs.
If the question says "default firewall", identify whether it's SG or NACL: default SG has no inbound allow except from itself; default NACL has allow all.
If the question mentions "subnet-level", it's NACL; if "instance-level", it's SG.
Security groups are stateful; NACLs are stateless.
Security groups have no explicit deny; NACLs support both allow and deny.
Default security group: inbound from itself only, all outbound.
Default NACL: allow all inbound and outbound.
Custom NACL: deny all until rules are added.
NACL rules are evaluated in ascending order; first match wins.
VPC Flow Logs capture metadata about accepted and rejected traffic.
Flow logs do not capture traffic to Amazon DNS, DHCP, metadata, or Time Sync.
Flow logs can be published to CloudWatch Logs, S3, or Kinesis Data Firehose.
You can change security groups on running instances.
You can associate a NACL with multiple subnets, but a subnet can have only one NACL.
Connection tracking timeout for TCP is 5 minutes; for UDP, 30 seconds; for ICMP, 10 seconds.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Stateful: return traffic automatically allowed.
Operates at the instance/ENI level.
Supports only allow rules; no explicit deny.
All rules are evaluated before a decision (most permissive applies).
Default: deny all inbound, allow all outbound.
Network ACL (NACL)
Stateless: return traffic must be explicitly allowed.
Operates at the subnet level.
Supports both allow and deny rules.
Rules are evaluated in order (lowest number first); first match applies.
Default for custom NACL: deny all inbound and outbound.
Mistake
Security groups are stateless and require explicit outbound rules for return traffic.
Correct
Security groups are stateful, meaning that if you allow inbound traffic, the outbound return traffic is automatically allowed regardless of outbound rules. Only NACLs are stateless and require explicit outbound rules for return traffic.
Mistake
The default security group allows all inbound traffic.
Correct
The default security group allows inbound traffic only from other instances within the same security group. It does not allow all inbound traffic. Outbound traffic is allowed to all destinations.
Mistake
Custom NACLs allow all traffic by default.
Correct
Custom NACLs have no rules initially, so they deny all traffic until you add allow rules. Only the default NACL (which is created automatically) has rules that allow all inbound and outbound traffic.
Mistake
VPC Flow Logs capture all network traffic, including traffic to the metadata service.
Correct
Flow logs do not capture traffic to the instance metadata service (169.254.169.254), Amazon DNS (169.254.169.253), DHCP traffic, Amazon Time Sync Service, and Windows license activation. They also do not capture traffic generated by AWS services for health checks.
Mistake
You cannot modify security groups after launching an instance.
Correct
You can modify the security groups associated with an instance at any time, even while the instance is running. Changes take effect immediately.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Check the NACL associated with the subnet. Even if the security group allows traffic, the NACL might deny it. Also, verify that the instance is in the correct subnet and that the security group is applied to the correct ENI. Use VPC Flow Logs to see if the traffic is being ACCEPTED or REJECTED at the subnet level.
Yes, you can assign up to 5 security groups to an ENI (default limit, adjustable). The rules from all security groups are aggregated. If any security group allows the traffic, it is allowed.
Security groups do not support deny rules. To block a specific IP, you must either not include an allow rule for that IP (i.e., ensure no rule allows it) or use a NACL with a deny rule at the subnet level. Alternatively, you can use a third-party firewall or AWS WAF.
VPC Flow Logs capture network traffic metadata (IP traffic) at the VPC/subnet/ENI level. CloudTrail captures API calls made to AWS services. Flow logs are for network troubleshooting and security analysis; CloudTrail is for auditing changes to AWS resources.
Yes, if you enable flow logs at the VPC or subnet level, traffic between instances within the same subnet is captured. If you enable at the ENI level, you must enable on both ENIs to see both directions.
You cannot delete a security group that is associated with any resource (e.g., EC2 instance, ENI). You must first disassociate it from all resources. Also, you cannot delete a security group that is referenced by a rule in another security group.
Check the NACL's outbound rules. NACLs are stateless, so even if the security group allows outbound, the NACL might deny it. Ensure the NACL has an outbound allow rule for the destination and port. Also, check the route table to ensure a route exists.
You've just covered VPC Security: Security Groups, NACLs, Flow Logs — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?