Refreshing a Bank's i2600 Pair with a Cloud-First Mandate
A regional bank runs a three-year-old pair of BIG-IP i2600 appliances carrying LTM, APM, and ASM. Peak traffic is 12 Gbps and average is 4 Gbps; peak SSL TPS is 400. The CIO wants 30 percent of applications in Azure within 18 months while keeping core banking on-premises, and has a fixed three-year budget of $350,000. Security requires FIPS-validated cryptography for anything in PCI scope. The reseller has proposed two BIG-IP VE Standard instances in an Azure availability set, running on D8s_v3, licensed BYOL by reusing the i2600 licenses, with the same support tier. The network team notes that the Azure landing zone is hub-and-spoke and that the VM sizes the bank will approve top out well below the required throughput. The account is up for renewal in 60 days.
1. Evaluate the reseller's proposal. Which assumptions are wrong, and what is the consequence for the customer?
Read the worked answer
The proposal fails on four independent points, and a single wrong assumption is enough to break the design.
- BYOL does not mean reusing hardware licenses. BIG-IP VE BYOL requires VE-specific license entitlements; the i2600 licenses are tied to the appliance. Either new VE licenses are purchased or the existing estate is converted to a credit-based model. The customer would otherwise receive unlicensed VEs.
- Throughput is bounded by the Azure instance size and platform limits, not by the F5 license. A pair of D8s_v3 cannot deliver the 12 Gbps peak; the design must be sized against F5's published VE instance matrix and Azure's per-VM network limits, then re-checked against the 4 Gbps average versus the 12 Gbps peak.
- FIPS is unresolved. Hardware FIPS validation does not automatically follow the workload into Azure. If the VE platform does not meet the PCI-scope requirement, those applications must stay on hardware with the appropriate cryptographic module, which changes the refresh shape entirely.
- An availability set is not a device HA pair. Two VEs in one region still need a mechanism to move the service address or to sit behind a load balancer.
The consequence: the quote is not a like-for-like replacement, and the customer is being asked to sign a renewal on an architecture that cannot meet its own security requirement.
2. How would you size and license the solution so that the 12 Gbps peak and the FIPS constraint are both addressed within a $350,000 envelope?
Read the worked answer
Separate the estate by requirement rather than by application count.
FIPS-scoped workloads stay on hardware. Size an iSeries or rSeries pair for the PCI-scope peak, not for the whole 12 Gbps. Hardware also gives predictable SSL TPS for the 400-TPS figure.
Cloud-eligible workloads go to VE. Size VEs for their own throughput, not the aggregate. Because peak is three times average, do not buy for 12 Gbps of VE capacity across the board - use a credit pool (an ELA or a multi-year VE subscription with a defined Gbps credit allowance) so capacity can be moved between regions and environments as the 30 percent migration progresses.
Licensing shape. Utility/PAYG for burst and for proof-of-concept; a multi-year VE credit pool for the committed footprint; preserve APM and ASM entitlements explicitly, because they are licensed separately from LTM and are easy to lose in a conversion.
Budget check. Build a three-year TCO that includes VE licensing, Azure compute and egress, support, and the hardware refresh - and test it against $350,000 before proposing anything. If it does not fit, the honest recommendation is a phased migration rather than a discount.
3. The customer asks for a verbal assurance that the migration will be seamless. How do you respond without overcommitting?
Read the worked answer
Decline the framing and replace it with a scoped, testable commitment.
Say plainly that a lift-and-shift of a 12 Gbps inspected estate into Azure is not seamless, and explain why: throughput is instance-bound, FIPS scope has to be re-established, and the HA mechanism changes in the cloud. Then offer what can be committed to: a 90-day proof of concept on three named applications, with success criteria agreed in advance - measured throughput, SSL handshake rate, WAF false-positive rate, and failover time. Put the criteria in writing and make the migration decision contingent on them.
This protects both sides. The customer gets evidence instead of adjectives, and the account is not built on a promise that the first peak-traffic Monday will disprove. It also creates a natural reason to discuss the renewal separately from the migration, which is useful when the two are only 60 days apart.