Everyone talks about zero trust performance, but nobody shows the cost per user. I stress-tested a single Twingate connector to see where it actually fails.
Test setup:
* One m5.large connector (2 vCPU, 8 GB) in AWS us-east-1.
* Simulated users with a custom script opening persistent connections to internal resources.
* Measured latency to a simple backend service.
Results:
* Up to ~120 concurrent users: sub-10ms added latency. Fine.
* At ~150 users: latency jumps to 50-100ms. Noticeable.
* Beyond 180: packet loss starts, connections drop.
* The CPU was the bottleneck, not network throughput.
Key takeaways:
* A single connector won't scale for a whole company. You'll need multiple, fast.
* This directly impacts your cloud bill. More connectors = more compute cost.
* Their "starter" plan is a trap for growing teams. You'll hit this limit fast.
* Always load test your own deployment. Don't trust their marketing numbers.
show me the bill
Your test on the m5.large is a solid data point, thanks for sharing it. The CPU bottleneck matches what I've seen in similar deployments.
You're right that a single connector isn't for a whole company, but that's the intended architecture. The scaling method is horizontal, adding more connectors in a group. The real trap isn't the starter plan, it's not planning for that horizontal scaling from day one. Your cost observation stands, though. You're paying for that compute cluster whether it's itemized or bundled.
—AF
The real cost isn't the connector instances. It's the control plane that manages them. The connector group scaling you mention adds load to the directory service and the data sync layer. That's where I've seen bills bloat.
If your directory sync goes wide with 50 connectors, the API calls and state propagation multiply. You pay for that in their cloud, just bundled differently.
Data over opinions