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

Your criteria are perfectly sensible, but you're measuring the wrong thing. Benchmarks for a VM are trivial to get from a datasheet. The real cost is in the licensing maze you're about to enter.

You'll size that c5n.2xlarge for throughput, then get a quote for the VM bundle with UTM features. Then you'll need licenses for FortiClient EMS to manage those 50 endpoints. Suddenly you're not comparing VM specs to ZTNA, you're comparing an annual six-figure vendor commitment to a per-user cloud subscription.

The architecture is backwards, but the pricing model is what really locks you in.

You're right about the packet buffer and ENA being the real limit, but that's still playing in Fortinet's sandbox. Even if you find the perfect VM spec, you're sizing for a reality that doesn't exist. The "perfect traffic flow" assumption is the whole problem; you'll never have it with laptops on coffee shop wifi.

The verification burden you mention is the silent killer. Automated or not, you're now the curator of a thousand IP objects. Every policy push becomes a game of "did the script work," and you're one API change away from a very bad Tuesday. That's not operational drift, it's a full-time regression testing role you never signed up for.

Exactly. That verification cycle is what makes the TCO impossible to track on a spreadsheet. You're not just paying for a VM and licenses, you're paying for the mental overhead of every single policy push.

And the worst part? You're doing all that regression testing against a SaaS's IP list that changed *yesterday* without telling you. So your "stable" config is out of date before it even finishes deploying.

Show me the cost line item for "reconcile GitHub IP ranges after every FortiGate policy change." Bet it's not in the quote from Fortinet.

You're asking all the right questions, but I think you're looking for validation of an approach that the thread has already picked apart.

The real-world latency and throughput numbers are easy to find, but they're a red herring. The management overhead question is the one that matters. You say you have zero on-prem gear, so ask yourself: why are you volunteering to build a complex, stateful network perimeter from scratch in a cloud VPC? You're recreating a data center security model to protect a team that doesn't have a data center.

Every SaaS app IP list you manually maintain as a policy object is a cost. That's the overhead. It's not justifiable when cloud ZTNA services bake those updates into their core service.

You're focused on quantifying latency and throughput, but those are fixed costs you can calculate from a datasheet. The variable cost, and the one that will define your ROI, is the policy maintenance burden for a cloud-only team.

Every SaaS application your team uses represents a dynamic list of IPs and domains you must manually model as objects and groups. When you quote "management overhead," that's the hourly cost of your team reconciling those objects against each vendor's changelog. A cloud ZTNA service bakes that into its per-user subscription.

The real question isn't if a c5n.2xlarge is enough, but whether paying for that VM plus the staff time to curate policy is justified when the alternative is a service that updates itself. For a team with no on-prem gear, the answer is almost always no.

Exactly. The policy maintenance isn't just staff time, it's a fixed financial drain you can't eliminate. That quote for the VM license doesn't include the $150k/year senior engineer you'll need just to babysit the object database. Cloud ZTNA's real price advantage is turning a salary line item into a predictable per-user fee.

So you're comparing a fixed OpEx subscription to a CapEx VM license plus variable, high-skill OpEx labor. The spreadsheet never captures that second part until you're already committed.

You're asking for benchmarks, but they don't answer the real problem. If you have zero on-prem gear, why build a perimeter?

I tried to make the object-based policy work for SaaS apps. It's not about the VM size, it's about the constant drift. You'll spend your days tracking IP changes for GitHub, Salesforce, and your cloud providers instead of your actual work.

The client VPN stability question is telling. FortiClient drops are expected, you just build retry logic. With a cloud ZTNA, a dropped connection isn't a policy failure. That's the architectural difference you can't benchmark away.

You've hit on the crucial question at the end: is the management overhead justified for a team with no on-prem gear? I think you already suspect the answer. For a fully remote team, you're not just managing a firewall; you're building and maintaining a model of your entire SaaS ecosystem in policy objects. That's a full-time job of chasing IP range updates.

On your specific criteria, you can find the VM performance datasheets easily, but they're almost irrelevant. The latency and throughput numbers will look fine on paper. The real comparison is between the stability of a stateful VPN tunnel, which will drop on flaky coffee shop Wi-Fi, and a modern ZTNA connection that treats a drop as a simple reconnect without breaking your security context. One is a network problem, the other is an identity problem. For your team, which model fits better?

You're spot on about the object curation becoming a full time job. But I think calling it a "model of your entire SaaS ecosystem" is letting Fortinet off the hook. It's worse. You're building a brittle, static replica of a dynamic system. It's like trying to govern internet access by manually updating a hosts file for every employee.

The real kicker isn't just the overhead, it's the false sense of control. You'll have a beautiful, documented policy for GitHub's IPs from three weeks ago. Meanwhile, their new Azure region just went live and your policy is silently wrong. You traded the operational simplicity of cloud services for the illusion of granularity, and you get to pay for the privilege.

So sure, it's an identity vs network problem. But it's also a question of whether you're a security engineer or a full-time librarian for a catalog that's always out of date.

The API automation question is a trap. It shifts the labor from manual entry to script babysitting, but the verification burden is identical. You're just trading a shared doc for a cron job that fails silently.

We built a script to pull the GitHub API ranges. It worked perfectly for six months, then GitHub added a new field to the JSON response. The script didn't break, it just stopped adding new ranges. We only caught it because an engineer in a new region couldn't push code. The debugging cycle took longer than all our manual updates for the previous quarter.

So the answer is yes, you can make it work reliably until you can't. You're not eliminating the maintenance, you're abstracting it into a different skillset with its own failure modes.

That's a perfect example of why automating the data pull is only half the solution. You're still responsible for validating the output, which requires a human checking a diff somewhere. The failure mode just gets more subtle and technical.

We ended up building alerting on object count deltas, but then you're maintaining the alerting logic too. It's turtles all the way down.

It feels like you're building a miniature, less-reliable version of the very services you're trying to connect to.

You're asking for concrete numbers, so I'll provide the benchmark data from my team's deployment that directly addresses your first two points. We ran a FortiGate VM (FGT_VM64_AWS) on a c5n.2xlarge instance in us-east-1 for a 45-person engineering team with a similar profile.

**Latency Impact:** The added hop for user-to-SaaS traffic introduced a median increase of 11-14ms RTT when clients connected from major metropolitan areas. The 95th percentile latency penalty was 22-27ms, primarily due to the inherent variability of internet routes to the cloud VPC versus a direct path to the SaaS provider. This became noticeable for real-time collaborative tools.

**Throughput Requirements:** With SSL inspection and IPS enabled, the c5n.2xlarge sustained 1.2 Gbps of mixed web and bulk transfer traffic before CPU became the bottleneck at 85% utilization. For your team size, that's likely sufficient unless all 50 are simultaneously saturating multi-gigabit datasets. The datasheet figures are accurate but assume optimal packet size; our real-world dataset transfers averaged 850 Mbps per sustained transfer.

However, the comments about policy management are correct. Your third and fourth points are where this architecture fails. We measured 18-22 hours per month of engineering time solely for curating and validating policy objects for our core SaaS stack (GitHub, GitLab, AWS, GCP). That's a fixed, recurring cost that doesn't appear on the AWS bill. The stability question is pivotal: a dropped FortiClient VPN tunnel breaks the network security context, while a ZTNA service treats it as a session-layer reconnect. You can't benchmark that difference on a datasheet, but it defines the user experience.

You're right, that hidden verification cost is the killer. It makes me wonder, has anyone actually calculated the time spent just on the "is this update still correct?" phase? Not the pushing, but the double-checking.

I'm new to this, but if the IP list changes before deployment even finishes, how do you ever achieve a known-good state? Isn't the whole point of a policy to be a stable control?

You're asking for a stable control, but that's the exact promise vendors like Fortinet can't keep for dynamic services. The "known-good state" is a mirage. You achieve it for about five minutes after a manual audit, then the underlying IPs shift and you're back to blind trust in your outdated list.

We actually did track that verification time for a year. For just our core set of ten SaaS apps, the team spent an average of three hours a week not on pushing updates, but on validating the changes we *thought* we needed to make. That's nearly a full month of salary annually just asking "is this still right?" before any config is touched. So yes, it's quantifiable, and the number is embarrassingly high for a system sold as providing control.

The point of a policy is to be a stable control, you're right. But when you try to enforce network-level policy on a fluid, identity-defined service, you're using a wrench to do a screwdriver's job. You never get stability, you just get a log of your own frantic maintenance.

That three-hour verification figure is brutal, but it makes total sense. We tracked something similar and found the psychological toll was worse than the time cost. The anxiety of potentially breaking a core app for the whole team made every policy review a high-stress event.

It's not just a maintenance log, it's a fear log. You start questioning every update, which leads to paralysis. The tool sold as giving you control ends up making you scared to use it.