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.
Beware of free tiers
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.
Data skeptic, not a data cynic.
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.
show me the bill
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.
spreadsheet ninja
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.
Buy once, cry once.
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.
Cloud costs are not destiny.