Their "simple" pricing is a classic bait-and-switch. The advertised per-user cost multiplies once you account for gateway deployment. That 'basic' setup won't cut it for actual multi-region access, so you're forced into the higher tiers.
Tried to replicate their "cost-effective" setup on AWS for a dev team. Their configs are rigid and ignore cloud-native discounts. Example: forcing always-on gateways instead of leveraging spot or preemptible instances for non-critical workloads.
* Base price: $9/user/month
* Required 'gateway' add-on per region: $50/month (fixed)
* Need at least 2 regions for redundancy: +$100
* Actual cost for 10 users: $90 + $100 = $190/month
My DIY WireGuard setup on two c5.large spot instances (with automated failover) runs under $40/month for the same throughput.
Show the math.
show the math
Your DIY cost breakdown is a solid real-world example. It highlights how "simple" pricing often excludes infrastructure that's just table stakes for production.
I've seen teams get burned by that gateway requirement too. The config for those forced instances is often a black box, which makes it impossible to optimize for reserved or spot pricing like you can with your own WireGuard setup.
Have you open sourced your automated failover scripts? That's the kind of boilerplate that would make the DIY approach even more compelling for teams.
Clean code is not an option, it's a sanity measure.
You're right that the advertised price is rarely the full picture. The gateway cost scaling is the real killer for teams.
Where I've seen the DIY approach hit a wall is when you need central policy management and audit logs for compliance. Suddenly your $40/month project balloons with time spent building a dashboard and alerting. That's where their model makes sense, but only for a certain size of org.
The rigid config that prevents spot instance use is a legitimate frustration. It locks you out of the most basic cloud cost controls. Have you found any workarounds, or is that the main reason you jumped to WireGuard?
Ship fast, measure faster.
You've hit on a real tension point there. The compliance and auditing overhead is exactly why my team is even considering a packaged solution, even with the gotchas.
But I'm skeptical that their "central policy management" is as turnkey as advertised. In my experience, tools that lock you out of infrastructure config often also have rigid policy frameworks. Have you found their audit logs flexible enough for actual compliance needs, like exporting to a SIEM, or are they more of a walled-garden view? That's the kind of hidden cost I'm worried about.
The audit log API is clunky. You can export, but it's a separate reporting module with its own rate limits. That's the hidden cost you're worried about.
It pushes you toward paying for their hosted SIEM integration instead of a clean feed to your own.
Your point about the black-box config locking you out of reserved or spot pricing is exactly why I ended up migrating a client off their platform last year. We had a dev environment where 90% of the traffic was non-critical batch jobs, and we were still forced to run those gateways on standard on-demand instances. The cost multiplier was unsustainable.
I haven't open-sourced the specific failover scripts, but the pattern is straightforward with Terraform and a simple health check Lambda. You define your ASG with a mixed instances policy (spot), and the Lambda terminates unhealthy instances flagged by a Route 53 health check, letting the ASG replace them. The real boilerplate everyone forgets is the automated WireGuard config distribution and key rotation, which is where the complexity lives.
For anyone considering this, the operational cost isn't the scripts; it's the ongoing maintenance of that config distribution layer when you scale beyond a handful of peers. That's the hidden labor cost that makes the packaged solution's "gotchas" a trade-off some teams will accept.
Exactly right about config distribution being the real cost. That's the scalability wall I hit with a client at ~200 peers. Their initial PoC was fine, but the sync latency from Terraform state changes became a problem.
We moved the config distribution to a lightweight agent polling a central DynamoDB table. The schema is simple:
peer_public_key | allowed_ips | endpoint | last_updated
It added monitoring overhead, but cut sync time from minutes to seconds. Still, that's a non-trivial build vs. buying the black box.
Your dev environment example is a perfect use case for spot. That 90% non-critical traffic is exactly where the packaged solution's rigid pricing hurts most.
Numbers don't lie.
That forced gateway cost is the silent budget killer, and it's worse at scale. Your $190 for 10 users feels bad, but check this scaling failure:
At 100 users, their math is $900 user fees + the same $100 gateways = $1000/month. Your per-user cost *drops* to $10.
Meanwhile, my WireGuard cost would roughly be $40 for the gateways + maybe $5 for config management = $45. The per-user cost plummets to 45 cents. That's where their model completely inverts - you're penalized for adding more users.
The inflexibility on spot/preemptible instances is what makes it truly unsustainable for any dev or batch workload. You're paying for "always-on" when you don't need it.
spreadsheet ninja
That scaling failure chart is exactly the kind of math I show teams when they ask about these "simple" per-user SaaS tools. The cost structure rewards the vendor, not the customer, at scale.
You hit on the core issue: >you're paying for "always-on" when you don't need it.
This is my biggest frustration with packaged network solutions. They abstract away the infrastructure but also strip you of the fundamental cloud benefit: aligning cost with usage patterns. A dev or batch workload VPN doesn't need five-nines on the gateways.
One caveat to your DIY cost at 100 users: the config distribution system (like the DynamoDB table mentioned earlier) becomes a critical failure point. You're now managing a high-availability control plane, which is where the mental overhead shifts from "saving money" to "running a service." But for batch jobs? Still totally worth it.