Accessing EC2 Instances the Secure Way

Traditional methods for accessing EC2 instances—SSH on port 22 or RDP on port 3389—require opening inbound ports in security groups. That creates attack surface. Bastion hosts add a layer of indirection but introduce their own maintenance burden and still require exposed ports somewhere.

AWS Session Manager offers a different approach: secure shell access to instances without any inbound ports open, no bastion infrastructure to manage, and full audit logging of every session.

How Session Manager Works

Session Manager is part of AWS Systems Manager. Instead of connecting directly to an instance over the network, connections are brokered through the Systems Manager service. The SSM Agent running on the instance maintains an outbound connection to AWS, and sessions are established through that channel.

This means:

• No inbound security group rules needed
• No SSH keys to distribute or rotate
• No bastion hosts to patch and secure
• Every command is logged to CloudWatch or S3

The tradeoff is that instances need outbound internet access (or VPC endpoints for PrivateLink) to reach the Systems Manager endpoints.

Prerequisites

Before Session Manager will work, a few pieces need to be in place.

SSM Agent must be installed and running. Most AWS-provided AMIs include the agent by default—Amazon Linux, Ubuntu, and Windows Server images all have it pre-installed. For custom AMIs or older instances, the agent can be installed manually.

The instance needs an IAM role with Systems Manager permissions. Without this, the agent can’t authenticate with the service. The role needs at minimum the AmazonSSMManagedInstanceCore policy attached.

Outbound connectivity to Systems Manager endpoints is required. This typically means internet access through a NAT gateway or internet gateway. For private subnets without internet access, VPC endpoints for Systems Manager can be configured instead.

Setting Up Session Manager Access

Create an IAM Role

The instance needs permission to communicate with Systems Manager. This is handled through an IAM role attached to the instance.

1. Navigate to IAM in the AWS console
2. Select Roles from the left menu
3. Click Create role
4. Choose AWS service as the trusted entity
5. Select EC2 as the use case
6. Search for and attach the AmazonSSMManagedInstanceCore policy
7. Name the role something descriptive like EC2-SSM-Access

Attach the Role to Your Instance

With the role created, attach it to the EC2 instance:

1. Go to the EC2 console and select your instance
2. Choose Actions → Security → Modify IAM role
3. Select the role you just created
4. Click Update IAM role

Verify the Instance Appears in Fleet Manager

Once the role is attached, the SSM Agent will register the instance with Systems Manager. This typically takes a few minutes.

1. Navigate to Systems Manager in the console
2. Select Fleet Manager under Node Management
3. Your instance should appear in the managed nodes list

If the instance doesn’t appear after 10-15 minutes, verify the SSM Agent is running on the instance and that outbound connectivity to Systems Manager endpoints is working.

Connecting to Instances

Command-Line Access

For shell access to Linux instances or PowerShell access to Windows:

1. Go to Systems Manager → Session Manager
2. Click Start session
3. Select your instance and click Start session

A browser-based terminal opens with a shell on the instance. No SSH keys, no passwords, no open ports.

Sessions can also be started from the AWS CLI:

aws ssm start-session --target i-0123456789abcdef0

GUI Access for Windows

Session Manager’s default connection is terminal-based, which works well for Linux but isn’t ideal for Windows servers where you need the desktop.

For RDP access through Session Manager:

1. Navigate to Systems Manager → Fleet Manager
2. Select the Windows instance
3. Choose Node actions → Connect → Connect with Remote Desktop
4. Enter Windows credentials or provide the key pair for password retrieval
5. Click Connect

This establishes an RDP session tunneled through Session Manager—still no inbound ports required.

Why This Matters

Beyond eliminating exposed ports, Session Manager provides capabilities that traditional access methods lack:

Session logging captures every command entered during a session. Logs can be sent to CloudWatch Logs or S3 for retention and analysis. This creates an audit trail that SSH access alone can’t provide.

No credential management means no SSH keys to rotate, no passwords to manage, and no risk of credentials being leaked or shared inappropriately.

Access control through IAM means permissions are managed centrally. Granting or revoking access is an IAM policy change, not a key distribution problem.

Access to unreachable instances is possible even when network connectivity is degraded. As long as the SSM Agent can reach AWS, sessions can be established—useful for troubleshooting network misconfigurations.

Closing Thoughts

Session Manager isn’t just a convenience—it’s a security improvement over traditional instance access methods. Eliminating inbound ports removes attack surface, centralized IAM controls simplify access management, and automatic session logging provides visibility that would otherwise require additional tooling.

For most environments, there’s little reason to keep SSH or RDP ports open once Session Manager is configured. The setup takes minutes, and the security benefits are immediate.