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

Each component in this task controls or checks what can reach your resources, and each works at a different layer. Network ACLs stand at the edge of a subnet and filter traffic entering or leaving that whole network segment. Security groups wrap an individual instance (technically its elastic network interface) and decide which connections may reach that specific resource. AWS WAF works higher still, at layer 7, reading the content of HTTP and HTTPS requests to spot malicious patterns that a port-based firewall can never see. AWS Shield protects against DDoS floods, AWS Network Firewall inspects traffic as it flows through a VPC, and AWS Firewall Manager manages these protections across many accounts.

Keeping the layers straight is the fastest way to reason about a scenario. 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.

Match the requirement to the control:

• 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.
• Withstand a distributed denial-of-service (DDoS) attack → AWS Shield.
• Inspect all VPC traffic with intrusion prevention or filter outbound traffic by domain name → AWS Network Firewall.
• Apply the same firewall rules to every account in an organization, including new ones → AWS Firewall Manager.
• 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.

Detecting active threats from account and network activity is a different job, done by Amazon GuardDuty, which is taught with the other monitoring and detection services in AWS security, governance and compliance.

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 main difference from network ACLs, which are stateless.

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 (so all inbound traffic is implicitly denied) and one 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, so a response is judged by the rules as a separate packet. This is where ephemeral ports matter. When a client opens a connection to a web server on port 443, the client picks a temporary source port from its own ephemeral range, and the server's response is addressed to that port. The response leaving the subnet therefore travels to a high-numbered port such as 50123, not to port 443. An outbound network ACL rule that allows only port 443 blocks every response; the outbound rule must allow the ephemeral port range instead. The range depends on the client's operating system (many Linux kernels use 32768–61000, Windows uses 49152–65535, and Elastic Load Balancing and NAT gateways use 1024–65535), so a rule covering 1024–65535 is common. The same logic applies in reverse: when an instance in the subnet calls out to the internet, the replies arrive on the instance's ephemeral ports and need an inbound rule. Security groups never need this, because they are stateful.

Unlike security groups, network ACLs support both allow and deny rules. This makes the NACL the 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, applies the first rule that matches, and ignores the rest. Every NACL ends with a rule numbered * that denies anything no numbered rule matched.

First-match order has a direct consequence: a deny rule only works if its number is lower than every allow rule that also matches the traffic. Take the outbound direction: if outbound rule 50 allows all traffic to 0.0.0.0/0 and outbound rule 120 denies traffic to 192.0.2.0/24, a packet leaving for 192.0.2.10 matches rule 50 first and is allowed, so rule 120 is never reached. Giving the deny a number below 50 (say 40) puts it ahead of the allow, and it takes effect. AWS recommends numbering rules in steps such as 10 or 100 so you can insert a rule between existing ones later.

Starting states differ, and they are easy to mix up:

• 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 all inbound and outbound traffic until you add allow rules.
• A new security group sits in between: it denies all inbound traffic (no inbound rules) but allows all outbound traffic.

Think of NACLs as a coarse subnet-wide guardrail and security groups as the fine-grained per-instance control.

Security groups and network ACLs differ on six attributes: level, state, rule types, evaluation, starting state, and coverage. Most questions on the two quote one of these attributes or build a scenario that turns on one of them.

A few reasoning shortcuts follow directly from the table. Blocking a specific IP address or range needs the network ACL, because security groups cannot deny. Return traffic allowed "automatically" describes 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 most common targets, 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 its neighbours clear: AWS WAF filters malicious request content, while AWS Shield (next section) absorbs DDoS floods. SQL injection and cross-site scripting are request-content attacks, so they need a layer-7 control, and AWS WAF is the AWS-native one.

These three services extend network protection beyond security groups, network ACLs and AWS WAF: AWS Shield protects against DDoS attacks, AWS Network Firewall inspects traffic flowing through a VPC, and AWS Firewall Manager applies firewall policies centrally across the accounts in an organization.

AWS Shield: DDoS protection

A distributed denial-of-service (DDoS) attack floods an application with traffic from many sources to make it unavailable. AWS Shield comes in two tiers:

• Shield Standard is automatic and comes at no extra cost for every AWS customer. It protects against the most common network- and transport-layer (layer 3 and 4) DDoS attacks, such as SYN floods and UDP reflection attacks. You do not turn it on.
• Shield Advanced is a paid subscription for resources such as Amazon CloudFront, Elastic Load Balancing, Amazon Route 53, AWS Global Accelerator and Elastic IP addresses. It adds protection against larger and more sophisticated attacks (including application-layer attacks, together with AWS WAF), near-real-time attack visibility, access to the Shield Response Team (SRT) during an attack, and cost protection: credits for scaling charges your resources run up because of a DDoS attack.

Shield and WAF solve different problems and often work together. Shield absorbs volume: floods of packets or requests meant to exhaust capacity. WAF judges the content of individual web requests. A single malicious SQL injection request is a WAF problem; millions of junk packets per second is a Shield problem. Putting CloudFront in front of an application gives it both at the edge.

AWS Firewall Manager: central policies for many accounts

AWS Firewall Manager is a security management service that lets a security team define firewall rules once and apply them across every account and resource in AWS Organizations. It does not filter traffic itself; it deploys and enforces the configuration of other services. Its policy types cover AWS WAF rules, Shield Advanced protections, security groups, network ACLs, AWS Network Firewall and Amazon Route 53 Resolver DNS Firewall.

The key benefit is automatic coverage: when a new account joins the organization or a new resource in scope is created, Firewall Manager applies the policy to it without anyone configuring it by hand, and it reports resources that are not compliant. Use it when the requirement is consistency across many accounts; use WAF, security groups or network ACLs directly when you are protecting resources in one account.

AWS Network Firewall: stateful inspection for a whole VPC

AWS Network Firewall is a managed, stateful network firewall and intrusion detection and prevention service for VPC traffic. It scales automatically and adds capabilities that security groups and network ACLs lack:

• Intrusion prevention with stateful rules in the open-source Suricata-compatible format, which can inspect traffic for known attack signatures and drop it.
• Domain-name filtering, for example allowing outbound traffic only to an approved list of domains.
• Both stateless and stateful rules, covering all protocols, not only HTTP(S).

You deploy it as firewall endpoints in dedicated firewall subnets, and you update VPC route tables so traffic passes through those endpoints, for example between an internet gateway and your application subnets.

AWS's native tools do not cover every security need, and when they do not, the place to turn is 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 security categories 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.

Marketplace also simplifies buying. 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 an organization wants a third-party security product, such as its existing firewall vendor in the cloud, a commercial SIEM or an endpoint agent, AWS Marketplace is where it finds, subscribes to and pays for it.

AWS publishes security information through three named sources, each for a different need: the AWS Knowledge Center for quick answers to common questions, the AWS Security Center for whitepapers, compliance information and security bulletins, and the AWS Security Blog for announcements and in-depth articles. Learn what each one is for, because the need decides the source.

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 hosted on AWS re:Post, AWS's community Q&A site. When you need a short, practical answer, such as how to troubleshoot an Access Denied error when calling an AWS API, the Knowledge Center fits. It covers all of AWS, with a substantial security section.

The AWS Security Center (aws.amazon.com/security) is AWS's central security site. It collects security whitepapers and best-practice guides, compliance information about the programs AWS participates in, and security bulletins: AWS's published advisories about vulnerabilities that may affect AWS services or customer workloads. Each individual service also has a security chapter in its own documentation.

The AWS Security Blog is where AWS announces new security features and services, publishes deep-dive walkthroughs, and shares best-practice posts written by AWS security engineers. Staying current with security announcements or reading detailed how-to articles points to the Security Blog.

Finally, AWS provides a channel 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 through the abuse reporting form.

AWS Trusted Advisor is the service this task names for identifying security issues: it inspects your account and compares your configuration against AWS best practices, producing checks across cost optimization, performance, security, fault tolerance, service limits, and operational excellence. For this task, the security category matters most.

Security checks flag concrete, high-risk misconfigurations. The classics: 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 user, IAM use (encouraging you to work through IAM identities rather than root), and publicly accessible Amazon EBS or Amazon RDS snapshots. Each finding is color-coded (green for no problem, yellow for investigation recommended, red for action recommended) so you can triage at a glance. Trusted Advisor is a best-practice configuration checker; it is not a threat-detection or vulnerability-scanning service (those are Amazon GuardDuty and Amazon Inspector, covered in AWS security, governance and compliance).

What you get depends on your AWS Support plan:

The support plans that include full Trusted Advisor are Business Support+, Enterprise Support and Unified Operations. The older Developer and Business Support plans are discontinued on 1 January 2027, and Enterprise On-Ramp customers are moved to Enterprise Support before that plan ends on the same date.

Now assemble the toolkit around one scenario. You run a public web application: an ALB in front of EC2 instances, with a database tier behind them. AWS Shield Standard already absorbs common DDoS floods at no extra cost. You attach AWS WAF to the ALB (or a CloudFront distribution in front of it) to block SQL injection and XSS. 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 with a rule numbered below its allow rules. Your team's preferred IDS appliance comes from AWS Marketplace. When the company grows to many accounts, AWS Firewall Manager rolls the same WAF and security group policies out to each one. Trusted Advisor then confirms nothing was left open, and the Security Blog, Security Center and Knowledge Center keep the team current.