AWS Network Firewall & Secure VPC Design: — Drawing the Line Around Your Cloud

① The VPC security layers — SG, NACL & Network Firewall

Meet Sneha, an L1 cloud engineer at Flipkart. Her VPC 10.20.0.0/16 hosts a payments app. On day one she's told "the VPC is secured — the security groups are tight." Then an incident lands: a compromised container is quietly sending data out to data-collector.unknown-site.example over port 443. The security group allowed all outbound (the default), so nothing stopped it. This is the lesson in one story: the three VPC layers do different jobs, and most leaks happen in the gap between them.

Layer one is the security group (SG). It's attached to an ENI (an instance, a load balancer, an RDS endpoint). It is stateful — if you allow an inbound request, the reply is allowed automatically — and it only has allow rules. Think of it as the guard standing at your individual flat's door. The classic default mistake: outbound is left wide open (0.0.0.0/0 allow all), so a host can talk to anything on the internet.

Layer two is the network ACL (NACL). It sits on the subnet boundary, is stateless (you must write both the inbound AND the matching outbound/ephemeral-port rule yourself), and supports explicit deny. Think of it as the society's main gate register — it sees everyone entering or leaving the whole building block, but it only checks IP, port and protocol numbers. It still can't tell that one HTTPS flow is a legitimate API call and another is exfiltration to a strange domain.

Layer three is AWS Network Firewall. It is a managed service — AWS runs the engine, scales it, and patches it — that you deploy as firewall endpoints inside dedicated subnets of your VPC. Under the hood it runs a Suricata-compatible engine, so it can match attack signatures (true IPS), filter by domain name (the SNI in a TLS handshake or the HTTP Host header), and — if you enable it — do TLS inspection to look inside encrypted traffic. This is the layer that catches Sneha's exfiltration.

The three layers, one tap each

Tap each card. If you can rattle these off, half the SCS-C02 Infrastructure Security domain stops being scary.

② Architecture patterns — inspection VPC, TGW & the route-table dance

One firewall per VPC works for a single app, but real estates have dozens of VPCs across many accounts. You don't deploy a firewall in each — you build a central inspection VPC and route everyone's traffic through it. The hub that makes this possible is the Transit Gateway (TGW): every spoke VPC attaches once, and the TGW route tables steer traffic into the inspection VPC before it goes anywhere else.

Inside the inspection VPC, AWS requires a specific subnet layout. In each Availability Zone you put two subnets: one for the TGW attachment and a separate one that holds only the firewall endpoint. That firewall subnet must contain no other resources — Network Firewall cannot inspect traffic that originates in the same subnet as its own endpoint. You also deploy an endpoint per AZ for resilience: if you only put one in AZ-a, an AZ-a outage takes your inspection offline.

Now the part that trips everyone up: appliance mode. A stateful firewall must see both directions of a flow on the same endpoint. Without appliance mode, the TGW can hash the return traffic to a firewall endpoint in a different AZ — the firewall sees half a conversation, decides it's asymmetric, and drops it. You enable appliance mode on the inspection-VPC's TGW attachment so the TGW pins each flow to one endpoint for its whole life.

The "route-table dance" is just making the next hop be the firewall. In the inspection VPC, the TGW-attachment subnet's route table sends 0.0.0.0/0 to the firewall endpoint; the firewall subnet's route table then sends the inspected traffic onward (to a NAT gateway for egress, or back to the TGW for east-west). If ReceivedPackets on the firewall stays at zero, it's almost always a route table that doesn't actually point at the endpoint — not a rule problem. Compare this to a third-party NGFW appliance: with a vendor NGFW you run EC2 instances behind a Gateway Load Balancer and own the patching/scaling; with Network Firewall, AWS owns all of that — you only own the rules and routes.

③ Rule groups + egress control — stateless, stateful, Suricata & domains

A firewall does nothing until you give it a firewall policy, which bundles two kinds of rule groups. Stateless rule groups run first and look at each packet alone using the 5-tuple (source/destination IP, source/destination port, protocol). Their job is a quick triage: pass obviously-fine traffic, drop obvious junk, and — crucially — forward everything else to the stateful engine. If you forget to forward, the stateful rules never see the traffic.

Stateful rule groups are where the real inspection happens. They run on the Suricata engine and come in three flavours: a 5-tuple standard group, a domain list group (allow or deny by domain), and raw Suricata rule strings for full control. You also choose an evaluation order: strict order (recommended — rules run in the priority you set, and you declare default actions for non-matching packets) versus the older default action-order.

Here's the egress-control move that stops data exfiltration. A stateful domain list rule group lets you write an allow-list: only let traffic out to .amazonaws.com, your partner APIs, and your package mirrors — everything else is dropped. For HTTPS the firewall reads the SNI in the TLS handshake; for HTTP it reads the Host header. By default the domain rule group only inspects traffic from the VPC's own CIDR — to inspect other CIDRs (a centralized design) you must widen the HOME_NET variable. A freshly-shipped 2025 feature even lets domain rules use Reject and Alert actions, not just drop.

You don't have to write every attack signature yourself. AWS publishes managed threat-signature rule groups (botnet command-and-control domains, known malware signatures) that AWS keeps updated — you just add them to the policy. And every decision can be logged: Network Firewall writes FLOW logs (a record of every flow) and ALERT logs (only traffic that matched a drop/alert rule) to one of three destinations — an S3 bucket, a CloudWatch Logs group, or a Kinesis Data Firehose. Logging is what turns the firewall from a silent gate into evidence you can hunt through.

# A raw Suricata rule string in a stateful rule group (strict order).
# Drops any HTTPS to the bad SNI and writes an alert log line.
drop tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; \
  content:"data-collector.unknown-site.example"; \
  msg:"Blocked exfil to unknown domain"; sid:1000001; rev:1;)

# Same idea as a domain-list ALLOW (egress allow-list — deny everything else):
#   Type: Domain list  |  Action: Allow
#   Domains: .amazonaws.com, .flipkart-internal.example, .ubuntu.com

# CloudWatch ALERT log (JSON, trimmed) when the EC2 host tries the bad domain:
{"event_timestamp":"1749600000","event":{
  "src_ip":"10.20.10.5","dest_ip":"203.0.113.45","app_proto":"tls",
  "tls":{"sni":"data-collector.unknown-site.example"},
  "alert":{"action":"blocked","signature":"Blocked exfil to unknown domain","signature_id":1000001}}}

④ Putting it together — a leak-proof multi-tier VPC & cheat-sheet

Now we assemble everything into a secure multi-tier VPC. Three tiers, three subnet types: a public subnet (only the load balancer and NAT gateway live here), a private app subnet (your EC2/containers, no direct route to the internet gateway), and a data subnet (RDS/databases, the most locked-down, no internet path at all). App and data tiers reach the internet only outbound, via the NAT gateway — and that egress is forced through the Network Firewall first. There is no inbound path from the internet gateway to the app or data tiers.

Wrap it with telemetry: enable VPC Flow Logs on the VPC (to CloudWatch or S3) so you have a record of every accepted/rejected flow, and turn on the Network Firewall's own FLOW + ALERT logging. Now you have two complementary trails: Flow Logs say who talked to whom, and the firewall ALERT logs say what we blocked and why. Together they're what an incident responder actually needs at 2 a.m.

The worked example that ties it off: a "block exfil to unknown domain" egress policy. You create a stateful domain list ALLOW group naming only the handful of domains your app legitimately needs (your AWS service endpoints, your package mirror, your partner API), set the firewall policy's stateful default action to drop, and widen HOME_NET to cover every CIDR you inspect. Result: a compromised host can try to beacon out all it wants — anything not on the short allow-list is dropped and logged. That single pattern defeats the most common cloud-breach step: quiet data exfiltration to attacker infrastructure.

aws network-firewall create-rule-group \
  --rule-group-name egress-allowlist-prod --type STATEFUL --capacity 100 \
  --rule-group '{"RulesSource":{"RulesSourceList":{
      "Targets":[".amazonaws.com",".ubuntu.com",".flipkart-internal.example"],
      "TargetTypes":["TLS_SNI","HTTP_HOST"],"GeneratedRulesType":"ALLOWLIST"}}}'

aws network-firewall describe-firewall --firewall-name prod-inspection-fw \
  --query 'FirewallStatus.Status'

{
    "RuleGroupResponse": {
        "RuleGroupArn": "arn:aws:network-firewall:ap-south-1:123456789012:stateful-rulegroup/egress-allowlist-prod",
        "RuleGroupName": "egress-allowlist-prod",
        "Type": "STATEFUL",
        "Capacity": 100
    }
}
"READY"

For your certification path, this lesson maps onto the AWS Certified Security – Specialty (SCS-C02) blueprint — specifically Domain 3: Infrastructure Security (20%), the single largest scored domain, which is all about network segmentation, edge protection and secure VPC design. Knowing SG vs NACL vs Network Firewall, the inspection-VPC pattern, and egress domain filtering covers a real slice of it, and the FLOW/ALERT logging ties into Domain 2: Security Logging & Monitoring (18%). This is high-yield exam material, not trivia.