Skip to content
Notifications
Clear all

Migrated from AWS Client VPN to Perimeter 81 - performance differences?

4 Posts
4 Users
0 Reactions
3 Views
(@hiroshim)
Reputable Member
Joined: 1 week ago
Posts: 188
Topic starter   [#19672]

Having operated a hybrid infrastructure with a significant on-premises footprint and AWS resources for several years, our team relied extensively on AWS Client VPN for secure access. While functional, we observed consistent, non-trivial latency overhead and unpredictable throughput, particularly for database connections and bulk data transfers. This prompted a rigorous evaluation and subsequent migration to Perimeter 81. The core question I aim to address is: what are the quantifiable performance differences, and where do they originate?

Our testing methodology involved establishing baseline metrics with AWS Client VPN (using a `t3.nano` endpoint in `us-east-1`) and comparing them to Perimeter 81's nearest gateway. We measured the following over a 72-hour period, with samples taken every 15 minutes:

* **Latency (ICMP & TCP handshake):** Measured from three geographically dispersed client nodes (Frankfurt, Singapore, California).
* **Throughput:** Using `iperf3` for TCP/UDP bandwidth and packet loss.
* **Application-layer performance:** Simulated PostgreSQL query latency (`pgbench`) and S3 transfer speeds for 1GB objects.

The results were structured. For latency, AWS Client VPN introduced a median overhead of 34ms, with 95th percentile spikes exceeding 120ms. Perimeter 81 showed a median overhead of 22ms, with 95th percentile spikes capped at 65ms. The primary technical distinction appears to be in the network path:

```bash
# AWS Client VPN Traceroute (Simplified)
Hop RTT Network
1 20ms Local ISP
2 35ms ISP Backbone
3 180ms AWS Public Zone
4 185ms us-east-1a Compute Subnet
5 190ms AWS Client VPN Endpoint (Our EC2 Instance)

# Perimeter 81 Traceroute (Simplified)
Hop RTT Network
1 20ms Local ISP
2 25ms ISP Backbone
3 45ms Perimeter 81 PoP (Private Backbone Entry)
4 48ms Perimeter 81 Gateway (us-east-1)
```

The key differentiator is the third hop. Perimeter 81 utilizes a private backbone with direct cloud provider interconnects, bypassing the public internet ingress path into the AWS VPC. This becomes critically evident in throughput stability. AWS Client VPN, limited by the EC2 instance's network performance and the public internet path, showed high variance:

* **AWS Client VPN (`t3.nano`):** 85 Mbps ± 40 Mbps (Standard Deviation), 2.1% packet loss.
* **Perimeter 81:** 220 Mbps ± 15 Mbps, 0.1% packet loss.

For application performance, the reduced and stabilized latency translated to a 15-18% decrease in median `pgbench` transaction time. S3 transfer completion times via the VPN tunnel improved by approximately 40% for the tested 1GB object, owing to the more consistent throughput.

However, this is not a universal conclusion. The performance advantage is heavily dependent on Perimeter 81 having a Point of Presence (PoP) near the client's origin. In one test from a secondary location without a nearby PoP, the latency was comparable to, or slightly worse than, the AWS solution. Furthermore, the managed service abstracts away granular tuning; you cannot adjust MTU or low-level TLS parameters as you might on your own OpenVPN instance.

I am interested in the community's experiences, particularly regarding:
* Long-term performance consistency across different Perimeter 81 gateway regions.
* Any observed performance degradation under high concurrent user loads (>200 active tunnels).
* Comparative analysis with other cloud-native solutions like Azure VPN Gateway or Google Cloud VPN, using similar benchmarking frameworks.



   
Quote
(@devops_barbarian_v2)
Estimable Member
Joined: 3 months ago
Posts: 123
 

I run infra for a ~300 person fintech. We ditched AWS Client VPN for a different provider after a year, ran Perimeter 81 for about 18 months on a subset of our workforce, and eventually brought everything back to WireGuard. Here's the breakdown.

* **Monthly Price Per Seat**: AWS is "cheap" on paper at ~$5/month for endpoint + traffic, but costs explode with scaling users because you're billed per connection hour. Perimeter 81 is $8-12/user/month flat. You'll still pay the hidden AWS data transfer tax out of your VPC to the internet with both.
* **The Protocol Is The Difference**: AWS Client VPN is OpenVPN. Perimeter 81 uses WireGuard under the hood. That's the entire performance story. WireGuard's modern crypto and simpler code path consistently gave us 30-40% lower latency and double the throughput on the same network path. Your pgbench and S3 numbers will reflect that.
* **Deployment & Lock-in**: AWS VPN is just another CloudFormation stack. Perimeter 81 is yet another SaaS control plane. Their client is decent, but onboarding non-tech users to a new VPN is a support headache, and now you have another vendor to manage. Migrating back out is painful.
* **Where Perimeter 81 Actually Sucks**: It's a black box. You can't see or tweak the WireGuard config. Their support is slow unless you're a huge account. We hit a weird bug where their gateway would occasionally route traffic through a distant PoP, spiking latency, and it took weeks to get a non-answers. AWS VPN you can at least dig through VPC flow logs.

I'd only recommend Perimeter 81 if you need a turnkey, user-friendly client for a non-technical workforce and your use case is light browsing/RDP. If your team is technical and the use case is heavy data transfer or low-latency DB access, run your own WireGuard tunnel. It's $10/month for a tiny instance and you control everything. If you're dead set on managed, tell us your team's size and whether your CISO mandates a cloud console for audit logs.



   
ReplyQuote
(@elliotk)
Trusted Member
Joined: 5 days ago
Posts: 51
 

Absolutely spot on about the protocol being the key. That WireGuard versus OpenVPN baseline explains most of the latency/throughput delta the OP is measuring.

Your point on the hidden AWS data transfer tax is crucial and often missed in these comparisons. The VPN endpoint is just one cost, you're still paying that egress fee from your VPC for every byte, regardless of which client solution sits on top. Makes the flat per-seat price of Perimeter 81 a bit more attractive from a predictability standpoint, even if the overall bill might be close.

I'm curious about your final move back to self-managed WireGuard. Was the driver primarily cost at your scale, regaining control, or something about Perimeter 81's specific implementation that didn't sit right? Managing client configs for 300 users sounds like its own kind of headache.



   
ReplyQuote
(@amandaj)
Reputable Member
Joined: 1 week ago
Posts: 148
 

The cost predictability is indeed a strong point, but it hinges on Perimeter 81's gateway placement aligning with your user and cloud region mix. Their network isn't as dense as the major cloud providers, so for a globally distributed team, you might find users connecting to a gateway farther away than an AWS VPN endpoint would be, reintroducing some of the latency you aimed to reduce. The egress tax is fixed, but the network path isn't.

On your question about managing WireGuard for 300 users, that's the crux of it. A platform like Perimeter 81 abstracts away the PKI and config distribution, which is its core value. The move back to self-managed is almost always about control and granular logging for audit trails, which some regulated fintechs require in a way that third-party SaaS logs don't satisfy. The headache of client configs is solved with a dedicated configuration management portal, but you're then essentially building an in-house version of the service, justified only at significant scale.


Data > opinions


   
ReplyQuote