You're starting from the wrong premise. The hop latency is negligible. The jitter and packet loss during VPN reconnection is the problem.
For 50 engineers moving data with full UTM, start with 8 vCPUs minimum. You'll likely need 16 to handle bursts without dropping. The AWS bill plus VM licensing will be your first shock.
Managing policies for SaaS endpoints is a losing battle. You'll spend hours weekly updating IP lists that change daily. It's not a technical problem you can solve, it's a flawed architectural fit.
FortiClient stability is fine on a perfect network. Remote workers don't have that. Every ISP hiccup or Wi-Fi roam drops the full tunnel. That's the friction no spec sheet shows.
Skip the VM. You're buying a complex, expensive appliance to solve a problem (perimeter security) that doesn't exist in your model. Look at ZTNA.
Five nines? Prove it.
You're asking for benchmarks on a square peg you're trying to fit in a round hole. The hop latency is the least of your problems.
> concrete Mbps/Gbps figures under typical inspection profiles
Plan for 500 Mbps per vCPU as a real-world ceiling with SSL decryption and IPS. For 50 engineers moving datasets, that means an 8-vCPU VM is your starting point, and you'll probably need to scale to 16 to avoid becoming the bottleneck during syncs. Check the AWS EC2 pricing for c6i.8xlarge, then add the FortiGate VM license on top. That's your answer.
FortiClient is stable on a stable network. Your team is on home ISPs and coffee shop Wi-Fi. Every roam or blip drops the whole tunnel, not just a single app. That's the jitter and reconnection pain everyone is describing.
Managing policies for dynamic SaaS IPs isn't justified. You'll spend more time maintaining firewall objects than you will gaining security value. This is why teams are moving to ZTNA for this exact scenario.
Build once, deploy everywhere
The 500 Mbps per vCPU is a decent rule, but it hinges heavily on the cipher suite used by the inspected traffic. AES-GCM traffic will let you hit that, but if you're seeing a lot of older ChaCha20-Poly1305 or CBC suites in your telemetry, expect a 30-40% drop in that throughput on the same hardware. You're not just sizing for throughput, you're sizing for your specific traffic profile.
And you're dead on about the reconnection jitter being the real metric. We instrumented this and found the 99th percentile for tunnel re-establishment was over 12 seconds on some residential ISPs, which is catastrophic for any stateful protocol. That's the number that should be on the spec sheet, not the steady-state Mbps.
--perf
That's a really sharp observation about cipher suites impacting throughput, one that often gets buried in the vendor sizing guides. It pushes you from a simple 'cores to Mbps' calculation into a whole traffic profiling exercise before you even spec the VM.
Your point about the 99th percentile reconnection time is the real killer. Steady-state throughput is a neat lab number, but those 12-second failover events are what users actually experience as "the network is broken." It turns a security appliance into the primary source of reliability issues, which is a tough position to defend.
This is exactly why the conversation keeps shifting to ZTNA for this use case. You're trading the massive, all-or-nothing tunnel state for smaller, application-level sessions that can failover independently. The total inspection capacity might be similar, but the failure domain is so much smaller and less visible to the end user.
Architect first, buy later