Auditing Network Protection Services

Compliance sends one line: confirm that every internet-facing application in the production account is protected by a web application firewall. You open the console, find a web ACL named prod-web-acl with 14 rules including the AWS managed core rule set, and reply that you are covered.

You may have just signed off on nothing. A web ACL is a standalone resource. Until it is associated with a specific CloudFront distribution or load balancer, it inspects zero requests, and the console page looks identical either way. The same shape of gap exists in all 4 of the services in this lesson, which is why the exam has a skill statement for auditing them rather than for configuring them.

Four services, four different pieces of traffic

Before you can audit these services you have to know what each one is even in a position to see. They are not layers of the same wall. They sit on different paths, and a gap in one is completely invisible to the other 3.

Two boundaries in that table earn their own sentence.

AWS WAF sees requests, Network Firewall sees packets. WAF only exists in front of resource types that speak HTTP: CloudFront distributions, Application Load Balancers, API Gateway REST APIs, AppSync GraphQL APIs, Cognito user pools, App Runner services, Bedrock AgentCore Gateways, Verified Access instances, and Amplify. Nothing else. If your workload is a database replica shipping data over a custom TCP port, WAF is not the control that could ever have caught it, and Network Firewall is.

DNS Firewall sees queries, Network Firewall sees connections. Both can filter by domain name, and that overlap is a favorite exam trap. DNS Firewall filters the DNS lookup itself as it passes through the Route 53 VPC Resolver, so it stops the workload from ever learning the address. Network Firewall inspects the resulting traffic on the wire but has no visibility into Resolver queries at all. AWS states this directly: the 2 services filter domain names on 2 different network paths.

The 4 questions an audit answers

Every one of these services can be deployed and still protect nothing, and the failure is always one of the same 4 steps. Carry this frame through the rest of the lesson and apply it to whatever service the exam names:

1. Is it deployed? Does the resource exist in this account and Region?
2. Is it attached to what you think? Association, subnet, route, or VPC binding.
3. Is it enforcing, or only observing? Count, Alert, and Pass all produce healthy-looking telemetry while permitting the traffic.
4. Can you prove what it did? Logging is off by default on most of these, and an audit without evidence is an opinion.

Question 3 is where real environments fail, because step 3 is a normal and correct part of every rollout. You start a new rule in count mode on purpose. Nobody schedules the day you turn it on.

Auditing AWS WAF

Start with the association, because that is the question the auditor actually asked. Web ACLs live in 2 separate scopes, and the CloudFront scope only exists in us-east-1:

# Regional resources: ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access
aws wafv2 list-web-acls --scope REGIONAL --region eu-west-1

aws wafv2 list-resources-for-web-acl \
  --web-acl-arn arn:aws:wafv2:eu-west-1:111122223333:regional/webacl/prod-web-acl/a1b2c3d4 \
  --region eu-west-1

# CloudFront distributions are always in the us-east-1 CLOUDFRONT scope
aws wafv2 list-web-acls --scope CLOUDFRONT --region us-east-1

An empty ResourceArns list is the finding. Work the other direction too: list your ALBs and CloudFront distributions and check which ones have no web ACL at all, because a resource with no association will never appear in any web ACL's resource list.

Once the association is confirmed, 4 configuration details decide whether the web ACL blocks anything.

The default action. A web ACL applies its default action to every request that no rule terminated on. Allow is normal for a public site protected by explicit block rules. Block is normal for a locked-down internal API. Reading the default action tells you which model the web ACL was designed for, and a Block default with a broad allow rule at the top is a very different security posture from what its name suggests.

Terminating and non-terminating actions. Allow and Block stop evaluation immediately, and whichever matches first decides the request. Count never terminates: it increments a metric and evaluation continues. CAPTCHA and Challenge are conditional, terminating only when the request has no valid token. So a rule set can be full of well-written block rules that never run.

Rule priority. AWS WAF evaluates rules from the lowest numeric priority upward. An allow rule at priority 10 that matches your office IP range will terminate before the SQL injection rule at priority 50 ever sees the request. Broad allow rules near the top are the single most productive thing to look for in a web ACL review.

Rule group overrides. When you add a managed rule group, you can override the whole group's action to Count, or override individual rules inside it. This is the intended way to trial the AWS managed core rule set without breaking a live application. It is also the most common reason a web ACL with excellent rules blocks nothing. Check for it explicitly; the console shows it as a small badge that is easy to skim past.

For question 4, WAF logging is off until you configure it. You can send web ACL logs to a CloudWatch Logs log group, an S3 bucket, or an Amazon Data Firehose delivery stream, and you can redact fields and filter which records are kept. Separately, request sampling gives you a rolling look at recent evaluated requests without any logging setup, which is the fastest way to see whether a rule is matching at all. The CloudWatch metrics to read are AllowedRequests, BlockedRequests, and CountedRequests. A web ACL whose BlockedRequests has been flat at zero for months while CountedRequests climbs is telling you the answer to question 3.

Auditing AWS Shield

Shield splits cleanly into an automatic half and a subscribed half, and the audit questions are different for each.

Shield Standard is on for every AWS customer at no extra charge and defends against the common network and transport layer floods. There is nothing to enable, nothing to attach, and nothing to audit beyond knowing it is there.

Shield Advanced is a subscription at $3,000 per month with a 1-year commitment, billed per payer account where that payer or any linked account is subscribed. It protects EC2 instances, Elastic Load Balancing load balancers, CloudFront distributions, Route 53 hosted zones, and Global Accelerator standard accelerators.

Here is the misconception worth naming: subscribing to Shield Advanced does not protect your resources. The subscription unlocks the capability. You still create a protection for each resource you want covered. The predictable audit finding is a load balancer created 3 months after the subscription started that nobody added, and the account is paying $3,000 a month partly for coverage it does not have.

aws shield describe-subscription          # is the account subscribed, and when does the term end
aws shield list-protections               # which resource ARNs are actually protected

Diff that protection list against the eligible resources in the account. That diff is your finding.

Three more Shield Advanced settings carry real audit weight:

• Automatic application layer DDoS mitigation can be configured to count or to block the web requests it identifies as part of an attack. Set to count, it is a detector. Enabling it adds a rule group consuming 150 WCUs to the associated web ACL, which counts against the web ACL's capacity.
• Health-based detection associates a Route 53 health check with a protected resource so Shield can distinguish a real impact from a benign traffic spike. It is available for every resource type except Route 53 hosted zones, and proactive engagement by the Shield Response Team only works on resources that have it enabled.
• Shield Response Team access additionally requires a Business or Enterprise Support plan. A subscription without the support plan means the phone number in your runbook does not work.

Shield Advanced also offers cost protection against bill spikes caused by an attack, granted as service credits after the fact rather than as an automatic discount.

Auditing AWS Network Firewall

Network Firewall has the largest gap between "the resource exists" and "the resource is doing something", so this is the deepest of the 4 audits.

The service creates a firewall endpoint in each subnet you designate, and each endpoint gives the firewall availability in its Availability Zone. A firewall policy holds the settings and points at rule groups, stateless and stateful. None of that puts the firewall in the traffic path.

Route tables are the enforcement mechanism. You edit VPC route tables so a protected subnet's traffic goes to the firewall endpoint, and so return traffic from the internet gateway comes back through the endpoint before reaching the subnet. Skip that step and you have a fully configured firewall with a monthly bill and zero packets. When a scenario says the firewall is deployed and correctly configured but traffic is not being filtered, the routes are the answer.

Four more checks, in the order they usually bite:

Availability Zone coverage. One endpoint per AZ, and the endpoint's availability is scoped to its own zone. Workloads in an AZ with no firewall endpoint are unfiltered, or their traffic crosses an AZ boundary to reach an endpoint elsewhere and picks up cross-zone data transfer charges on the way. Compare the list of AZs holding workload subnets against the list of AZs holding firewall subnets.

Dedicated firewall subnets. A firewall endpoint cannot filter traffic entering or leaving the subnet it lives in. Put a workload in a firewall subnet and that workload is exempt from inspection. AWS is explicit: use firewall subnets for nothing else.

Stateless default actions. The stateless engine runs first and decides whether each packet is passed, dropped, or forwarded to the stateful engine. If the stateless default action is Pass and no stateless rule forwards traffic onward, your Suricata rules and domain lists never execute. The policy is perfectly valid, which is what makes it an audit finding instead of an error. The same setting has a separate default for UDP packet fragments; Network Firewall silently drops fragments of other protocols.

Stateful rule evaluation order. A policy uses either action order or strict order, and RuleOrder can only be set when the policy is created. It cannot be edited afterward. Under action order, Suricata evaluates every pass rule before any drop, reject, or alert rule regardless of the priority keyword, so a permissive pass rule anywhere in any rule group overrides everything below it. Under strict order, rule groups run by ascending priority and rules run in the order written, and you also choose default actions such as Drop all or Drop established. AWS recommends strict order for exactly this predictability. If an audit finds a drop rule that never fires, action order plus a broad pass rule is the first hypothesis.

For evidence, Network Firewall logging is off until you configure it, and it produces 3 log types you enable separately:

The constraint that catches people: only traffic forwarded to the stateful engine is logged at all. Stateless drops never appear in these logs. CloudWatch metrics cover both engines and are the right place to confirm the firewall is receiving traffic in the first place.

One last item worth recording: delete protection is enabled when a firewall is created and must be explicitly turned off through the API before the firewall can be deleted. The console does not show the setting because the deletion flow disables it for you.

Auditing Route 53 Resolver DNS Firewall

DNS Firewall filters outbound DNS queries as they pass through the Route 53 VPC Resolver. Its headline job is stopping DNS exfiltration, where an attacker who has compromised an instance encodes data into lookups against a domain they control. It also blocks resolution of private hosted zone records, VPC endpoint names, and EC2 instance names.

Association. Rule groups do nothing until associated with a VPC, and you can associate up to 5 rule groups per VPC per Region. Confirm the association and its priority, then check that the priority order matches your intent, since lower numbers evaluate first both across associated rule groups and among rules inside one group.

aws route53resolver list-firewall-rule-group-associations --vpc-id vpc-0abc123
aws route53resolver list-firewall-rules --firewall-rule-group-id rslvr-frg-0abc123
aws route53resolver list-firewall-configs        # the fail-open setting per VPC

Rule action. Every rule carries exactly one of 3 actions:

AWS itself recommends creating a blocking rule as Alert first so you can measure how many queries it would have blocked. That advice creates the most common DNS Firewall finding in existence: a rule group where every rule is still on Alert a year later. Alert is a detector; Block is a control. Reading the action list is a 30 second check with real consequences.

Block response. When the action is Block, you choose what the client hears back:

• NODATA answers that the query succeeded but no record is available.
• NXDOMAIN answers that the domain name does not exist.
• OVERRIDE returns a custom CNAME you specify, with a time to live that defaults to 0 so the answer is not cached. This is how you route blocked lookups to a sinkhole or an internal warning page.

Managed domain lists. AWS maintains 4 lists you can use for free: Malware, Botnet/Command and Control, Aggregate Threat List (a superset of the others, adding ransomware, spyware, and DNS tunneling), and Amazon GuardDuty Threat List (domains from GuardDuty's own DNS findings). You cannot view or download their contents, which is deliberate: a published block list is a specification for evading it. When a managed list produces a false positive, the fix is to add an allow rule for that specific domain and give it a lower numeric priority than the blocking rule so it runs first.

Failure mode. This is the setting nobody checks. When VPC Resolver gets no reply from DNS Firewall, the VPC's firewall configuration decides what happens:

• Fail closed is the default. The query is blocked and VPC Resolver returns SERVFAIL. Security over availability.
• Fail open, set through the FirewallFailOpen field, lets the query through. Availability over security.

Both are legitimate choices, and neither is an error. But a fail-open VPC loses its DNS protections during exactly the moments an attacker would want them gone, so the audit finding is not "fail open is wrong", it is "fail open is set and nobody documented the decision".

Worth memorizing alongside the config: 5 rule groups per VPC, 100 rules per rule group, 1,000 rule groups per account per Region, 100,000 domains across all your domain lists.

Turning spot checks into standing evidence

Everything above is a point-in-time answer. An audit that has to be repeated by hand every quarter will not be repeated.

AWS Config records configuration changes to these resources and evaluates managed rules against them continuously, so a web ACL that loses its association or a firewall policy whose default action changes generates a noncompliant finding on its own. Conformance packs bundle the relevant rules into one deployable unit.

AWS Security Hub aggregates those Config findings alongside GuardDuty and Inspector results and scores them against standards such as the AWS Foundational Security Best Practices, which turns "are we protected" into a number with a trend line.

CloudWatch alarms close question 3 permanently. An alarm on a web ACL's BlockedRequests staying at zero across a full week, or on Network Firewall's packet counters dropping to nothing, catches the silent regressions that a quarterly review misses by 89 days.

One scope note that matters for the exam. This skill is written as auditing these services in a single account. The moment the question widens to every VPC in every member account, including accounts that do not exist yet, the answer changes to AWS Firewall Manager, which centrally applies AWS WAF, Shield Advanced, security group, network ACL, Network Firewall, and DNS Firewall policies across an organization and automatically brings new resources into scope. Firewall Manager requires AWS Organizations and AWS Config. Keep it filed as the organization-wide answer so it does not tempt you on a single-account question.

Exam tips

• Existence is not protection. For WAF read the association, for Shield read the protection list, for Network Firewall read the route tables, for DNS Firewall read the VPC association. That single move answers most audit questions on this skill.
• Count, Alert, and Pass are the observe-only settings. WAF Count and rule group overrides, Shield automatic mitigation set to count, Network Firewall stateless default Pass, DNS Firewall Alert. A scenario describing "logs show the traffic but it is not blocked" is pointing at one of these.
• Domain filtering appears twice. Queries through the Resolver are DNS Firewall; traffic on the wire is Network Firewall. Network Firewall has no visibility into Resolver queries.
• AWS WAF only attaches to HTTP resource types. CloudFront, ALB, API Gateway, AppSync, Cognito user pools, App Runner, Bedrock AgentCore Gateway, Verified Access, Amplify. Not EC2, not NLB, not RDS.
• Shield Standard is free and automatic; Shield Advanced is $3,000 a month on a 1-year commitment and protects only the resources you explicitly add.
• Network Firewall route tables, dedicated firewall subnets, and one endpoint per AZ. A firewall endpoint cannot filter its own subnet.
• RuleOrder is set at policy creation and cannot be changed. Strict order is the recommended choice.
• DNS Firewall fails closed by default and returns SERVFAIL. Fail open is opt-in.
• Single account is the audit; AWS Organizations is Firewall Manager.

The habit to carry out of this lesson is smaller than the service list: for any protection control, find the binding that connects it to real traffic, then find the setting that decides whether it acts or only watches. Those 2 facts are the audit. The next lesson looks at the same network from the opposite direction, asking not whether it is protected but what every gigabyte crossing it costs you.