AWS Network Firewall: Stop Exfil Without Breaking Egress

AWS Network Firewall in a centralized inspection VPC is the right answer when security hands you a ticket to block unexpected egress — here's how to design it without taking down production at 2am. You'll learn: Why the firewall lives in one centralized inspection VPC behind AWS Transit Gateway, not deployed per spoke VPC — and how the route tables enforce that How stateful domain-list rules use TLS SNI to allow *.github.com and *.pypi.org while dropping everything else on 443 — without decrypting traffic The encrypted client hello (ECH) blind spot: why SNI-based rules can silently stop matching and what you need as a backstop How to roll out in alert/count mode first, capture a full week of egress patterns to CloudWatch, and flip rule groups to drop one at a time Pricing gotcha: endpoint hours per AZ plus data processed means centralized inspection is cheaper, but you must size for combined peak across all VPCs Keywords: AWS Network Firewall interview questions, TLS SNI egress filtering, centralized inspection VPC, cloud security engineer interview, data exfiltration AWS 🎧 Listen, then go deeper — DevOps & Cloud interview-prep ebooks at DevOpsInterview.Cloud ▶ Daily 30-second interview drills: DevOps Interview Cloud on YouTube Transcript Security just sent you a ticket. Block all unexpected egress across every VPC. No more instances calling out to random IPs on the internet. Sounds simple until you realize your build servers pull from package registries, your app calls three SaaS APIs, and nobody has a full list of what's actually supposed to be leaving the network. Ship the wrong rule set and you either miss real exfiltration paths, or you break a deploy at two in the morning and get paged for it. This question shows up in senior DevOps and cloud security interviews because it tests three things at once. Can you design for centralized inspection instead of bolting a firewall onto every VPC. Do you understand the tradeoff between IP-based and domain-based filtering. And do you have a rollout process that doesn't nuke production traffic on day one. Anyone can say "add a firewall." Fewer people can explain why it goes in one place, and how you prove it's safe before you flip it to blocking mode. Start with the mental model. In a multi-VPC setup, you do not want AWS Network Firewall deployed separately in every spoke VPC. That's operationally painful, it's expensive, and every team ends up writing slightly different rules. The standard pattern is a centralized inspection VPC, sitting between your spoke VPCs and the internet, usually paired with AWS Transit Gateway. Every spoke VPC routes its default egress through the transit gateway to the inspection VPC. The firewall endpoints live there, traffic gets inspected once, using one shared rule set, and then it's routed out through a NAT gateway to the internet. The firewall itself has two kinds of rules. Stateless rules operate on packet headers, source and destination IP, ports, protocol. They're fast, but they don't know anything about the content or the destination domain. Stateful rules track connections and can inspect protocol details, and this is where domain filtering comes in. AWS Network Firewall supports domain-based stateful rules using the HOME_NET and TLS SNI, the Server Name Indication field. Since most traffic is encrypted, the firewall reads the SNI in the TLS handshake to figure out what domain a connection is headed to, without decrypting the actual payload. Here's the walkthrough security actually wants. Instead of writing rules like "allow this IP range," which breaks the moment a SaaS vendor rotates their infrastructure behind a content delivery network, you write domain allow lists. Something like: allow egress to star dot amazonaws dot com, star dot github dot com, star dot pypi dot org, your internal artifact registry domain, and your approved SaaS endpoints like star dot datadoghq dot com. Everything else on port 443 and port 80 gets dropped by a default deny rule at the bottom of the rule group. That's the actual control that stops exfiltration. An attacker who compromises a workload can't just open a connection to some random domain and quietly ship data out, because the SNI doesn't match anything on the allow list and the connection gets reset. A concrete example: say you've got an application VPC running ECS tasks that call out to a payments API and pull container images from Amazon ECR. You'd build a stateful rule group with domain list rules, action equals pass, targeting star dot amazonaws dot com for ECR and S3 access, plus the specific payments vendor domain. Then a second rule group, lower priority, with a drop-all rule for anything else on 443. You attach both rule groups to a firewall policy, and that policy gets applied to the firewall in the inspection VPC. Every spoke VPC's route table sends 0.0.0.0/0 traffic to the transit gateway attachment for the inspection VPC, so nothing bypasses the firewall. Now the tradeoffs, because this is where people get burned. Domain filtering by SNI only works for standard TLS on the usual ports, and only if the client isn't using something like encrypted client hello, which hides the SNI entirely. If a vendor rolls out ECH, your domain rule silently stops matching and either everything from them gets blocked, or worse, it falls through some overly broad rule you added while troubleshooting. You also can't domain-filter plain HTTP or arbitrary custom ports the same way, so you still need IP or port-based stateless rules as a backstop for non-standard traffic, like a database replication port or a syslog forwarder hitting a fixed IP. Cost and scale matter too. Network Firewall pricing is based on endpoint hours per availability zone plus data processed, so centralizing it in one inspection VPC is cheaper than deploying it per spoke VPC, but you're also creating a single choke point. Size your endpoints for peak traffic across all VPCs combined, not just one team's workload, or you'll see latency spikes during deploys when everyone's pulling images at once. The rollout process is the part that saves you from an outage. Never go straight to a default-deny domain policy in a live account. Start in alert mode, sometimes called count mode, where the firewall logs what it would have blocked without actually dropping it. Ship those logs to CloudWatch or S3, run them for at least a full business cycle, ideally including a deploy day, a patch day, and a batch job day, because those all have different egress patterns. Build your domain allow list from that real traffic, not from what people think they're calling. Then flip specific rule groups from alert to drop one at a time, watch error rates and application logs, and keep a documented rollback, which just means removing that rule group from the policy or reverting the route table change on the spoke VPC. Common wrong answers you'll hear in interviews. One: "just use security groups." Security groups are IP and port based, they don't understand domains, and CDN-fronted SaaS traffic breaks them constantly. Two: "deploy Network Firewall in every VPC." Technically works, but it's expensive, hard to keep consistent, and it's not what "centralized inspection" architecture means when an interviewer asks for it. Three: "block everything by IP range from threat intel feeds." That catches known-bad infrastructure but does nothing against a compromised workload calling out to a brand-new domain that hasn't been flagged yet, which is exactly the exfiltration scenario security is worried about. Four: forgetting DNS. If you don't also control DNS resolution, or at least log it through Route 53 Resolver query logging, attackers can tunnel data through DNS queries themselves, which a domain-based TLS rule won't ever see. Quick recap. Centralize AWS Network Firewall in a dedicated inspection VPC, route all spoke VPC egress through transit gateway into it. Use stateful domain-based rules keyed off TLS SNI for an allow list of legitimate destinations, backed by stateless IP and port rules for non-TLS or fixed-port traffic. Roll out in alert mode first, build your allow list from real traffic patterns across a full business cycle, then convert to drop mode one rule group at a time. Watch for encrypted client hello breaking SNI matching, and don't forget DNS query logging as a second exfiltration channel outside the firewall's visibility. If you want the full written version of this, with the actual rule group syntax and a rollout checklist you can bring into an interview or a real migration, it's all laid out over at devopsinterview dot cloud.