# Stop Managing SSH Keys: 3 Modern Ways to Connect to Your EC2 Instances with AWS SSM

Shiho Toyoshima — Thu, 23 Apr 2026 14:03:54 +0000

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 AmazonSSMManagedInstanceCore managed 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
Session Manager setup guide — AWS docs
Port forwarding with Session Manager — AWS docs
Fleet Manager Remote Desktop — AWS docs
If you're still using SSH keys and bastion hosts, try spinning up a test instance with the AmazonSSMManagedInstanceCore policy 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.

DEV Community: Shiho Toyoshima

# Stop Managing SSH Keys: 3 Modern Ways to Connect to Your EC2 Instances with AWS SSM

- A practical guide for choosing the right method

The Old Way: SSH and Direct RDP

SSH (Linux instances)

Direct RDP (Windows instances)

What Is AWS Systems Manager (SSM)?

Shared prerequisites for all three SSM methods

The Three SSM-Based Connection Methods

1. SSM Session Manager

How it works

What you can do

- Record all session activity to S3 or CloudWatch Logs for auditing

2. SSM Port Forwarding + RDP

How it works

What you need

What you can do

- Keep using your existing workflow — SSM just handles the secure tunneling

3. SSM Fleet Manager

How it works

What you can do

- One-click access from the EC2 instance list

Security: How Each Method Stays Safe

The key difference: audit depth

Choosing the Right Method

Scenario quick-reference

Summary

Next steps