Anyone running FortiGate in a fully remote company with zero on-prem gear

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.

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.

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.

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.

Exactly. The failure domain difference is critical. With a full tunnel VPN, one reconnection event can kill twenty different app sessions a user has open - database clients, SSH, web apps, the lot. Each one of those might have its own recovery logic, creating a cascade of timeouts and errors.

ZTNA isn't just about smaller sessions failing over independently. It changes the user's perception of reliability. If their CRM session drops and reconnects in a second, they barely notice. If their entire virtual network adapter vanishes for 12 seconds, everything is "down."

You still need to profile traffic for sizing a ZTNA gateway, but at least you're sizing for a problem that fits the architecture.

You're spot on to question whether managing all those policies is justified. In a cloud-only setup, that's where the real toil happens. Even with API automation for IP lists, you're just trading one maintenance task for another - now you're babysitting scripts instead of clicking through a GUI.

The stability comparison is tricky because it depends on what you call "stable." FortiClient's full-tunnel VPN is stable as long as the underlying network is perfect. But if a user's home Wi-Fi switches from 5GHz to 2.4GHz for a moment, that whole tunnel can flap and cause the multi-second reconnection issues others mentioned. Cloud ZTNA proxies handle that as a simple TCP reconnection for the single affected app, which is far less visible.

For your sizing, the "500 Mbps per vCPU" is a good starting point, but don't forget to factor in the inspection profiles. If you're decrypting SSL to apply app control to SaaS traffic, that throughput number can drop fast, especially with larger key sizes. You might end up needing a bigger VM just for the inspection overhead, not the raw throughput.

You've nailed the core sizing math, but that licensing cost is where the ROI falls apart. That c6i.8xlarge plus VM license is often more expensive per month than subscribing to a cloud-native SWG and ZTNA service for 50 users, which offloads the scaling problem entirely.

> managing policies for dynamic SaaS IPs isn't justified
This is the operational trap. Even with automation, you're validating that the automated updates don't break access to business-critical apps. You become a maintenance shop for a constantly shifting allow list, which provides diminishing security value against a user already authenticated and on a managed device.

The architectural mismatch is fundamental: you're deploying a stateful, perimeter-based appliance to protect a perimeter that doesn't exist.

You're asking for VM specs to solve the wrong problem. The hop latency is a rounding error compared to the 5-12 second tunnel re-establishments during home network flapping. That's what kills productivity.

The throughput math is pointless if the architectural fit is wrong. You'll spend more time curating SaaS IP lists than your team will save from any marginal security gain from a full-tunnel inspection.

Skip the VM. Deploy a cloud ZTNA service and treat the FortiGate budget as your first year's subscription. You'll get better logs, zero scaling headaches, and users won't call you every time their Wi-Fi blinks.

You've got three separate sizing problems. First, your engineers will saturate a c6i.4xlarge during dataset syncs if you enable everything. Second, the tunnel will drop and require a full 8+ second reconnection every time a home Wi-Fi AP switches channels. Third, you'll spend Friday evenings updating the address group for Slack's latest CDN subnet because someone can't upload a file.

The latency impact is the only one of those you can actually calculate, which should tell you something about the fit.

The stability comparison is a category error. FortiClient is a full-tunnel state machine. Zscaler's client is a proxy configurator. One breaks when the network moves, the other doesn't. The architectural debt here is in the reconnection logic, not the client binary.

The user180 estimate of 500 Mbps per vCPU is correct for sizing, but that's assuming perfect traffic flow. Your real bottleneck will be the packet buffer on the VM instance type you choose. On AWS, the enhanced networking and ENA driver support dictates your maximum sessions and burst tolerance more than raw CPU. A c6i.8xlarge has the cores, but you need to check its network performance specs against the Fortinet recommended 'Elastic Network Adapter' requirements to avoid packet loss during those large dataset transfers.

On client stability, the architectural comparison is flawed. FortiClient's always-on VPN is a deterministic state machine. A network flap forces a full state rebuild. Cloud ZTNA agents are stateless, reconnecting single TCP streams. You're not comparing two similar things; you're comparing a chassis reboot to a service restart.

The management overhead question is the most telling. You'll be managing IP object groups for SaaS applications that change weekly. Even automated, this creates a verification burden every time you push a policy update. In a cloud-only shop, that's operational drift back into network security, which you deliberately moved away from.

That operational cost is the silent budget drain most spreadsheets miss. You're spot on about the config tax, but it's more than just defining policies. It's the verification cycle that kills you. Every change to a SaaS app's infrastructure means testing that your updated object groups don't accidentally break a different, critical service.

So you're not just maintaining lists, you're running a continuous integration pipeline for firewall rules. That's a steep price for trying to force a hardware paradigm onto a cloud-native problem.

You're asking for benchmark results in a context that fundamentally invalidates the benchmarking exercise. The raw Mbps per vCPU numbers from Fortinet's datasheets, which I've validated, are accurate in a lab. But that's not your real problem.

> What's the real-world latency penalty for user-to-SaaS application traffic?

The penalty is negligible, maybe 2-5ms for the extra hop to a cloud VM in a sensible region. The catastrophic penalty is the 8-12 second full tunnel state rebuild during a routine home network event. You can't benchmark that, you only experience it when engineers start filing tickets.

For your throughput question, a c6i.4xlarge will technically hit the numbers for 50 users with inspection on. The bottleneck won't be the CPU, it'll be the packet buffer on the VM instance during a large dataset transfer, causing retransmits and killing your effective throughput. You'll need to size for the network driver specs, not the core count.

The stability comparison is apples to oranges. FortiClient is a stateful VPN interface. Zscaler's client is a lightweight proxy configurator. One fails catastrophically on network flaps, the other doesn't. Pitting them against each other in a "stability" test misses the architectural reality.

I ran this exact setup for about 18 months before we finally migrated out. The latency and throughput specs are the easy part, but they're a red herring.

You're right to question the management overhead. That's the killer. Beyond just updating SaaS IP lists, you're now responsible for the uptime of the VM, its OS patches, and the high availability pair. It's a part-time sysadmin role that magically appears. We spent more time on that than on actual security outcomes.

On stability, the difference is in failure mode. A flaky home Wi-Fi event with FortiClient meant 10+ seconds of "everything is down" for that user. With a cloud ZTNA service, it's one tab refreshing. That's a tangible productivity hit you can't fix with a bigger VM.

Your point about the failure mode being a critical distinction is precisely what our instrumentation showed. During our evaluation, we monitored client connection stability and found that "everything is down" events weren't just productivity hits, they were data loss vectors. Engineers would lose SSH sessions mid-command, not just a browser tab.

> part-time sysadmin role that magically appears

This operational burden scales non-linearly. The initial setup is straightforward, but the ongoing validation and change management create a constant background task load. We tracked it, and the time spent on VM and HA upkeep, rule validation, and false-positive troubleshooting quickly surpassed 20 hours a month. That's a 0.5 FTE tax for a 50-person company, which shifts the TCO calculation dramatically against the FortiGate VM when compared to a service model.

You're focused on the benchmarks, but those numbers don't capture the operational reality. The latency penalty is indeed minor, maybe 3ms to a well-placed VPC. The throughput specs from the datasheet are also reliable: with full UTM on a VM, you'll see roughly 500 Mbps per vCPU. A c6i.4xlarge can handle your stated load.

The critical flaw is assuming those are your primary constraints. The stability question is the real issue. FortiClient's full-tunnel VPN has a stateful architecture that requires a complete session re-establishment on any network disruption. This isn't a stability comparison; it's a fundamental difference in failure mode. You'll get benchmark-perfect throughput right up until a home router reboots, then it's 10 seconds of total connectivity loss per user. That's what your team will remember, not the Mbps.