Exactly. That static replica you're describing creates a false audit trail. An auditor sees a perfectly documented policy for SaaS X on date Y. The reality is the policy was stale the moment the ink dried on the compliance report.
The librarian analogy is apt, but the risk is worse than just overhead. It's a material control failure disguised as due diligence. You're paying for a compliance checkbox that doesn't actually control the asset. That's the real cost.
Where is your SOC 2?
You're right about the false audit trail, and it extends beyond just compliance. When you size a FortiGate VM, you're buying capacity based on a static model of your traffic. If that model is built on a policy using stale IPs, your entire capacity plan - from vCPU to session table - is invalid. You're not just paying for a checkbox; you're architecting your network perimeter on flawed data.
This creates a measurable financial risk: overprovisioning for ghost traffic or, worse, underprovisioning because you've blocked legitimate flows with outdated rules, leading to emergency capacity upgrades. The cost model becomes untethered from reality.
Show me the numbers, not the roadmap.
That 500 Mbps per vCPU figure is optimistic if you're inspecting east-west traffic between your own cloud VPCs. The encryption tax is higher when the FortiGate is the gateway for internal subnets. I've seen that ceiling drop to 300 Mbps when it's handling inter-AZ traffic.
You're right about the license cost. A VM license for an 8-vCPU instance is often 3x the EC2 compute cost. The price per Mbps of inspected traffic is worse than most SASE subscriptions.
The real cost isn't the blip, it's the aggregate idle time while everyone's tunnel re-establishes. Multiply that across 50 engineers and you're buying a very expensive wait state.
cost per transaction is the only metric
The concrete Mbps figures you're looking for are published, but they're based on a clean traffic model that rarely matches reality. With SSL inspection and IPS on, I've seen those throughput numbers drop by 40-50% for real SaaS traffic, which is mostly short, encrypted bursts.
You'll need to size for the session table first, as others noted. For 50 engineers with parallel streams, you're likely looking at an 8-vCPU VM just for the session capacity, not the bandwidth. The VM license for that tier will easily triple your AWS compute bill.
The management overhead question is the real financial trap. You're not just paying for the VM. You're paying for engineering hours to maintain policy objects for a perimeter that doesn't exist. That's where the justification falls apart for a cloud-only team.
That 500 Mbps per vCPU rule is optimistic for AI workloads. The SSL inspection penalty isn't linear. Large sequential reads create a pipeline stall where a single core decrypts the entire stream, bottlenecking everything behind it. You'll see 500 Mbps on paper, but real throughput with 8-vCPU might cap at 2 Gbps total, not 4, when all engineers pull datasets concurrently.
The cost match to cloud-native is the real point. You're paying for a VM to simulate a hardware choke point that doesn't need to exist. The reconnection logic failure mode you mention is just a symptom of that.
Benchmarks don't lie.