Anything beyond the inspected part is never checked: an attacker can pad a request with harmless filler and place the payload behind the limit. Larger requests are only inspected if extra rules are set up manually.

* The rules only see the first part of the body; a payload placed after the limit passes unchecked. *

Inspecting a request costs time and memory, so cloud WAFs cap how much of a request body their rules read. With the default rule sets of AWS and Google cited at 8 KB, a large form submission, an upload or a big JSON body is only partially checked. Unless someone knows about the limit and adds rules for oversized requests (block them, or extend the inspection), the WAF gives a false sense of coverage for exactly the requests an attacker can make large on purpose.

The exact numbers move with the products: AWS WAF still inspects 8 KB of the body behind an Application Load Balancer, but 16 KB by default (configurable up to 64 KB) for CloudFront and API Gateway; Google Cloud Armor now inspects up to 64 kB. The lesson stays the same: know your WAF's limits, because they are part of your attack surface.

Go deeper:

• AWS WAF — Oversize web request components — the per-service body inspection limits and how to handle oversized requests.
• Google Cloud Armor — Security policy overview — includes the request body inspection limit among the limitations.

Internal side: clients may reach the DMZ only for administration (client -> dmz: allow ssh), and dmz <-> internal: deny all. Internet side: each public service gets exactly its own protocol — internet <-> dns: allow dns, internet <-> mailex: allow email, internet -> webserver: allow http(s) — and nothing else.

* The outer firewall opens one protocol per public server; the inner firewall lets nothing from the DMZ into the LAN. *

The two rule sets express two different trust decisions:

• Outer firewall (internet ↔ DMZ): the internet may talk to the DMZ servers, but only in the one protocol each server exists to offer. The web server is reachable with HTTP(S), the mail exchanger with email (SMTP), the DNS server with DNS. Note the direction: the web server only receives (->), while DNS and email work in both directions (<->), because the mail exchanger also sends mail out and the DNS server also queries other name servers.
• Inner firewall (DMZ ↔ internal LAN): the DMZ is treated as untrusted. Nothing in it may open connections into the LAN, and nothing in the LAN talks to it except administrators connecting in (SSH or similar) to maintain the servers.

The key consequence: a server that is compromised from the internet ends up in a zone from which it cannot reach the internal systems.

Go deeper:

• NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy — firewall architectures including DMZs, and how to write the policy for them.
• Network segmentation — Wikipedia — why splitting a network into zones limits the damage of a breach.