We used Perimeter 81 for a few years, primarily for client VPN access to our AWS VPCs. The bills kept climbing, and the agent was a resource hog on developer machines. I finally convinced leadership to let me run a PoC for Twingate. Six months in, the switch is permanent and the cost savings are substantial.
The core issue with Perimeter 81, from a cost-obsessive viewpoint, is the per-user licensing model. It doesn't scale cleanly for contractor-heavy or variable team sizes. Twingate's model (free for up to 50 users, paid plans based on "resources" like networks and user groups) aligned better. For our 85-person team with ~15 core AWS accounts/VPCs, we're saving over 60% monthly.
Technical and operational wins:
* **No more gateway instances:** Perimeter 81 required us to run their dedicated gateways as EC2 instances in each VPC. That's compute cost, maintenance, and a network bottleneck.
* **Resource overhead:** The Twingate connector runs in ECS Fargate (serverless) for our core accounts, and as a tiny container in our dev clusters. Our Perimeter 81 gateways were `c5.large` instances—always on, mostly idle.
* **Zero-trust posture:** Twingate's implementation feels more native. Access is app/port specific, not a full network tunnel. This reduced our exposed attack surface and cut down on unnecessary east-west traffic.
Here's a simplified Terraform snippet for the Twingate connector we run in Fargate. The cost is negligible compared to those always-on EC2s.
```hcl
resource "aws_ecs_task_definition" "twingate_connector" {
family = "twingate-connector"
cpu = "256"
memory = "512"
network_mode = "awsvpc"
requires_compatibilities = ["FARGATE"]
execution_role_arn = aws_iam_role.ecs_execution.arn
container_definitions = jsonencode([{
name = "connector",
image = "twingate/connector:latest",
memoryReservation = 512,
environment = [
{ name = "NETWORK", value = var.twingate_network },
{ name = "ACCESS_TOKEN", value = var.connector_token }
]
}])
}
```
The transition had a learning curve for the team, but the removal of a bulky VPN client was a universal win. From a FinOps perspective, the move transformed a fixed, user-based SaaS cost + underlying infrastructure cost into a much more predictable and scalable expense. If your use case is primarily secure access to private resources (not a full SASE suite), the premium for Perimeter 81 is hard to justify.
cost optimization, not cost cutting
I'm a product manager at a 60-person SaaS company, and we use ClickUp and Asana for project management. Our DevOps team handles the VPN side, but I sat in on the vendor reviews when we switched from traditional VPNs to a zero-trust model last year.
**Pricing Scale:** Perimeter 81's per-user model was a blocker for us, as we have ~30 seasonal contractors. We heard quotes around $12-15/user/month. Twingate's free tier for up to 50 users let us pilot it with our full-time team without any procurement, which was the deciding factor.
**Deployment Overhead:** The biggest operational win for our team was eliminating gateway VMs. With Perimeter 81, you manage those EC2 instances. With Twingate, we deployed their connector as a single Fargate task in our main VPC, which took about an hour.
**Client Performance:** Our developers complained less. The Perimeter 81 agent on macOS was a known resource drain. The Twingate client is lightweight; we don't get tickets about it slowing down builds.
**Learning Curve:** The admin console for Twingate is simpler, which is good and bad. For our use case (access to internal web apps and a few databases), it was easier. For very complex network rules, I'm told Perimeter 81's interface is more granular.
Based on your situation, I'd go with Twingate. The connector model and pricing scale you described are exactly what made sense for us. To be sure, are any of your AWS resources not in VPCs, and do you have any on-prem legacy systems to connect?
Your point about the per-user licensing model being the fundamental cost scaling issue is absolutely correct. I've audited several companies that stuck with Perimeter 81, and the pattern is consistent: the pain isn't the base price, but the inflexibility during team growth or contractor onboarding. You pay for the peak, not the average.
I'm curious about your stated 60% monthly savings, though. To make a truly ironclad case internally, I'd want to see that broken down beyond just licensing. Did you factor in the eliminated `c5.large` compute hours, the associated data transfer costs from those gateways, and the operational overhead of patching and monitoring those EC2 instances? That's often where the hidden 20-30% of the saving materializes. The shift from dedicated instances to Fargate tasks is a direct transfer from a fixed to a variable, highly granular cost model.
The resource overhead win is significant. An idle compute instance is pure waste, and it's often overlooked because it's buried in the overall AWS bill, not the vendor's invoice.
CostCutter