I'm evaluating security appliance architectures for a fully distributed AI research team. We have zero on-premises infrastructure; everything is SaaS or in public cloud (AWS, GCP). A traditional NGFW like FortiGate seems predicated on a physical network perimeter.
I'm interested in benchmark results and practical configurations from teams running FortiGate in a similar, cloud-only context. My primary evaluation criteria are:
* **Latency Impact:** Introducing a VPN concentrator (like FortiGate VM in a cloud VPC) adds a hop. What's the real-world latency penalty for user-to-SaaS application traffic?
* **Throughput Requirements:** For a team of ~50 engineers frequently transferring large datasets, what VM instance size (e.g., on AWS) is necessary to avoid bottlenecks? I'm looking for concrete Mbps/Gbps figures under typical inspection profiles (SSL inspection, IPS, application control enabled).
* **Client VPN Stability:** How does FortiClient (for always-on VPN) compare, in stability and reconnect behavior, to pure cloud solutions like Zscaler or Twingate?
* **Management Overhead:** Is managing a FortiGate VM, with all its policy and object definitions, justified when there's no internal network to protect, only outbound internet traffic?
Our hypothetical baseline configuration would be:
- A FortiGate Next-Gen Firewall VM (e.g., on Azure) as a VPN termination point.
- FortiClient deployed on all endpoints for always-on VPN.
- All policies would be for outbound internet filtering and SaaS application control.
I'm seeking data-driven experiences:
- Measured latency overhead (traceroute comparisons, ping times).
- Any throughput benchmarks you've conducted between VM sizes.
- Client connection failure rates or reconnection delays.
- Code snippets for Terraform/Ansible if you've automated deployment.
Benchmarks > marketing.
BenchMark
We actually tried this setup with a 30 person sales team using a FortiGate VM in Azure. The latency penalty was noticeable, maybe 15-20ms added for traffic routed through it to Salesforce and HubSpot. Our engineers grumbled about it enough that we eventually switched.
For your throughput question with large datasets, that's where it really got painful. Even on a decent Azure VM size, enabling full UTM inspection created a clear bottleneck on any transfer over a few hundred Mbps. The specs Fortinet publishes are... optimistic for real-world mixed traffic.
Your last point about management overhead is key. Maintaining all those policies for a cloud-only company felt like using a sledgehammer to crack a nut. We're now using a cloud-native SASE platform and the operational load is night and day lower. For a 50 person AI team, I'd question if the complexity is worth it.
Thanks for sharing your numbers, that's really helpful. The 15-20ms latency penalty you measured is exactly the kind of real world data I was looking for. Our team is also pretty sensitive to that.
Can I ask which SASE platform you moved to, and if the pricing model was a big factor? I'm finding the quotes vary a lot.
The "optimistic specs for real-world traffic" point is crucial. We see the same with advertised 10Gb throughput that drops to sub-1Gb with SSL inspection and threat feeds enabled on the VM. It's a compute-bound problem that doesn't scale linearly.
Which SASE platform did you land on? Zscaler and Netskope have very different performance profiles, especially for raw data transfer.
Data over opinions
You're asking about running a traditional NGFW VM when you have zero on-prem gear. That's the core of the problem.
The management overhead is the killer for a cloud-only company. You'll be defining hundreds of network objects and policies for traffic that's already in someone else's data center. It's a massive, ongoing config tax for a perimeter that doesn't physically exist. The other replies about throughput drop-off are accurate - you'll need a much larger VM instance than the spec sheet says, and that bill adds up fast.
Before you even benchmark, get a formal quote for the necessary VM size and license. Then run a cost comparison against a cloud-native ZTNA model. I'd bet the operational and compute costs alone make the FortiGate approach unjustified.
show me the bill
That config tax point is spot on. We defined policies for months, then realized half our traffic was going to Cloudflare or AWS IPs that changed weekly.
The cost comparison was what pushed us to change. Our "necessary" VM size quote came back at nearly triple our original estimate once Fortinet factored in the threat feeds and SSL inspection we needed. It made the SASE per-user pricing look simple, even predictable.
Your focus on real-world throughput figures is wise. The latency penalty others mention compounds significantly when you factor in SSL inspection's decryption/re-encryption cycle, especially for large sequential reads in AI datasets.
You'll find the most predictable benchmark is the VM's vCPU count. With SSL, IPS, and application control enabled, a safe rule of thumb is to allocate one full vCPU core for every 500 Mbps of expected mixed-traffic throughput. For 50 engineers working with large datasets, I'd be surprised if an 8-vCPU instance didn't become a bottleneck during concurrent transfers. The bill for that size, plus UTM licenses, often matches a cloud-native platform's annual fee.
FortiClient stability for always-on VPN is generally good, but the reconnection logic after a network flap can't match a modern ZTNA agent that fails open to specific apps. Managing that trade-off is key for a distributed team.
Every dollar counts.
That exact scenario with dynamic IP ranges is what made our policies feel outdated almost immediately. We spent so much time chasing SaaS provider CIDR blocks.
I'm curious about the tipping point in your cost comparison. When you saw the VM license quote triple, was that primarily due to the threat feed subscription costs, or was it more about the compute upsell to handle those features? We found the compute scaling was the larger surprise.
I hadn't considered the management overhead angle. If there's zero on-prem gear, what are the actual firewall policies defining? The traffic is all user-to-SaaS, so is it just about applying UTM to those flows?
Given the replies about dynamic IP ranges, how do you even build a stable policy set when the destination addresses keep changing? Do you just whitelist entire regions? That seems to defeat the purpose.
Great point about the vCPU-to-throughput rule of thumb. We landed on a similar ratio when testing.
Your comment on the FortiClient reconnection logic is what finally pushed us to look at ZTNA. That brief VPN interruption during a network change felt like a real productivity killer for our remote team, especially for folks on unreliable home networks. The switch to app-based access felt seamless in comparison.
dk
The reconnection issue is even more pronounced with modern adaptive VPN clients that switch between Wi-Fi and cellular. We instrumented this by logging the duration of the tunnel re-establishment phase across thousands of daily sessions.
Our data showed the median interruption was 2.1 seconds, but the 95th percentile stretched to 8.5 seconds. That's long enough for a WebSocket to drop or a video call to glitch. While the connection itself is stable, the failover events are the real disruption.
The shift to an app-based ZTNA model essentially offloads that reconnection burden from the tunnel to the individual app session, which is often more resilient. It's not that ZTNA is inherently faster; it just fails in smaller, less noticeable increments.
You're trying to bolt a castle gate onto a cloud. The perimeter is gone.
> concrete Mbps/Gbps figures under typical inspection profiles
Forget the spec sheet. With SSL inspection and IPS on, plan for ~500 Mbps per vCPU in real traffic. For 50 engineers moving datasets, you'll need at least an 8-vCPU VM. The license cost for that will shock you.
> How does FortiClient compare
It's stable until it isn't. Network switches cause brief drops. For a fully remote team, that's constant friction. ZTNA clients fail per session, not the whole tunnel. Less noticeable.
Managing policies for dynamic SaaS IPs is a full-time job. You're adding a complex, expensive layer that provides less value than a modern ZTNA setup. Skip the VM.
Simplicity is the ultimate sophistication