A volumetric flood saturates the path to a public search tier — which layer absorbs that, and why can the workload's own rule set not?

## The question is capacity, not policy There are two different problems that both look like "unwanted traffic", and boundary filtering solves only one of them. - **Reachability**: which sources may open a connection to which workloads. This is what a rule set expresses, and it is expressed precisely. - **Volume**: how much traffic arrives at all. This is a capacity property of the path, and no rule expresses it. A flood that saturates the path is the second problem. By the time a packet is tested against any of your rules it has already traversed the link and already consumed the entry point's capacity. The verdict costs something too — every dropped packet is a decision made — so a boundary under a flood is spending its own capacity to refuse traffic it cannot stop arriving. Adding rules makes the refusals more precise and does nothing about the arrival rate. This is the part candidates most often get backwards: **dropping is work**. "We just deny it at the firewall" describes an action taken at the wrong end of the saturated path. ## Where absorption has to happen Absorption requires somewhere with **more capacity than the attack**. On a cloud platform that place is the provider's shared entry layer in front of your resources — the pooled front door that terminates connections for a large number of tenants and is therefore sized against an aggregate far larger than any one tenant's link. Three properties follow: 1. It is **upstream of your boundary**, so absorbed traffic never reaches the path you own or the rules you wrote. 2. It is **shared**, which is why the capacity exists at all: no single tenant would provision it. 3. It is **coarse** — it works on volume and traffic shape, not on your application's notion of a legitimate caller. This is also why a managed, pooled entry point behaves differently under a flood from a public address pinned to one machine: the pooled layer has somewhere to absorb, the single address has only the machine behind it. ## What each layer is actually good for | Layer | Absorbs volume? | Decides reachability? | Fails under a flood by | |---|---|---|---| | Provider's shared entry capacity upstream | yes, that is its purpose | coarsely, on shape and rate | saturating a capacity sized for all tenants | | Stateless filter on the subnet | no — already past the path | yes, by range and port | spending its own budget on drops | | Stateful rule set on the workload | no, and it is the worst place to try | yes, precisely, by group | exhausting the connection table | The last cell is worth stating on its own: statefulness makes the workload layer *more* fragile under volume, not less, because every flow it accepts consumes a table entry. A flood of connection attempts that your rules happily allow — because they come from a source you permit — fills that table. This is the shape where a rule set has genuinely failed, and it failed by doing exactly what it was told. ## The traffic that only your rules can stop None of this makes boundary filtering less important; it makes its job specific. Upstream absorption cannot tell your legitimate caller from an unwanted one, because both look like well-formed traffic at a modest rate. Only your rules know that the store should be reachable from the search tier and from nothing else. So the division is: - **Volume you cannot serve** — absorbed upstream, by capacity. - **Callers who should not be there at all** — refused at your boundary, by rules. - **Callers who may connect but should not do that** — refused by authorization, which is a different mechanism entirely and sits behind both. A design that relies on rules for the first, or on absorption for the second, has put each control where it cannot work. ## What to say when asked what you would do Be honest about the sequence. Confirm the path is saturated rather than the workload being slow — a saturated path shows loss and rising latency at the boundary while the workload's own utilisation may look unremarkable. Then move the answer upstream: sit the public entry behind the platform's pooled, absorbing front door rather than exposing an address that lands on your own capacity; keep your rule sets narrow so that anything that does arrive is refused by the cheapest layer that can refuse it; and make the workload layer's exposure small, because a stateful table is a resource an attacker can consume without ever being allowed to do anything useful.