You must size an interior firewall for east-west campus traffic an intruder would have to cross - why is the internet link's bandwidth the wrong number?

## Why the instinct is wrong Everyone has a number for the internet link, because someone signs an invoice for it every month. It is therefore the number that gets reached for when finance asks how big the interior firewall needs to be. It is the wrong number for three separate reasons. **It is a purchased cap, not a demand measurement.** North-south throughput is limited by a circuit somebody chose. East-west traffic has never been limited by anything except switch capacity, so it reflects what the estate actually generates. **Its shape is different.** Internet traffic is many users doing small interactive things across a shaped pipe. Interior campus traffic includes backup streams, workstation image deployment, file-share copies, software distribution and virtualisation or storage flows - large, sustained, and clustered into windows. A device sized for the average of a business day falls over at 02:00 on the backup window, which is precisely when nobody is watching. **Bandwidth is rarely the binding constraint.** Interior workloads open enormous numbers of short-lived sessions: discovery, monitoring polls, file-share connections, agent check-ins. What exhausts an interior firewall first is usually **new connections per second** or the **concurrent session table**, not gigabits. A device comfortably inside its throughput rating can be dropping traffic because its session table is full - and an intruder scanning the range is itself a burst of thousands of new sessions. ## How to get a defensible number 1. **Draw the boundary first.** You are not filtering all east-west traffic; you are filtering traffic that crosses the boundary you intend to enforce. If a chatty application tier and its database land on the same side, that traffic never touches the device. 2. **Measure what would cross it.** Export flow records from the core over a full business cycle - a month covers month-end, patch cycles, backup windows and imaging days - and sum only the pairs that would be on opposite sides. Flow records give you five-tuple, byte and packet counts and timestamps, which is exactly what sizing needs, and no payload, which sizing does not need. 3. **Extract three numbers, not one:** peak bits per second across the boundary, peak new connections per second, and peak concurrent sessions. 4. **Derate the datasheet.** Published throughput is measured with a stated feature set and traffic mix. Enabling deeper inspection, logging every session, or decryption cuts it substantially - by a large factor, not a small percentage. 5. **Account for the hairpin.** On a single-link design each crossing flow traverses the device link twice, so the interface budget is double the flow budget. 6. **Size each redundant unit for the full load.** If a pair is active/standby, or active/active with a failover, the survivor carries everything. A pair sized for half the peak each is a pair that fails together. 7. **Add growth and lifetime.** The box is depreciated over several years, so it must still fit at the end of that period, not on the day it ships. ## What to say when the answer is expensive The honest position is that the number is set by the boundary you drew, so the boundary is the lever. If sizing comes back unaffordable, redraw it: move the two populations that generate most of the crossing traffic onto the same side, and the device shrinks. That is a design conversation, not a haggle, and it is the one worth having before anyone quotes hardware. ## The trap to avoid Do not offer a ratio of east-west to north-south as if it were a constant. It varies enormously between a campus, a data centre and a cloud estate, and quoting an invented multiple is how a sizing exercise loses its credibility. Say that east-west typically dominates in a campus, then say you would measure it.