AWS Network Firewall in front of an app server: the 2026 setup we'd actually use.

Putting AWS Network Firewall (ANFW) at the VPC edge in front of an internet-facing application server is still the right pattern in 2026. Our 2023 case study covered the basics: ingress rules, egress rules, allow-listing, deep-packet inspection, and CloudWatch / CloudTrail for visibility. Three years on, the bones are unchanged, but the defaults and the surrounding context have moved enough that a rewrite is honest.

What the original got right

• 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.

What we’d change for 2026

1. Stateful rule groups by default

In the 2023 setup we leaned heavily on stateless 5-tuple rule groups for performance reasons. Today, 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 is no longer enough to justify 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 now 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 the original article underweighted: the application server, compromised, attempting to exfiltrate over HTTPS to an attacker-controlled host. Our 2023 article said “filter outgoing IPs and ports.” In 2026, we additionally:

• 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

The 2023 article said “monitor traffic with CloudWatch.” Three years of running that pattern: dashboards nobody reads. In 2026 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 (2026)

                ┌──────────────────────────────────────────────┐
                │ 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

What we cut from the original

• The recommendation that “every scenario is unique” — it is, but the default posture should not change between scenarios. State the defaults; deviate explicitly.
• The framing of ANFW as “your tool of choice.” It’s not the only one. 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.

What carries over unchanged

The instinct. 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.

— wGrow studio · migrated from Team-Notes #86