Hey folks, been deep in the weeds rethinking our team's SSH/management access to cloud instances. We're trying to move away from the classic, scary public bastion host and its ever-growing SSH key management problem. 😅
I've been prototyping and reading docs for three main contenders that keep coming up: **AWS Session Manager** (part of SSM), **Teleport**, and **Apache Guacamole**. They all approach "bastion replacement" from pretty different angles, and I'm trying to map them to real-world use cases. My primary lens is developer and admin ergonomics—how smoothly does this integrate into a daily flow?
Here’s my initial breakdown of core characteristics:
**AWS Session Manager**
* **Model:** Agent-based, tightly integrated with AWS IAM and CloudTrail. No inbound ports.
* **Key Feature:** It's not just SSH/RDP—it can start port forwarding sessions, run commands without interactive shells, and integrates with S3/CloudWatch for logging.
* **Config Snippet (CLI):**
```bash
# A typical session start
aws ssm start-session --target i-1234567890abcdef0
# Port forwarding magic
aws ssm start-session --target i-0abc123def456
--document-name AWS-StartPortForwardingSession
--parameters '{"portNumber":["5432"],"localPortNumber":["5432"]}'
```
* **Big Question:** How does this feel for non-AWS resources or hybrid setups? The vendor lock-in is real.
**Teleport**
* **Model:** Identity-aware access proxy. It becomes your certificate authority for SSH, Kubernetes, databases, and apps.
* **Key Feature:** Short-lived certificates, session recording, and JIT (Just-In-Time) access requests are huge for audit. Feels like a proper PAM (Privileged Access Management) system.
* **Thoughts:** Requires running the Teleport proxy and auth services. Seems more "infrastructure-heavy" but also far more comprehensive. How's the learning curve for developers used to raw SSH?
**Apache Guacamole**
* **Model:** Clientless remote desktop gateway. RDP, SSH, VNC via HTML5.
* **Key Feature:** No client software needed—just a browser. Great for providing controlled access to internal web apps or desktops without a VPN.
* **Thoughts:** It's a bastion *in front of* your protocols, not a replacement for the underlying auth mechanism. You'd still need to manage keys/passwords on the targets, unless you layer it with something like LDAP/SSO for the Guac portal itself.
My current mental framework is:
* **Pure AWS shop, developer-centric:** Session Manager seems like a no-brainer for its simplicity and integration.
* **Multi-cloud, strict compliance, need session recording:** Teleport appears purpose-built.
* **Providing secure, ephemeral access to contractors or for specific internal tools:** Guacamole's browser-based model shines.
Has anyone run a hybrid approach? Maybe Teleport for SSH/Kubernetes and Guacamole for the odd RDS desktop session? Or replaced Session Manager's logging with something more granular? Really curious about the day-to-day developer experience and any plugin/CLI tooling that makes these systems sing.
editor is my home
I'm Grace, a lead platform engineer at a 120-person SaaS shop running on AWS, and we've been running Teleport in production for our developer and SRE access for about 18 months after migrating from a janky OpenSSH bastion setup.
Core comparison based on our evaluation and what I hear from peers:
1. **Primary Use Case Fit:** AWS Session Manager is best for teams that live 90% in the AWS console/CLI and need basic, audited instance access. Teleport is built for engineering-focused organizations (50-500+ people) that need unified, identity-based access to SSH, RDP, Kubernetes, databases, and internal web apps from day one. Guacamole is a strong fit for providing browser-based RDP/VNC/SSH portals to contractors or non-technical staff, especially in hybrid or multi-cloud environments where you can't install an agent.
2. **Real Cost & Complexity:** Session Manager's cost is buried in SSM agent management and Data Scan charges, but it's nearly free for low usage; operational cost is the engineering time to build guardrails and workflows it lacks. Teleport's open-source core is free but you'll need the $12-$15/user/month Enterprise tier for SSO, RBAC, and compliance features, plus about 40-60 hours of initial setup to integrate with your IDP and configure resource discovery. Guacamole is "free" but the real cost is 2-3 weeks of engineering time to containerize, harden, and maintain its Java/Tomcat stack, and you must build the auditing and secret management around it yourself.
3. **Daily Developer Ergonomics:** Session Manager feels bolted on; you're still managing keys for Git or using the AWS CLI for sessions, which breaks normal SSH tooling like VS Code Remote. Teleport's `tsh` CLI replaces the SSH command and its proxy service means developers get a true, certificate-based SSH experience that works with all their existing tools and configs. Guacamole requires users to work entirely in a browser, which is fine for a quick RDP fix but frustrating for all-day SSH work due to clipboard issues and terminal lag.
4. **Where It Clearly Loses:** Session Manager becomes a coordination nightmare once you have more than 20 developers needing concurrent access; it has no native concept of teams or roles beyond basic IAM policies. Teleport's community support is slow; you're reliant on their docs and GitHub issues unless you pay. Guacamole's architecture is its biggest weakness; scaling the guacd components and troubleshooting WebSocket connections for more than 50 concurrent users requires dedicated operational knowledge.
My pick is Teleport, specifically if your team is engineering-heavy and you need a consolidated access layer for SSH, databases, and internal dashboards that feels native. If your use case is purely "a few admins need to access EC2 instances without a public IP," stick with AWS Session Manager. To make the call clean, tell us what percentage of your access is SSH for dev work versus RDP for admin work, and whether you have a compliance requirement like SOC 2 or HIPAA that mandates session recording.
The right tool saves a thousand meetings.
The integration you mentioned between Session Manager and the AWS CLI is a real time saver for daily work. But it's crucial to map the data egress costs for your logging setup.
When you use S3 and CloudWatch for session logs, especially with verbose application logging or long-lived port forwarding sessions, the volume can be substantial. Have you modeled the cost delta compared to your current bastion's logging method? I often see teams enable full audit logging without realizing the storage and data transfer costs can run into hundreds of dollars monthly, depending on session frequency and data volume.
Your config snippet shows the port forwarding document. That's where costs can spike if you're moving large files or database traffic, as the data passes through SSM. You need to monitor the `ssm.outboundDataTransfer` metric in Cost Explorer.
CostCutter
This breakdown is really helpful, especially the point about > SSO, RBAC, and compliance features. I'm curious, for a smaller team just starting to tighten up access (maybe 20 engineers), would you consider the open-source Teleport core viable for a first step? Or is the lack of SSO integration a deal-breaker for proper audit trails from day one?
The lack of SSO in the open-source Teleport core is absolutely a deal-breaker for audit trails, because you lose the immutable identity link. For 20 engineers, you're looking at a $1k/month jump to the Team tier for SSO and RBAC. That's a tough sell against $0 for Session Manager.
You could hack something together with the OSS version and Duo MFA, but then you're managing another legacy system. The hidden cost is the engineering time to build and maintain that integration, which often surpasses the SaaS subscription within a quarter.
I'd push for the Team tier budget, or stick with Session Manager and accept its limitations. Trying to build enterprise features on the OSS core usually ends up being a false economy.
Cloud costs are not destiny.