Size and License Your F5 Platform

Under-sizing an F5 platform shows up as TLS handshake latency, dropped connections and an emergency purchase; over-sizing shows up as capital and support fees spent on capacity you never use. We size every deployment against measured traffic – not data-sheet maximums – and turn the result into a bill of materials and a licensing model you can defend.

What we measure

• Layer 4 and layer 7 throughput, connections per second and concurrent connections per application, with growth applied for each year of the platform’s expected life.
• TLS transactions per second by cipher and key type, including TLS 1.3 and ECDSA, which decide whether hardware crypto offload or a larger Virtual Edition is the right answer.
• Module overhead: Advanced WAF, APM per-request policies, AFM and SSL Orchestrator each consume CPU that a pure LTM sizing ignores.
• High-availability topology – active/standby, active/active or F5OS tenants spread across chassis – and the headroom a single failure leaves behind.

Platforms we size

• rSeries appliances running F5OS, with BIG-IP tenants sized by vCPU and memory instead of vCMP guests.
• VELOS chassis for consolidation: partitions, blades and tenant placement for multi-tenant and service-provider estates.
• Virtual Edition on VMware, KVM, AWS, Azure and Google Cloud, matching instance types, SR-IOV or cloud-native networking and licence tiers to the workload.
• BIG-IP v21 tenants on any of the above, with the extra control-plane memory the 64-bit release needs already in the sizing.

Licensing without regret

We map the sizing to the right commercial model – perpetual, the Flexible Consumption Program or cloud marketplace – and to the add-on modules you will actually enable, so you are not paying for Advanced WAF on a device that only ever load-balances, or discovering at cut-over that a module was never licensed.