Sizing methodology

Why a WAF is not sized like a firewall

A firewall forwards packets, so it is sized on throughput. A WAF terminates the connection and parses every request and response, so it is sized on layer-7 requests per second and on new TLS handshakes per second, with throughput and the connection table as secondary limits. The headline figure on a datasheet is measured with no security policy applied; with a production policy the usable rate is a fraction of it.

That is why the catalogue in this tool carries a separate WAF request rate and WAF throughput per model, and why those are the numbers every candidate is measured against.

What each vendor sizes on

Step 1 · Day-one request rate

A measured peak always wins. The engine takes the highest figure the form can produce, because a WAF has to survive the worst of them, not the average:

The busy-hour rate per user comes from the application profile, so a JSON API is not sized as though it were a page-heavy intranet:

Step 2 · Day-one throughput

If a higher peak throughput was measured and entered, that figure is used instead.

Step 3 · New TLS handshakes per second

This is the figure that sinks most WAF designs. Handshake capacity runs out long before throughput does, and it is the one number nobody measures.

The rating used for the comparison is the one that matches the certificate in use: RSA 2048 or ECDSA P-256. On the same platform ECDSA is roughly twice the handshake rate, which is often cheaper than moving up a model.

Step 4 · Inspection cost

Vendor ratings are published with a standard policy. Anything heavier has to be paid for in platform size, so each capability adds a documented cost to the request-rate requirement:

Handshake capacity is crypto work rather than policy work, so the inspection factor is not applied to the TLS figure.

Step 5 · Insertion mode

Step 6 · Growth and design headroom

The platform is sized for the last year of its life, not the first, and to run at no more than 100% - headroom of its rating even then. The headroom is what absorbs an attack, a failover and a policy that grows as applications are onboarded.

Step 7 · High availability

An active/active pair is deliberately sized at 100% per unit, not 50%. Sizing a pair at half the load each is the most common WAF sizing error: it works until the day one unit is lost, which is exactly the day the load matters. A cluster is sized so that the loss of one node still leaves enough capacity.

Step 8 · Choosing the model

A model qualifies only if it clears every one of these:

• WAF request rate at or above the required figure
• WAF throughput at or above the required figure
• TLS handshake rate, at the key type in use, at or above the required figure
• Bulk TLS throughput at or above the encrypted share of the traffic (throughput × encrypted % × 2 if the WAF re-encrypts to the back end)
• Connection table large enough
• Rated for at least the number of protected applications
• Supports the insertion mode chosen
• Positioned for the place in the estate chosen
• Matches the form-factor preference

The smallest qualifying model is recommended, so the tool never oversells, and every rejected model keeps the list of reasons it failed. The recommendation can be overridden with any model in the range: an undersized choice is kept and flagged with the utilisation above 100%, never silently corrected.

Scoring a model against the requirement

Any model can be measured against the figures above, whether the engine picked it or you did. Each dimension gets a coverage percentage - what the platform provides against what the design needs, capped at 100% - and the fit is the weakest of them:

It is deliberately not an average. A platform that covers the throughput twice over but only 40% of the TLS handshake rate does not fit 70% - it fails, and averaging would bury the one number that sinks the design. Exceeding a requirement never raises the fit above 100%; it shows up as headroom instead, which is what the utilisation figure reports.

A platform that cannot be used at all - it does not support the insertion mode, or it is a cloud service in an on-premises design - scores 0% however much capacity it has. One that is merely the wrong shape, such as a virtual instance when hardware was asked for, keeps its capacity score and is labelled wrong shape, because that number still means something if the preference is revisited.

What the tool does not do

• It does not price anything. The bill of materials is the shape of the order; term, support tier, discount level and existing entitlement all change the commercial outcome.
• It does not replace the datasheet. Performance figures are indicative values held for relative sizing between models, last reviewed 2026-09.
• It does not size the policy-tuning effort, which on a real WAF deployment is usually the larger part of the work.