Firewall sizing: how to size a firewall properly

Why sizing goes wrong

Most undersized firewalls were sized correctly against the wrong number.

A vendor publishes several throughput figures per model, each measured under its own conditions. The largest of them is measured with large fixed-size packets and no content inspection. That test answers a real question about forwarding capacity, and it is not the question a deployment with inspection enabled is asking.

The gap between those two figures is large on every platform. It is a property of the work rather than a property of the product. Forwarding a packet requires a lookup and a decision. Inspecting a stream requires the appliance to reassemble it, identify the application, evaluate it against signature sets, and often decrypt and scan the content inside it. Each step consumes processing and memory bandwidth that forwarding does not.

Two further errors compound it. Sizing is frequently done against the internet circuit speed, which ignores internal traffic crossing the firewall between segments. And it is frequently done against today's peak, which leaves nothing for growth, for services not yet enabled, or for the encrypted share of traffic continuing to rise.

The method below removes all three. It costs an afternoon of measurement and it produces an answer that can be defended line by line in front of a customer.

The relationship between forwarding and inspection cost follows from the architecture and is disclosed openly by every major vendor in the footnotes to their datasheets. For what each published figure measures on Fortinet and Palo Alto specifically, see the performance comparison. We publish no throughput values of our own, because we run no lab.

The eleven inputs

Sizing is a requirement built from measurements, compared against a printed figure.

These are the eleven values that determine the answer. Complete the worksheet from the customer's environment before opening any vendor's datasheet, so the requirement is built independently of the models being considered.

A worksheet rather than a result. Every value comes from the customer's own environment, which is the only place a defensible sizing input exists. The set of inputs is our own operating practice rather than a vendor methodology, and it is deliberately longer than the input list most vendor calculators ask for.

Two of these inputs are VPN inputs, and they are separate limits from throughput. Tunnel count, concurrent remote-access users and aggregate crypto load each have their own ceiling on the datasheet, and the remote access page covers what drives each one on either platform.

Getting the numbers

Every input above exists on the firewall the customer is already running.

Exact commands and menu paths differ by platform, so what follows names the mechanism rather than the syntax. On any current enterprise firewall, all four mechanisms are available.

The device's own historical graphs

Throughput, session count and CPU history are retained on the appliance or in its management platform. Retention is usually short, which is the reason to start the measurement period before the sizing conversation rather than during it. Thirty days is the minimum useful window, because it captures a month-end and at least four weekly cycles.

SNMP polling into whatever the MSP already monitors

Interface counters, session table occupancy and CPU are all exposed over SNMP on every major platform. Polling them into an existing monitoring system produces a longer history than the appliance keeps, and it produces the 95th percentile figure directly rather than by inspection of a graph.

Flow export

NetFlow, IPFIX or the vendor's equivalent gives the traffic composition rather than the volume. This is where the encrypted share, the internal-to-internal share and the application mix come from, and those three shape the requirement more than the headline volume does.

The session table itself

Concurrent sessions and new sessions per second are both readable from the live session table and both are commonly missed. Sample them at the busiest minute of the busiest day rather than at an average, because the limit that matters is a peak limit.

Building the requirement

The requirement is four numbers, not one.

Take the worksheet and convert it in this order. The order matters, because each step feeds the next.

1. Total inspected throughput. Add peak internet throughput to inspected internal throughput. This is the volume the appliance has to process, rather than the volume it has to forward.
2. Apply the encrypted share. The portion of that total which will be decrypted carries a materially higher cost per byte than the portion that will not. Where the customer intends to decrypt, size against a vendor figure measured with decryption enabled rather than adjusting the plain figure by a guess.
3. Add the growth projection. Apply the customer's own year-on-year change across the full term of the purchase, rather than across one year.
4. Apply headroom. Itemized in the next section rather than applied as a single round percentage.

That produces the throughput requirement. Carry the other three limits alongside it unchanged: concurrent sessions, new sessions per second, and VPN load in both tunnel count and aggregate throughput.

Now open the datasheets. Find the smallest model on each vendor's line that clears all four requirements, reading the figure whose footnote matches the services the customer will enable. A model that clears throughput and fails on session rate is not a candidate, and this is the check most frequently skipped.

Headroom, itemized

Headroom is three separate allowances that are usually collapsed into one percentage.

Collapsing them is what makes headroom feel arbitrary and makes it the first thing a customer challenges. Itemizing them makes each one defensible on its own.

The three-part breakdown is our own practice rather than a vendor methodology. The values belong to the customer and vary widely, so we publish none. What transfers between engagements is the discipline of estimating the three separately.

Two rules keep the allowance honest.

Apply the same standard to every vendor under consideration. An allowance applied generously to one quote and sparingly to another produces a comparison that reflects the allowance rather than the appliances.

State the allowance to the customer as a line in the recommendation. A customer who understands that a tier of headroom is being bought deliberately is a customer who will not treat the next tier down as a saving. An early appliance replacement costs considerably more than selecting one tier up at purchase, and that comparison belongs in the same conversation as the quote.

Size the survivor

In a high-availability pair, the capacity that matters belongs to one unit.

An active-passive pair runs all traffic through one member. The standby carries no load until a failure, at which point it carries everything. The requirement for the pair is therefore the requirement for a single appliance, and the second unit buys availability rather than capacity.

An active-active design distributes load across members while both are healthy. The arithmetic that follows is the reason this design is misused. If two members each run at sixty percent of capacity, the failure of either one presents the survivor with a hundred and twenty percent of its capacity. The estate is adequate right up to the moment redundancy is called upon, and inadequate at exactly that moment.

The rule is the same in both designs. Size a single appliance to carry the full requirement, then buy two of them. Anything less means the redundancy exists on the purchase order rather than in the failure.

Failover behaviour deserves the same scrutiny as failover capacity, and the two are separate questions. Which sessions survive a failover, and what happens to inspection state during one, are covered in the high availability page.

Sizing for segmentation

Internal segmentation changes the requirement more than any other design decision.

A perimeter firewall processes traffic between the customer's network and the internet. That volume is bounded by the circuit. A firewall enforcing policy between internal segments processes traffic that is bounded by the LAN, which is frequently an order of magnitude larger and carries no circuit cost to constrain it.

Three inputs shift when segmentation is in scope.

• Throughput rises with the number of segment boundaries crossed. A single flow between two internal hosts may traverse the firewall once. A flow that crosses three boundaries traverses it three times, and each traversal is inspected.
• Session counts rise faster than throughput. Internal traffic is often composed of many short connections between application tiers, so the session table fills before the interfaces do.
• Backup and replication windows dominate the peak. These are internal flows, they are large, and they frequently run at night when nobody is watching the graph. Measure across a full backup cycle before sizing.

Where a customer intends to segment progressively rather than at once, size for the intended end state rather than the first phase. A segmentation program that outgrows its firewall in phase two stalls, and a stalled segmentation program is a security outcome as well as a capacity one.

Virtual and cloud firewalls

Virtual firewalls introduce a second capacity ceiling that hardware does not have.

A hardware appliance has one limit, set by the hardware. A virtual firewall has two. The host provides one, in allocated vCPU, memory and network interface capability. The license provides the other, because most vendors tier virtual firewall licensing by capacity and the tier caps throughput independently of how much hardware sits underneath it.

Four consequences follow, and each one has produced a surprise on an estate we have inherited.

• Adding vCPU may change nothing. Where the license tier is the binding constraint, more host resource has no effect on throughput. Confirm which ceiling is actually in force before scaling the virtual machine.
• The license tier is a purchasing decision with a capacity consequence. It belongs in the sizing worksheet as an input rather than being discovered afterwards.
• Host contention is invisible from inside the firewall. A virtual firewall sharing a host with a noisy neighbour reports its own health as normal while delivering less than its allocation. Size with the hypervisor's own metrics in view.
• Cloud instance type constrains network performance separately. In a public cloud, the instance family caps aggregate network bandwidth and packets per second, and that cap may bind before either the license or the vCPU allocation does.

That virtual firewall licensing is tiered by capacity, and that the tier bounds throughput independently of allocated host resource, is standard across the major vendors and stated in their virtual appliance documentation. Specific tier names, capacity bands and instance requirements change often enough that we name no values here. Read the current virtual appliance datasheet for the platform being quoted. Checked 12 August 2026.

Interrogating a sizing tool

Every vendor and most resellers offer a sizing tool, and their output is a starting point rather than an answer.

These tools are built by people who understand the platform, and they are also built by a party with an interest in the outcome. A tool that recommends too small an appliance loses a renewal. A tool that recommends too large an appliance wins a bigger order. Neither failure is deliberate, and the incentive runs in one direction.

Six questions turn a tool output into something you can put your name to.

1. Which throughput figure does this recommendation clear? Ask for the named figure and its footnote, rather than a number.
2. Does it assume decryption? If the input form never asked about encrypted traffic, the answer is no.
3. What traffic profile does it assume per user? Any tool that takes a user count as its primary input has assumed a profile on the customer's behalf.
4. Does it check session count and session rate, or only throughput? Ask which model it would have recommended on those limits alone.
5. Does it size the pair or the survivor? Confirm the recommendation holds with one unit carrying everything.
6. What growth allowance is included, and over what term? A tool sized to today's load has answered a question about today.

Send the same six questions to every vendor in the comparison, in writing. The answers make two recommendations comparable in a way the model numbers do not, and a reseller's willingness to answer them offers useful information about the support you can expect later.