Domain Filtering and Egress Control

Most firewalls focus on inbound traffic, but egress (outbound) control is critical for security. Compromised workloads call out to attacker servers to receive commands or exfiltrate data. Restricting which destinations your resources can reach cuts off this path and limits the damage of a breach.

Security groups and NACLs can restrict outbound traffic only by IP and port, not by domain. Since attacker infrastructure uses rotating IPs and shared cloud hosts, IP-based egress rules are brittle. Domain-based filtering in Network Firewall solves this by controlling destinations by name.

A domain allow-list permits outbound traffic only to approved domains, such as your software repositories, AWS service endpoints, and partner APIs, blocking everything else. This deny-by-default posture means even a compromised host cannot reach unknown command-and-control servers.

A domain deny-list takes the opposite approach, blocking known-bad or unwanted domains while allowing the rest. Allow-lists are stronger for high-security environments, while deny-lists suit less restrictive workloads where blocking everything would be impractical.

Network Firewall inspects the TLS SNI (Server Name Indication) for HTTPS and the HTTP Host header for plaintext to determine the destination domain. Because SNI is sent in the clear during the TLS handshake, the firewall can filter HTTPS by domain without decrypting the traffic.

Egress filtering directly counters data exfiltration. If an attacker tries to upload stolen data to an unapproved cloud-storage or paste site, the domain rule blocks the connection. Combined with logging, you also get an alert that an attempt occurred, aiding detection.

Malware typically beacons to command-and-control (C2) domains to receive instructions. A strict egress allow-list breaks this loop because the C2 domain is not on the list, neutralizing many malware families even after initial infection. This is a key containment control.

In multi-VPC setups, route all outbound traffic through a central inspection VPC running Network Firewall via a transit gateway. One egress policy then governs every workload, and a single set of domain rules is consistently enforced organization-wide, simplifying both security and auditing.

Egress filtering usually sits alongside a NAT gateway in the outbound path. Traffic flows from private subnets through the firewall, then NAT, to the internet. Route tables must send traffic through the firewall endpoint before NAT so inspection happens on every outbound connection.

Send Network Firewall alert and flow logs to your log pipeline so you can see which egress attempts were blocked and which domains workloads contact. Unexpected blocked domains can reveal compromise, while the allowed list helps you right-size and tighten the policy over time.

Effective egress security layers domain allow-lists, default-drop strict ordering, centralized inspection, and thorough logging. This turns outbound traffic from an open door into a tightly governed, observable channel, a control the SCS-C02 exam emphasizes for containing breaches.

Apply egress-filtering reasoning.

Egress control stops compromised hosts from reaching attacker infrastructure. Because security groups and NACLs filter only by IP and port, use Network Firewall domain allow-lists or deny-lists, matching the TLS SNI and HTTP Host without decryption. This blocks command-and-control beacons and data exfiltration. Centralize egress through an inspection VPC, place the firewall before NAT, and log all decisions.