How do you protect a network when attackers are constantly knocking on every door? In AWS, you layer protections: Security Groups act as virtual firewalls for your instances, Network Firewall inspects all traffic flowing through your VPC, and Web Application Firewall protects against application-layer attacks. Mastering these three tools is essential for the SCS-C02 exam, which will test your ability to design a defence-in-depth strategy that stops threats at every level.
Jump to a section
A simple way to picture Security Groups, Network Firewall, and Web Application Firewall
A busy nightclub on a Friday night. The bouncer at the main entrance checks IDs and the guest list. This is your Security Group. It is the first line of defence, deciding who (which IP address) can even walk up to the door and on which port (which entrance). It only checks the envelope — the source address and the destination port.
Once inside, the club has a separate, more private VIP section guarded by a second, tougher security team. This team does not just check IDs; they inspect what each guest is carrying. They scan bags, check for glass bottles, and ensure no one is bringing in recording equipment. This is your Network Firewall. It looks deeper into the packet than the bouncer. It can see the contents of the conversation and block specific requests based on rules, not just the destination.
Finally, there is the club's head of security who watches the dance floor through CCTV. He does not care who came through the door or what is in your bag. He watches what people are actually doing. He sees a patron sending a drink to a stranger and flags it as suspicious behaviour. This is your Web Application Firewall (WAF). It examines the actual request — the text in a form field, the URL being accessed — and blocks attacks like SQL injection and cross-site scripting. The bouncer, the VIP team, and the CCTV operator work together, but each has a distinct job. The Security Group controls the door. The Network Firewall inspects the package. The WAF protects the application logic.
Think of your AWS environment as a series of rooms in a secure building. Each room needs its own set of rules about who can enter and what they can do once inside. Security Groups, Network Firewall, and Web Application Firewall are the three key tools AWS gives you to control access at different layers of your network.
Security Groups act as a virtual firewall for your Amazon EC2 instances and other resources. They are stateful, meaning if you allow inbound traffic on port 80 (HTTP), the outbound response is automatically allowed, regardless of outbound rules. You define rules that specify allowed source IP addresses, protocols, and ports. For example, you might create a Security Group that allows SSH (port 22) only from your office's public IP address. Security Groups operate at the instance level, not the subnet level, so you can assign different Security Groups to different instances within the same subnet.
Network Firewall is a managed service that provides a more advanced, stateful inspection of all traffic entering and leaving your Virtual Private Cloud (VPC). Unlike Security Groups, Network Firewall can inspect traffic at layers 3 through 7 of the OSI model. It can block traffic based on domain names, URL paths, and even the content of packets. For example, you can create a rule that blocks all traffic to known malware domains or that prevents outbound data exfiltration to unauthorised IP ranges. Network Firewall is deployed in a central VPC or as part of a firewall subnet, and it inspects traffic as it passes through the VPC.
Web Application Firewall operates at the application layer (layer 7) and protects web applications from common exploits such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). It sits in front of your application, either as part of Amazon CloudFront, an Application Load Balancer (ALB), or API Gateway. WAF uses managed rule groups that AWS provides (like the Core Rule Set) to automatically detect and block malicious requests. You can also create custom rules to match specific patterns in headers, query strings, or request bodies.
The key difference between the three is the layer they operate at and the scope of control:
Security Groups control traffic at the instance level and are stateful.
Network Firewall controls traffic at the VPC level and is stateful with deep packet inspection.
Web Application Firewall controls traffic at the application level and protects against application-layer attacks.
In practice, you use all three together for defence in depth. Security Groups block unwanted connections from ever reaching your instances. Network Firewall filters out known bad traffic based on signatures and domain lists. WAF catches the sneaky application-level attacks that slip through the lower layers.
AWS recommends you use Security Groups for simple allow/deny rules based on IP addresses and ports. Use Network Firewall when you need to inspect traffic content, do domain filtering, or block traffic based on geographic location. Use WAF when you need to protect web applications from OWASP Top 10 vulnerabilities.
A common beginner trap is thinking Security Groups are enough for all scenarios. They are not. Security Groups cannot inspect packet contents, cannot block traffic based on URL patterns, and cannot detect SQL injection. That is why you need the other two services. Another trap is confusing the stateful nature of Security Groups with the stateless nature of Network Access Control Lists (NACLs). Security Groups automatically allow return traffic; NACLs do not.
Identify the Assets You Need to Protect
List every AWS resource in your architecture: EC2 instances, load balancers, databases, and Lambda functions. For each, determine what traffic needs to reach it and from which sources. This informs your Security Group, Network Firewall, and WAF rules.
Define Security Group Rules Using Least Privilege
Create Security Groups for each resource type. For a web server, create a rule allowing inbound HTTP/HTTPS only from the load balancer's Security Group. For a database, allow inbound MySQL only from the web servers' Security Group. Do not use 0.0.0.0/0 unless absolutely necessary.
Deploy AWS Network Firewall in a Dedicated Subnet
Create a firewall subnet in your VPC and launch an AWS Network Firewall instance. Configure route tables to send all egress and inter-subnet traffic through the firewall. Create stateful rule groups for domain filtering and intrusion prevention, and attach them to the firewall policy.
Attach a Web ACL Using AWS WAF to Your Internet-Facing Endpoint
Decide which front-end service (CloudFront, ALB, or API Gateway) receives your HTTP traffic. Create a Web ACL with managed rule groups like the Core Rule Set and add custom rules for rate limiting and IP blocking. Attach the Web ACL to the resource.
Test and Monitor the Layered Defences
Use tools like AWS Shield Advanced, VPC Flow Logs, and WAF logging to monitor blocked requests and allowed traffic. Simulate common attacks (e.g., SQL injection) against a test environment to verify that WAF blocks them. Check Network Firewall logs for any traffic that bypassed Security Groups. Adjust rules based on findings.
Imagine you work as a cloud security engineer for a fintech company called PayFlow. PayFlow runs a web application on AWS that processes credit card payments. The application is deployed across multiple Amazon EC2 instances behind an Application Load Balancer (ALB), and the database is an Amazon RDS instance in a private subnet. Your job is to secure this architecture.
Your first step is to create Security Groups. You create a Security Group for the ALB that allows inbound HTTP (port 80) and HTTPS (port 443) traffic from anywhere (0.0.0.0/0), since customers need to reach your website. You create a second Security Group for the EC2 instances that only allows inbound traffic from the ALB's Security Group. This means if an attacker somehow discovers the IP address of your EC2 instances, they still cannot connect because the Security Group denies traffic from any source other than the ALB. You create a third Security Group for the RDS database that allows inbound MySQL traffic (port 3306) only from the EC2 instances' Security Group. This creates a tight chain: customer -> ALB -> EC2 -> RDS.
Next, you configure AWS Network Firewall. You deploy it in a dedicated firewall subnet within your VPC. You create a stateful rule group that blocks traffic to known malicious IP addresses from threat intelligence feeds. You also create a domain list rule that blocks outbound traffic to any domain not on your approved list. For example, you block all traffic to social media sites and file-sharing services to prevent data exfiltration. You also enable intrusion prevention (IPS) mode, which inspects the packet payload for attack signatures and blocks suspicious traffic in real time.
Finally, you set up AWS WAF on your Application Load Balancer. You enable the AWS managed Core Rule Set, which blocks common attacks like SQL injection, cross-site scripting, and path traversal. You also create a custom rule that inspects the User-Agent header and blocks requests with known bad user agents (like those from vulnerability scanners). You set up rate-based rules that automatically block IP addresses that send more than 1,000 requests in a 5-minute window — a classic sign of a DDoS attack.
When a real attack happens — say a SQL injection attempt on the login page — the flow works like this:
The request first hits the ALB, which forwards it to WAF.
WAF inspects the request body, sees the string "OR 1=1" in the username field, and blocks the request, returning a 403 Forbidden response.
If WAF had missed it, the request still arrives at the EC2 instance. But because the Security Group only allows traffic from the ALB, an attacker cannot bypass WAF and connect directly to the instance.
Even if the request makes it past Security Groups, Network Firewall inspects the traffic and can also block the malicious packet based on its content.
This layered approach is exactly what the SCS-C02 exam expects you to design. The exam will present scenarios where you must choose which service to apply. For example, they might ask: 'A company needs to block all traffic to a specific domain. Which service should they use?' The answer is Network Firewall, because it supports domain-based filtering. Or: 'An application needs to block SQL injection attacks.' The answer is WAF, because it operates at layer 7.
The SCS-C02 exam tests your ability to design and implement security groups and network firewalls as part of a defence-in-depth strategy. Here is exactly what you need to know.
Security Groups are one of the most heavily tested topics in this domain. The exam loves to test the difference between Security Groups (stateful) and Network ACLs (stateless). They will give you a scenario where a rule change breaks connectivity because a candidate forgot that Security Groups automatically allow return traffic while NACLs do not. Memorise this: Security Groups are stateful — allow inbound = allow outbound response. NACLs are stateless — you must explicitly allow both inbound and outbound traffic.
For Security Groups, the exam often tests the concept of 'least privilege'. They will ask: 'What is the most secure way to configure a Security Group for a web server?' The correct answer is to allow inbound traffic on port 80 and 443 only from the load balancer's Security Group, not from 0.0.0.0/0. They test whether you know you can reference another Security Group by its ID in a rule.
Network Firewall is a newer service and appears less frequently, but it is tested. The exam focuses on when to use Network Firewall versus third-party firewall appliances from the AWS Marketplace. They ask: 'When would you choose AWS Network Firewall over a third-party firewall?' The answer usually revolves around the need for a fully managed, cloud-native service that integrates with AWS services like VPC Flow Logs and Route 53.
Web Application Firewall is tested in the context of application protection. The exam asks about managed rule groups, rate-based rules, and how WAF integrates with CloudFront, ALB, and API Gateway. A common trap is confusing WAF with Shield (AWS Shield is for DDoS protection at the network layer, while WAF is for application-layer attacks). Another trap is thinking WAF can protect all non-HTTP protocols — it only protects HTTP/HTTPS.
Specific exam traps to watch for: - 'Security Groups are applied at the subnet level' — false. They are applied at the instance level. - 'Network Firewall can inspect encrypted traffic' — not natively. You need to configure TLS inspection. - 'WAF can block traffic based on IP reputation' — yes, via IP set rules using threat intelligence feeds. - 'Security Groups block all traffic by default' — yes, they have an implicit deny all inbound and allow all outbound.
The exam also tests the concept of 'defence in depth'. They present a scenario where a single control fails and ask which additional control would catch the failure. For instance: 'A web application is protected by WAF but still gets compromised via SQL injection. What could be missing?' The answer is that Security Groups should restrict inbound traffic to the application from only the load balancer, preventing direct access.
Key definitions to memorise:
Stateful: Automatically tracks connection state and allows return traffic.
Stateless: Each packet is evaluated individually, and return traffic must be explicitly allowed.
Managed rule group: A pre-configured set of rules provided by AWS or AWS Marketplace partners.
Rate-based rule: A WAF rule that automatically blocks IPs exceeding a request threshold in a time window.
Intrusion prevention system (IPS): A Network Firewall feature that inspects traffic and blocks malicious packets.
Web ACL: The configuration object in WAF that contains the rules and default action (allow or block).
Security Groups are stateful — if you allow inbound traffic, the outbound response is automatically allowed, unlike Network ACLs which require explicit rules in both directions.
Security Groups only support allow rules. To deny specific IPs, use Network ACLs or AWS Network Firewall.
Web Application Firewall (WAF) protects against application-layer attacks like SQL injection and cross-site scripting and integrates with CloudFront, ALB, and API Gateway.
AWS Network Firewall provides deep packet inspection, domain filtering, and intrusion prevention at the VPC level, complementing Security Groups and WAF.
Defence in depth means layering Security Groups, Network Firewall, and WAF so that if one control fails, another catches the threat.
You can reference another Security Group by its ID in a rule to allow traffic only from resources that have that Security Group attached — a key least-privilege pattern.
WAF rate-based rules can automatically block IP addresses that exceed a defined request threshold, helping mitigate DDoS attacks.
AWS Network Firewall can use threat intelligence feeds to block traffic from known malicious IP addresses.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Stateful — automatically allows return traffic if inbound is permitted.
Operates at the instance or resource level.
Only supports allow rules (no explicit deny).
Network ACL
Stateless — return traffic must be explicitly allowed.
Operates at the subnet level.
Supports both allow and deny rules.
AWS WAF
Operates at layer 7 (application layer).
Protects against SQL injection, XSS, and web-specific attacks.
Integrates with CloudFront, ALB, and API Gateway.
AWS Network Firewall
Operates at layers 3-7 (network to application layer).
Provides deep packet inspection, domain filtering, and IPS.
Deployed at the VPC level and inspects all routed traffic.
Security Group
Controls traffic based on IP addresses, ports, and protocols.
Applies to any resource (EC2, RDS, Lambda).
Cannot inspect the content of the packet (e.g., no SQL injection detection).
AWS WAF
Inspects the content of HTTP/HTTPS requests (headers, body, URL).
Only protects web-facing services (CloudFront, ALB, API Gateway).
Can detect and block application-layer attacks using rule groups.
Mistake
Security Groups are applied at the subnet level like a network ACL.
Correct
Security Groups are applied at the instance or resource level, not the subnet. Each instance can have its own Security Group, and multiple instances can share the same Security Group.
This confusion comes because both Security Groups and NACLs control traffic, but beginners mix up which layer they operate at. The exam deliberately tests this difference.
Mistake
Adding a deny rule to a Security Group will explicitly block a specific IP address.
Correct
Security Groups only support allow rules. There is no way to add a deny rule. To block a specific IP, you must either not include it in an allow rule (implicit deny) or use a Network ACL or Network Firewall instead.
People are familiar with traditional firewalls that support both allow and deny rules. Security Groups' 'allow-only' design is counterintuitive, leading to this mistake.
Mistake
Web Application Firewall can protect any AWS service, including S3 buckets and EC2 instances directly.
Correct
WAF only protects services that have an associated web ACL: CloudFront, Application Load Balancer, API Gateway, and AWS AppSync. It cannot be attached directly to an EC2 instance.
Beginners assume WAF is a universal filter, but it is tightly integrated with specific AWS services that act as the entry point for HTTP/HTTPS traffic.
Mistake
AWS Network Firewall can inspect and block malicious traffic inside the VPC between instances in the same subnet.
Correct
Network Firewall is deployed at the VPC edge or in a dedicated subnet and inspects traffic crossing VPC boundaries (east-west traffic between subnets can be inspected, but only if it is routed through the firewall). It does not magically inspect all intra-subnet traffic.
This misconception arises from thinking Network Firewall is a transparent inline device for all VPC traffic, but routing must be specifically configured to force traffic through the firewall.
Mistake
Security Groups and Network Firewall are interchangeable — you only need one or the other.
Correct
They serve different purposes. Security Groups are simple, instance-level filters for ports and IPs. Network Firewall provides deep packet inspection, domain filtering, and intrusion prevention. They are complementary and used together for defence in depth.
Beginners looking for a single solution may think one tool covers all needs, but the exam emphasises using multiple layers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Security Group is stateful and acts as a virtual firewall at the instance level, automatically allowing return traffic. A Network ACL is stateless and acts at the subnet level, requiring you to explicitly allow both inbound and outbound traffic. Security Groups are typically the first choice for instance-level control.
No, you cannot attach a Web ACL directly to an EC2 instance. AWS WAF only integrates with CloudFront, Application Load Balancer (ALB), API Gateway, and AWS AppSync. To protect an EC2 instance with WAF, you must place it behind an ALB or CloudFront distribution.
By default, no. Traffic between instances in the same subnet stays within the subnet and does not pass through Network Firewall. To inspect east-west traffic, you must configure the VPC route tables to route that traffic through the firewall subnet.
Security Groups only allow rules; they cannot explicitly deny traffic. To block a specific IP, you can omit it from the allow rules (implicit deny) or use a Network ACL or Network Firewall rule with a deny action.
A managed rule group is a pre-configured set of rules provided by AWS or AWS Marketplace vendors that automatically detect and block common web attacks like SQL injection, cross-site scripting, and known bad bots. You can enable them in your Web ACL with a single click.
For effective defence in depth, you should use all three. Security Groups are fundamental for instance-level control, Network Firewall provides centralised inspection and filtering at the VPC level, and WAF protects your web applications from application-layer attacks. Relying on only one leaves significant gaps.
You've finished Security Groups, Network Firewall, and Web Application Firewall. Continue through the SCS-C02 study guide to build a complete picture of the exam.
Done with this chapter?