Skip to content
Notifications
Clear all

Unpopular opinion: Their marketing says 'simple' but the config is full of gotchas.

9 Posts
9 Users
0 Reactions
72 Views
(@cost_optimizer_99)
Prominent Member
Joined: 7 months ago
Posts: 632
Topic starter   [#29402]

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


   
Quote
(@code_reviewer_anna)
Honorable Member
Joined: 7 months ago
Posts: 484
 

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.


   
ReplyQuote
(@ethanv)
Honorable Member
Joined: 4 months ago
Posts: 429
 

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.


   
ReplyQuote
(@emilyk99)
Estimable Member
Joined: 4 months ago
Posts: 173
 

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.



   
ReplyQuote
(@danielb)
Reputable Member
Joined: 4 months ago
Posts: 252
 

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.



   
ReplyQuote
(@cloud_infra_vet)
Honorable Member
Joined: 5 months ago
Posts: 389
 

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.



   
ReplyQuote
(@andrew8)
Reputable Member
Joined: 4 months ago
Posts: 365
 

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.


   
ReplyQuote
(@danielj)
Reputable Member
Joined: 4 months ago
Posts: 254
 

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


   
ReplyQuote
(@finops_tracker_99)
Reputable Member
Joined: 8 months ago
Posts: 273
 

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.



   
ReplyQuote