Finance wants the firewall SKU with half the session capacity. How do you defend the larger one?

## The mistake that loses this argument The losing move is to quote the datasheet. "We need the four-million-session model" is a number with no meaning to anyone outside the network team, and it invites the obvious counter: the other one is cheaper and also has a big number on it. You have to translate before you ask. ## What the number actually bounds, and who spends it The capacity is a count of **concurrent conversations**, and it is usually the model or licence tier that sets it. The part worth saying out loud is that this budget is not spent by your architecture; it is spent by whoever sends packets to services you deliberately published. A policy that permits any source to reach the front door — which is what publishing a service means — names an unbounded population, and each member of it claims a slot with one packet. You do not get to cap that with a rule, because the rule is the front door. So the honest sentence to a budget holder is: *this number is the only thing standing between an ordinary increase in arrivals and a refusal to accept new business, and we do not control arrivals.* ## State the failure mode in their language This is where the argument is won, because the failure mode is genuinely nasty and genuinely explicable without jargon. A firewall at its ceiling does not get slow. It keeps every conversation that already has a slot running perfectly and refuses to start new ones. What the business sees is: - existing sessions fine, dashboards green, bandwidth graphs unremarkable; - new sign-ins, new checkouts and new API clients failing; - an hour spent looking at the application, because that is what the symptom looks like. A budget holder can price that. "Revenue that depends on new connections stops, and it takes us longer than it should to find out why" is a sentence they can act on; "we would exceed our concurrent session limit" is not. ## Bring the arithmetic and bring the evidence Come with four numbers, not one: 1. **Measured peak session-creation rate** — connections per second at the busiest hour, not bandwidth. The two are unrelated ceilings and people conflate them constantly. 2. **Mean entry lifetime**, so the concurrency figure is derived rather than asserted. 3. **Failover headroom.** In a high-availability pair, one member may carry the whole estate. A table sized exactly at the observed peak has nothing left on the day you need it most. 4. **Growth to the end of the refresh horizon.** You are buying capacity for the life of the box, typically several years, and it is far cheaper to buy it once than to replace a platform mid-cycle. Bring a year of utilisation history with the peaks marked, and be specific about what caused past jumps. The most instructive ones are usually not attacks at all: a mobile client release that opened connections and abandoned them without closing, a partner integration that retried aggressively, a marketing event. Those are the events that make the case, precisely because nobody malicious was involved and nobody could have been blocked. ## Offer the cheaper options rather than refusing Credibility is the currency here, and it is spent by asking for the top model "to be safe". Put the alternatives on the table yourself: - **Shorten idle timeouts.** Free in capital terms; costs application teams keepalive work you do not control, and silently breaks long-idle flows if you do it unilaterally. - **Stop tracking a bulk flow class** between fixed endpoints. Recovers entries; gives up the invited-traffic guarantee for that class, which somebody must accept in writing. - **Move the boundary.** A stateful control facing an unbounded internet population is the expensive case. The same control between two internal zones faces a population you own and can count, so it can be a much smaller box. Sometimes the right answer is a cheaper, coarser control at the edge and the stateful spend placed inside where sizing is a known quantity. - **Buy the smaller model deliberately**, with a documented ceiling, an alert well below it, a named owner and a pre-agreed purchase trigger. ## Then let them decide, and make the decision visible If the smaller box is defensible on the evidence, say so. If it is not, say what you cannot promise: you cannot bound the arrival rate, so the residual risk has a trigger outside your control, and it needs an owner with a name attached — ideally the person accountable for the revenue that stops when new connections are refused. Write the acceptance down. That is the whole principal move. The technical answer is a sizing calculation any competent engineer can do. The judgment is translating a capacity ceiling into a business failure mode, offering the honest cheaper paths, and ensuring that a decision to under-buy is recorded as a decision somebody made rather than a surprise you absorb alone at three in the morning.