AWS Network Firewall in front of an app server: the setup we'd actually use.
By Scott Li ·
Default posture for putting AWS Network Firewall at the VPC edge in front of a public-facing app server, plus the agent-era addition.
Putting AWS Network Firewall (ANFW) at the VPC edge in front of an internet-facing application server is the right default pattern. The basics — ingress rules, egress rules, allow-listing, deep-packet inspection, and CloudWatch / CloudTrail for visibility — are well-trodden ground. The defaults and the surrounding context are where most posture mistakes happen.
The non-negotiables
- Putting ANFW at both ingress and egress, not only at ingress. Most teams still skip egress.
- Allow-listing IPs and ports as the starting posture, with everything else denied.
- Continuous monitoring via CloudWatch + CloudTrail rather than a one-time configuration audit.
If you do nothing else, do those three. Most public app-server breaches we get called in on after the fact have at least one of the three missing.
Defaults we ship today
1. Stateful rule groups by default
A stateless 5-tuple-only posture is brittle. With ANFW’s stateful inspection performance where it is, we default to stateful rule groups for application traffic and reserve stateless for explicit deny-fast lanes (e.g. shut down a region’s IPs in one rule). The cost difference no longer justifies the added blast radius of a stateless misconfiguration.
2. Suricata rules, not just JSON allow-lists
Hand-maintained JSON allow-lists for the ingress posture turn into spaghetti within a year. ANFW consumes Suricata rule format directly. We write our deny rules as Suricata signatures (community + Emerging Threats + a small in-house set) and let those run alongside the allow-list. Maintenance is less painful, and we get prior-art protections we wouldn’t think to write ourselves.
3. Egress is where the leak is
Deep packet inspection on outbound traffic catches a category of misconfiguration most ingress-focused postures underweight: the application server, compromised, attempting to exfiltrate over HTTPS to an attacker-controlled host. Beyond filtering outgoing IPs and ports we:
- Use TLS SNI inspection (ANFW supports it) to allow only known-good hostnames outbound.
- Restrict the application server to a named egress domain list maintained alongside its IaC.
- Treat any egress to an unrecognized SNI as a potential incident, not a rule miss.
4. The agent-era addition
If your app server runs an LLM-driven agent that makes outbound API calls (to Anthropic, OpenAI, or your own model gateway), that traffic must be scoped explicitly. In our active engagements:
- Agent egress goes to a separate egress route through ANFW, with its own allow-list.
- Domains outside that allow-list are dropped at the firewall, not at the SDK.
- SNI inspection on this lane is non-optional. A jailbroken agent should not be able to reach a domain you didn’t approve.
This is the cheapest control to add early. It is the most expensive one to retrofit after a prompt-injection incident.
5. CloudWatch alarms wired to people, not dashboards
“Monitor traffic with CloudWatch” is true and useless. Dashboards nobody reads are the failure mode. We wire the count of denied flows from the application server into a CloudWatch alarm tied to PagerDuty, with a single human-readable runbook. A spike in denied egress is, more often than not, the first signal of a compromise.
Architecture sketch
┌──────────────────────────────────────────────┐
│ Internet │
└──────────────────────────────────────────────┘
│
┌──────────▼──────────┐
│ AWS Network Firewall │ ◀── ingress posture
│ - Suricata rule │ (stateful + stateless)
│ - allow-list │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Public subnet (ALB) │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ App-tier subnet │
│ - app server │
│ - agent process │
└────┬─────────────┬───┘
│ │
egress ─► │ │ ─► agent egress
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ ANFW egress │ │ ANFW egress │
│ (app SNI list) │ │ (agent SNI list)│
└──────────────────┘ └──────────────────┘
│ │
▼ ▼
approved API hosts approved model APIs
Where the alternatives fit
ANFW isn’t the only viable choice. Cloudflare Magic Transit, Akamai, and the cheaper-but-narrower Security Group + WAF combo are all viable for smaller estates. Pick on cost and operational fit, not allegiance.
The instinct doesn’t move: ANFW at both ingress and egress, allow-list as starting posture, monitoring wired to a human, and the assumption that an internet-facing app server will be probed — usually within hours of going live, in our experience.
— Scott Li, wGrow