Have you ever lost an SSH key and been locked out of your EC2 instance? Or spent hours managing key pairs across a team, only to have a security audit flag them as a risk? If you're still connecting to EC2 the old-fashioned way — opening port 22, juggling .pem files, and maintaining a bastion host — there's a better approach.
AWS Systems Manager (SSM) offers three connection methods that eliminate SSH keys entirely. No open inbound ports. No bastion servers. Just clean, auditable, IAM-controlled access.
In this article, we'll walk through:
- How traditional SSH/RDP connections work (and why they're painful)
- What SSM is, and the shared prerequisites for all three methods
- The three SSM-based connection methods and how each one works under the hood
- How each method handles security and what users can do
- A practical guide for choosing the right method
The Old Way: SSH and Direct RDP
Before diving into SSM, let's quickly recap what most people are currently doing.
SSH (Linux instances)
ssh -i my-keypair.pem ec2-user@<public-ip>
This is the classic approach. You generate a key pair in AWS, download the .pem file, and use it to authenticate. To make this work, you need to:
- Open port 22 inbound in your security group
- Keep the instance reachable over the internet (or set up a bastion host for private subnets)
- Manage and distribute key pairs to every team member who needs access The pain points are real: keys get lost, leaked, or forgotten. Rotating them across a team is tedious. And that open port 22 is a constant target for brute-force attacks.
Direct RDP (Windows instances)
For Windows instances, you connect via Remote Desktop Protocol (RDP). AWS uses the key pair not for direct authentication, but to decrypt the Windows administrator password. You retrieve this password from the AWS console, then use an RDP client like mstsc to connect.
Requirements:
- Open port 3389 inbound in your security group
- A public IP address (or bastion host for private subnets)
- The key pair to decrypt the initial admin password Both approaches share the same fundamental problems: open inbound ports and the overhead of key management. SSM solves both.
What Is AWS Systems Manager (SSM)?
AWS Systems Manager is a service for managing AWS infrastructure at scale. One of its most useful features is Session Manager, which enables secure shell and GUI connections to EC2 instances — without any open inbound ports.
Shared prerequisites for all three SSM methods
Before you can use any of the three connection methods below, your EC2 instance needs:
- SSM Agent installed and running — Pre-installed on Amazon Linux 2, Amazon Linux 2023, and most Windows AMIs. Other OS types may require manual installation.
-
An IAM role attached to the instance — The role must include the
AmazonSSMManagedInstanceCoremanaged policy. - Outbound HTTPS (port 443) access to SSM endpoints — Either via an internet gateway (public subnets) or VPC endpoints (private subnets). Once these are in place, your instance appears as a "managed node" in SSM, and all three connection methods become available.
The Three SSM-Based Connection Methods
1. SSM Session Manager
Best for: Shell access to Linux or Windows instances
Session Manager gives you an interactive shell session directly from the AWS Management Console or AWS CLI — no SSH client, no key pair, no open ports required.
How it works
Your browser / AWS CLI
│
│ IAM authentication + SigV4 signing
▼
Session Manager Service ──── TLS 1.2 encrypted channel ────▶ SSM Agent on EC2
│ │
└──────────────── ssmmessages VPC endpoint (optional) ─────────┘
When you start a session:
- Session Manager authenticates your identity and validates your IAM permissions.
- It sends a message to the SSM Agent on the target instance to open a bidirectional channel.
- All traffic between your client and the instance is encrypted with TLS 1.2, and the connection request is signed with SigV4.
- Command input and output stream through this channel in real time. The instance never needs an inbound port open. The SSM Agent initiates an outbound connection to the SSM service — the traffic flows out, not in.
What you can do
- Run bash or PowerShell commands interactively
- View and edit files, inspect processes, tail logs
- Connect from a browser (AWS Console) or AWS CLI
- Apply fine-grained access control using IAM conditions (e.g., restrict access by EC2 tag)
- Record all session activity to S3 or CloudWatch Logs for auditing
2. SSM Port Forwarding + RDP
Best for: GUI access to Windows instances using your existing RDP client
This method uses Session Manager to create an encrypted tunnel between your local machine and the EC2 instance. You then point your RDP client at a local port, and SSM forwards the traffic through the tunnel to port 3389 on the instance.
How it works
RDP Client (mstsc, etc.)
│
│ connects to localhost:<local-port>
▼
AWS CLI + Session Manager Plugin
│
│ HTTPS (port 443) — TLS tunnel
▼
Session Manager Service
│
│ TLS tunnel
▼
SSM Agent on EC2 ──▶ RDP port 3389 (internal only)
To start a session, you run a single AWS CLI command:
aws ssm start-session \
--target <instance-id> \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber=3389,localPortNumber=55678"
Then open your RDP client and connect to localhost:55678. SSM forwards all traffic to port 3389 on the instance — but port 3389 is never exposed to the internet.
What you need
- AWS CLI with the Session Manager Plugin installed
-
Any RDP client you're already using
What you can do
Full GUI desktop experience via your familiar RDP client
Use RDP's built-in features: clipboard sharing, file transfer, printer/drive redirection
- Keep using your existing workflow — SSM just handles the secure tunneling
3. SSM Fleet Manager
Best for: GUI access to Windows instances entirely from the browser
Fleet Manager takes the RDP experience and moves it entirely into the AWS Management Console. There's nothing to install on your local machine — just open your browser, navigate to the Fleet Manager console, and click "Connect with Remote Desktop."
How it works
Your Browser (AWS Console)
│
│ HTTPS
▼
Fleet Manager (Amazon DCV protocol)
│
│ TLS encrypted channel
▼
SSM Agent on Windows EC2
Under the hood, Fleet Manager uses Amazon DCV (Desktop Cloud Visualization), a high-performance remote display protocol that streams the Windows desktop to your browser. The entire connection stays within AWS — no RDP traffic ever reaches the public internet.
You can have up to 4 simultaneous connections open in a single browser window.
What you can do
- Full GUI desktop access with nothing but a browser
- Connect via IAM Identity Center (SSO) — no Windows password needed if configured
- Manage multiple instances side by side
- One-click access from the EC2 instance list
Security: How Each Method Stays Safe
All three methods share a common security foundation:
| Security layer | Session Manager | Port Forwarding + RDP | Fleet Manager |
|---|---|---|---|
| Authentication | IAM policy | IAM policy | IAM policy + SSO support |
| Encryption | TLS 1.2 (+ optional KMS) | TLS 1.2 tunnel wrapping RDP | Amazon DCV protocol |
| Inbound ports required | None | None | None |
| SSH keys required | No | No | No |
| Session audit log | Full command log (S3 / CloudWatch) | Session start event only (CloudTrail) | Session start event only (CloudTrail) |
| Access control granularity | Instance, tag, or region level | Instance level | Instance level |
| Private subnet support | Yes (VPC endpoints) | Yes (VPC endpoints) | Yes (VPC endpoints) |
The key difference: audit depth
Session Manager is the only method that can record what commands were run during a session. If you need to demonstrate to a security auditor exactly what an engineer did during a maintenance window, Session Manager with S3 logging is your answer.
Port Forwarding and Fleet Manager record that a session happened (via CloudTrail), but the contents of the RDP session — the mouse clicks and keystrokes — are not captured.
Choosing the Right Method
Use this as a quick reference:
Is the OS Linux?
├── Yes → Session Manager (CUI is fine for Linux workloads)
└── No (Windows only)
├── Do you need full RDP features (file transfer, clipboard, drive redirection)?
│ └── Yes → Port Forwarding + RDP
└── Can you install AWS CLI on the local machine?
├── Yes → Port Forwarding + RDP or Fleet Manager (your choice)
└── No → Fleet Manager
Scenario quick-reference
| Scenario | Recommended method |
|---|---|
| Troubleshooting a production Linux server | Session Manager |
| Configuring IIS or Active Directory on Windows Server | Port Forwarding + RDP |
| Managing multiple Windows servers via SSO | Fleet Manager |
| Running deployment scripts from a CI/CD pipeline | Session Manager |
| Accessing EC2 from a locked-down corporate laptop | Fleet Manager |
| Developers who want to keep using their RDP client | Port Forwarding + RDP |
Summary
Here's what we covered:
- Traditional SSH / RDP requires open inbound ports, key pair management, and often a bastion host. These add operational overhead and attack surface.
- SSM eliminates all of that. Every method uses IAM for authentication and outbound-only HTTPS for communication — no inbound ports, no SSH keys.
- Session Manager is the most versatile: CUI access to Linux and Windows, with full command logging. Ideal for automation, auditing, and production environments.
- Port Forwarding + RDP lets you keep your existing RDP client workflow while adding SSM's security layer. Best when you need RDP's full feature set (file transfer, clipboard, etc.).
-
Fleet Manager requires nothing on the local machine — just a browser. Best for Windows-only environments and teams that want centralized, browser-based access.
Next steps
Fleet Manager Remote Desktop — AWS docs
If you're still using SSH keys and bastion hosts, try spinning up a test instance with theAmazonSSMManagedInstanceCorepolicy attached and connecting via Session Manager. The setup takes about 10 minutes — and you may never go back.
Found this useful? Drop a comment with which method you're using in your team — I'd love to hear how others are managing EC2 access.
Top comments (0)