AWS Security Components: Security Groups vs Network ACLs, WAF, Trusted Advisor

Every component in this task answers the same question — "how do I control what reaches my resources?" — but each answers it at a different layer. Network ACLs stand at the edge of a subnet and filter traffic entering or leaving that entire network segment. Security groups wrap an individual instance (technically its elastic network interface) and decide which connections may reach that specific resource. AWS WAF operates higher still, at layer 7 of the OSI model, reading the content of HTTP and HTTPS requests to spot malicious patterns that a port-based firewall can never see.

Keeping the layers straight is the fastest way to answer exam questions. A packet destined for an EC2 instance in a VPC crosses the network ACL at the subnet boundary first, then the security group at the instance. If the application sits behind CloudFront or an Application Load Balancer with AWS WAF attached, the request is inspected at that entry point before it ever travels toward the subnet.

Use this decision list when a question describes a threat and asks for the right control:

• Block or allow traffic to one instance by port, protocol, or source → security group.
• Block a specific IP range from an entire subnet, or add an explicit deny → network ACL.
• Stop SQL injection, cross-site scripting, or other malicious web requests → AWS WAF.
• Need a capability AWS does not provide natively (for example, a specific vendor's firewall) → AWS Marketplace.
• Find out whether your account already has risky settings → AWS Trusted Advisor.

The rest of this lesson works through each layer in exam-level depth.

A security group is a virtual firewall that controls inbound and outbound traffic for the resources it is attached to — EC2 instances, RDS databases, load balancers, and other resources with an elastic network interface. It operates at the instance (ENI) level, not the subnet level, so two instances in the same subnet can have completely different security groups and therefore completely different exposure.

Security groups are stateful. If you allow inbound traffic on port 443, the response traffic for that connection is automatically allowed back out — you never write a rule for return traffic. The same applies in reverse: if an instance initiates an outbound request, the reply is allowed in regardless of inbound rules. Statefulness is the number-one fact the exam checks, usually by contrasting it with the stateless behavior of network ACLs.

Security groups support allow rules only. There is no deny rule; anything not explicitly allowed is implicitly denied. Because there are no denies, there is no rule ordering to resolve — AWS evaluates all rules before deciding whether to permit traffic. A new security group starts with no inbound rules (all inbound traffic implicitly denied) and an outbound rule allowing all traffic, which you can tighten.

Two practical features are worth knowing at a foundational level. First, a rule's source can be another security group, not just an IP range — for example, "allow port 3306 only from the web-tier security group," which keeps working even as instances change addresses. Second, rule changes take effect immediately on every attached resource, making security groups the day-to-day tool for controlling instance access.

A network access control list (network ACL, or NACL) is an optional layer of security that filters traffic at the subnet boundary. Every subnet in a VPC is associated with exactly one network ACL, and that ACL applies to all traffic entering or leaving the subnet — every instance inside inherits it automatically, whether or not its security group would have allowed the traffic.

Network ACLs are stateless: they do not track connections. If you allow inbound HTTPS on port 443, the response leaving the subnet is a separate event that must match an explicit outbound rule — typically one covering the ephemeral port range that clients use for return traffic. Forgetting the return-path rule is the classic real-world NACL mistake, and "stateless — return traffic must be explicitly allowed" is the exact phrase to anchor for the exam.

Unlike security groups, network ACLs support both allow and deny rules. This makes the NACL the only VPC-native way to explicitly block traffic — for example, denying a known-malicious IP range before it reaches anything in the subnet. Rules are numbered, and AWS evaluates them in ascending number order, applying the first rule that matches and ignoring the rest. Every NACL ends with an unnumbered rule that denies anything no other rule matched.

Defaults matter on the exam: the default network ACL that comes with your VPC allows all inbound and outbound traffic, so subnets are open at the NACL layer until you change it. A custom network ACL you create starts the opposite way — it denies everything until you add allow rules. Think of NACLs as a coarse subnet-wide guardrail and security groups as the fine-grained per-instance control.

This table is one of the highest-yield pieces of content on the entire CLF-C02 exam. Questions quote one row and ask you to identify which component it describes, or present a scenario whose answer hinges on a single row.

A few reasoning shortcuts follow directly from the table. If a question mentions blocking a specific IP address or range, the answer is the network ACL, because security groups cannot deny. If a question mentions return traffic being allowed "automatically," it is describing a security group. If a rule change must affect every instance in a subnet at once, that is the NACL; if it should affect only one instance, that is the security group.

Remember that the two are complementary, not alternatives. Defense in depth means traffic must pass both: the NACL at the subnet edge and the security group at the instance. A permissive default NACL with tight security groups is the common baseline; adding NACL deny rules hardens the subnet further.

AWS WAF is a web application firewall. Where security groups and network ACLs make decisions from network-level facts — IP addresses, ports, protocols — AWS WAF inspects the content of HTTP and HTTPS requests: URIs, query strings, headers, cookies, and body. That layer-7 visibility is what lets it catch application attacks such as SQL injection (malicious database commands smuggled inside request parameters) and cross-site scripting (XSS) (malicious scripts injected into pages served to other users). A port-based firewall must allow port 443 for a public website, so these attacks sail straight through it; only a layer-7 inspector can tell a legitimate request from a hostile one on the same port.

You configure AWS WAF by creating a web ACL — a collection of rules that allow, block, or count matching requests. Rules can match attack signatures, rate-limit aggressive clients, filter by originating IP or country, and more. AWS and Marketplace sellers publish managed rule groups — pre-built, maintained rule sets for common threats — so you get protection without writing rules from scratch.

A web ACL attaches to the resources that terminate web traffic: Amazon CloudFront distributions, Application Load Balancers, and Amazon API Gateway APIs are the three to memorize, and AWS WAF also supports services such as AWS AppSync and Amazon Cognito user pools. Attaching WAF to CloudFront blocks bad requests at AWS edge locations, before they reach your infrastructure at all.

Keep the boundary with sibling topics clear: AWS WAF filters malicious request content; AWS Shield, covered under protection services elsewhere in this domain, addresses DDoS floods. On the exam, "SQL injection" or "cross-site scripting" in the question stem points to AWS WAF, full stop.

AWS's native tools do not cover every security need, and the exam wants you to know where to turn when they do not: AWS Marketplace, the curated digital catalog where independent software vendors list products that run on or integrate with AWS. Its security category includes thousands of offerings from established security companies as well as specialized vendors.

Typical categories you might see named in an exam option include next-generation firewalls and network security appliances (often delivered as Amazon Machine Images you launch into your VPC), endpoint protection and anti-malware agents for your instances, SIEM and log-analysis platforms, vulnerability scanners, and governance and compliance tools. Many WAF vendors also publish managed rule groups for AWS WAF through the Marketplace, layering third-party threat intelligence onto the native service.

The commercial model is part of the exam-relevant story. Marketplace products can be offered with free trials, pay-as-you-go (hourly or usage-based) pricing, annual subscriptions, or bring-your-own-license (BYOL) terms, and charges appear on your regular AWS bill — no separate vendor procurement cycle. Deployment is similarly streamlined: many products launch in minutes from a pre-configured image or SaaS listing.

For CLF-C02 you do not need vendor names or configuration detail. You need one recognition-level fact: when a question says an organization wants to use a third-party security product — its existing firewall vendor in the cloud, a commercial SIEM, an endpoint agent — the answer that sources and licenses it is AWS Marketplace.

Task 2.4 explicitly tests whether you know where AWS publishes security information, and the exam names the sources directly. Learn what each one is for, because questions describe a need — "a quick answer to a common question," "announcements of new security features" — and ask which resource fits.

The AWS Knowledge Center is a library of answers to the questions customers most frequently ask AWS Support, written in a question-and-answer format and now hosted on AWS re:Post, AWS's community Q&A site. When you need a short, practical answer — "how do I make my S3 bucket private?" — the Knowledge Center is the fit. It covers all of AWS, with a substantial security-focused section.

The AWS Security Blog is where AWS announces new security features and services, publishes deep-dive walkthroughs, and shares best-practice guidance from AWS security engineers. If a question describes staying current with security announcements or reading detailed how-to articles, the Security Blog is the answer.

What the exam guide calls the AWS Security Center corresponds to AWS's central security resource pages — the AWS Cloud Security site and its documentation hub. This is the umbrella destination for security whitepapers, best-practice guides, compliance information, and security bulletins, AWS's published advisories about vulnerabilities that may affect AWS services or customer workloads. Each individual service also has security-specific chapters in its own documentation.

Finally, know at a sentence's depth that AWS provides channels to report abuse — if you observe AWS resources being used for attacks, spam, or malware, you can report it to the AWS Trust & Safety team via the abuse reporting form.

The final skill in this task is using AWS services to identify security issues, and the named example is AWS Trusted Advisor. Trusted Advisor continuously inspects your account and compares your configuration against AWS best practices, producing checks across several categories: cost optimization, performance, security, fault tolerance, service limits, and operational excellence. For this task, the security category is the star.

Security checks flag concrete, high-risk misconfigurations. The classics to remember: security groups with unrestricted access (rules open to 0.0.0.0/0 on risky ports), Amazon S3 buckets with open access permissions, MFA not enabled on the root account, IAM use (encouraging you to work through IAM identities rather than root), and publicly accessible EBS or RDS snapshots. Each finding is color-coded — green for no problem, yellow for investigation recommended, red for action recommended — so you triage at a glance.

The tiering rule is a reliable exam target: a core set of checks, including key security checks, is free for every AWS account, while the full set of checks unlocks with Business, Enterprise On-Ramp, or Enterprise Support plans. Note the framing that distinguishes it from sibling topics: Trusted Advisor is a best-practice configuration checker across cost, performance, and security alike — it is not a threat-detection or vulnerability-scanning service (those belong to other task statements).

Now assemble the whole toolkit around one scenario. You run a public web application: an ALB in front of EC2 instances, with a database tier behind them. You attach AWS WAF to the ALB (or a CloudFront distribution in front of it) to block SQL injection and XSS at the edge. Security groups allow only the ALB to reach the web instances on port 443, and only the web tier's security group to reach the database on its port. A network ACL on the database subnet adds a stateless guardrail and denies a hostile IP range outright. Your team's preferred IDS appliance comes from AWS Marketplace. Trusted Advisor then confirms nothing was left open, and the Security Blog and Knowledge Center keep the team current. Five components, five layers, one defense-in-depth story — exactly how the exam expects you to connect them.