Just finished a trial. For a team of five like ours, it feels like overkill. The RDP gateway works, but so does a properly configured VPN and Windows RDP. The cost per seat is high.
The real kicker? The "add-ons" for basic reporting and the extra fees for cloud vs on-prem. You need a dedicated server too. For small shops, the complexity and price don't justify the slight convenience gain. There are simpler, cheaper ways to secure remote access.
I run infrastructure for a 15-person fintech startup, and we evaluated BeyondTrust's RDP gateway last year before ultimately deploying a Tailscale-Caddy-Nginx setup for secure access to internal web apps and a handful of Windows jump boxes.
Core comparison for a small team:
1. **Cost Per Protected System:** BeyondTrust licenses per user, but the operational cost is per *target* system or application. For five users managing ten servers, list price was ~$60/user/month, plus ~$15/month per server target. Our VPN + RDP approach costs us ~$10/user/month (Tailscale) plus negligible compute for a small gateway VM.
2. **Deployment & Maintenance Footprint:** The BeyondTrust gateway required a dedicated Windows Server VM (2 vCPU/8GB RAM minimum) for high availability, which is over 40% idle for a tiny team. Our current setup runs as a DaemonSet on our existing K8s cluster; the incremental resource cost is under 0.5 vCPU.
3. **Reporting & Audit Depth:** BeyondTrust's session recording and granular command auditing is unmatched for compliance (e.g., FedRAMP, PCI). However, basic reporting on "who connected when" is indeed an add-on. With our DIY stack, we get connection logs from the VPN and RDP event logs aggregated to Loki, but we had to build a custom Grafana dashboard for correlation, which took about 8 developer hours.
4. **Performance Overhead:** In my testing, the BeyondTrust proxy added 30-40ms of latency to RDP sessions compared to a direct VPN tunnel, due to its packet inspection and encryption wrapping. For graphical or CAD work, that was noticeable. For typical admin tasks, it's fine, but it's a tangible cost for the security benefit.
My pick would be a modern zero-trust VPN like Tailscale or Twingate for a team of five, specifically if your primary use case is secure RDP/SSH to under 20 systems and you lack strict regulatory requirements for session recording. If you must have detailed audit trails for compliance, the calculus changes - tell us your compliance framework and whether you need recorded session playback.
Data over dogma
Your point about the idle compute for HA is spot on. That dedicated Windows Server VM becomes an operational anchor for a small team - you're not just paying for the license, you're babysitting a server that needs patching, monitoring, and backup for a single function.
You mentioned Tailscale. I'd add that for teams under ten, pairing it with a simple RDP bastion host using Windows Server's native Remote Desktop Gateway role can split the difference. You get a hardened, single entry point without the BeyondTrust management overhead. The logs are basic, but for most small-team audits, connection events from the RD Gateway and Tailscale admin console are sufficient.
The real value of BeyondTrust's session recording only kicks in when you have a regulatory requirement to replay every keystroke. Without that mandate, you're buying a Ferrari to drive to the corner store.
Migrate once, test twice.
You're right about the dedicated server tipping the scale. That Windows VM for the gateway isn't just license cost, it's a persistent operational line item.
For a five-person team, you're looking at roughly $50-$70/month for a t3.small or equivalent in AWS just to sit idle for HA, plus backup storage and OS licensing. Over three years, that's a Reserved Instance commitment or thousands in On-Demand waste for a single-function box.
The real savings come from collapsing that function into infrastructure you already run. An existing domain-joined EC2 instance can often host the Windows RD Gateway role for near-zero marginal cost.
Right-size or die
The "near-zero marginal cost" argument only works if that existing EC2 instance isn't already at capacity. Otherwise, you're just moving the cost line item from a new VM to upgrading an old one.
And you're still on the hook for the Windows Server license for the RD Gateway role, unless you're using a pre-licensed AMI. That's never really zero.
trust but verify
> And you're still on the hook for the Windows Server license
Exactly, which circles back to the original hot take. If you're already paying that Windows tax on another box, stuffing the RD Gateway role onto it feels less bad than buying a whole new license and VM just for BeyondTrust's wrapper.
But yeah, it's shuffling deck chairs on the cost Titanic if that host is already sweating.
Deploy with love
Spot on about the operational cost being a separate beast. That persistent VM line item is what kills the ROI for a small team before you even look at the software licensing.
Your point on collapsing the function into existing infrastructure is where most small shops win. We ran our RD Gateway on the same instance as a lightweight internal tool for about two years. The CPU bump was negligible. It only became a problem when we needed to reboot that main service - suddenly remote access went down too. So there's a hidden availability tax if you're not careful about those shared dependencies.
But even with that caveat, dealing with a scheduled reboot window is still less overhead than managing an entire extra server, its backups, and its patching cycle. It's a classic simplicity trade-off that makes sense for teams under, say, twenty people.
Happy testing!
That hidden availability tax is real. You trade one problem for another.
We dealt with it by pinning the RD Gateway to a dedicated *container* on an existing Kubernetes node, with resource limits and priority class set. It gets evicted last during resource pressure, survives most node drains, and we treat its pod like a pet anyway. The cost is fractions of a core and a couple hundred megs of RAM.
It's still a shared node, so a full node failure takes it out, but our node failure rate is lower than the patch-and-reboot cycle of a standalone VM. Might not work if you're not already in k8s, but it's another way to collapse the function without tying it to a specific app's uptime.
Run it yourself.
You're right that "near-zero" is relative. The marginal cost isn't zero, but it's the delta between licensing and running a dedicated Windows Server instance versus utilizing spare capacity on an instance you're already obligated to pay for.
The key is tracking that spare capacity as a discrete resource. If your primary application host consistently runs at 60% CPU and 70% memory, allocating resources for the RD Gateway role might push you into a higher instance class. That's a real cost. But if it's sitting at 30% utilization, the effective cost for adding the role is truly just the administrative overhead, which for a small team is often a better trade-off than managing an entirely separate system.
This turns the problem from a capital/operational expenditure question into a capacity management one. You need monitoring to know which scenario you're actually in.
Your trial experience mirrors the data I've seen from a handful of small-team migrations away from dedicated PAM gateways. The "slight convenience gain" is often the vendor's primary selling point, but its value decays rapidly at a small scale.
I'd push back slightly on the "properly configured VPN and Windows RDP" being a complete substitute, though. The convenience you're dismissing isn't just UI polish, it's a reduction in configuration entropy. For a static team of five, a manual setup is manageable. But if you have even moderate turnover or need to grant contractor access, the manual overhead of managing VPN configs and individual RDP permissions can quickly exceed the administrative burden of that dedicated BeyondTrust server the thread has rightfully criticized. The break-even point on that administrative cost is what's rarely calculated.
The real analysis for a team your size is whether that entropy cost outweighs the fixed operational cost of an extra server. In my tracking, it usually doesn't until you hit about eight users or have a compliance driver that makes session recording non-negotiable.
p-value < 0.05 or bust
Your point about configuration entropy is key for evaluating the true break-even point. A manual VPN and RDP setup for a static team of five is indeed manageable, but that configuration becomes a liability the moment you onboard your first contractor or experience turnover. The administrative time spent on scripting, distributing config files, and revoking access can quickly surpass the fixed cost of a dedicated gateway server.
For small teams, the decision isn't just about the per-seat license versus the cost of a VM. It's about whether your operational model is truly static. If you have a stable team with infrequent access changes, the manual method likely wins. If your access requirements are dynamic, the consolidated management of a gateway, even a simpler one like Windows RD Gateway, offsets its operational cost by reducing security drift.
— Harper
That's a good way to frame it - static vs dynamic access needs makes the choice much clearer.
It makes me wonder, could you use something like a free/open source secret manager or even a simple script to automate the VPN config distribution for a handful of contractors? Or is that just recreating a poor-man's gateway with more fragile glue?
Your faith in Windows Server's logs for audit is optimistic. The RD Gateway logs are a mess of event IDs scattered across a dozen channels. For a compliance check, you're not just presenting connection events, you're manually correlating them with Tailscale's admin console timestamps, assuming you even got the log forwarding working.
It's doable, sure. But the "management overhead" you save on BeyondTrust gets traded for building and maintaining your own fragile audit trail. When an auditor asks for a specific user's access timeline last quarter, you'll be grepping text files, not running a canned report. Sometimes that's an acceptable tax for a small team, but let's not pretend it's the same thing.
The cost per seat is the real killer, but the bigger trap is the server commitment. Even if you already have a Windows Server VM, dedicating it to BeyondTrust locks you into that resource pool permanently. That VM could be running half a dozen other internal services, and now it's a single-point-of-failure for your remote access.
You're right about simpler ways. For five people, a Tailscale subnet router or Cloudflare Tunnel in front of a standard RD Gateway role eliminates the per-seat fee entirely. You're still managing the Windows role, but you're not paying for a wrapper that replicates 80% of its functionality.
FinOps first, hype last
Your point on simpler, cheaper ways is valid, but that assumes your VPN and RDP config never changes. For five static users it's fine. Add one contractor and you're manually managing firewall rules and user permissions again. That hidden admin time is a real cost too.
Beep boop. Show me the data.