Session Manager Without Open Ports

Session Manager, a capability of AWS Systems Manager (SSM), gives you interactive shell access to EC2 instances and on-premises servers without opening any inbound ports. Understanding precisely how it achieves this is a high-value exam topic, because it underpins modern, bastion-free administration.

The magic starts with the SSM Agent, software preinstalled on most AWS AMIs (Amazon Machine Images). The agent runs on the instance and initiates an outbound connection to the Systems Manager service endpoints. Because the instance reaches out, no inbound rule is ever required, the security group can block all inbound traffic.

For SSM to work, the instance needs an IAM role (via its instance profile) granting Systems Manager permissions, typically the managed policy AmazonSSMManagedInstanceCore. Without this role the agent cannot register, so attaching the right role is the first troubleshooting step when an instance does not appear as a managed node.

Session Manager works even for instances in private subnets with no public IP. The agent reaches SSM either through a NAT gateway or, more securely, through VPC interface endpoints (PrivateLink) for ssm, ssmmessages, and ec2messages. Endpoints keep all traffic on the AWS network, never touching the internet.

An authorized user starts a session from the console, CLI, or SDK. The command below opens a shell on a managed instance with no SSH client, key, or open port involved. IAM decides whether the user may start the session at all.

Who can open a session is governed entirely by IAM policies on the ssm:StartSession action. You can scope access to specific instances by tag, restrict which users may connect, and even limit which SSM documents (session types) they may use. This replaces SSH key distribution with centralized, auditable IAM control.

A powerful pattern scopes session access by instance tag. A policy can allow ssm:StartSession only on instances tagged, say, Environment=Dev, so developers reach dev boxes but never production. This attribute-based control scales cleanly and enforces least privilege without per-instance policies.

Session data is encrypted in transit using TLS, and you can require KMS encryption for the session channel for extra assurance. Combined with no open ports, this means administrative traffic is both invisible to the internet and protected end to end, satisfying strict compliance requirements.

Session Manager also supports port forwarding, tunneling a port from your machine to a port on the instance (or beyond) over the secure SSM channel. This lets you reach RDP or a database without exposing those ports publicly, replacing yet another reason teams kept bastions around.

The security model is compelling: no inbound ports to attack, no SSH keys to leak, IAM-based access control, optional private endpoints, and encryption throughout. Every weakness of traditional remote access is addressed, which is why the exam treats Session Manager as the default answer for secure administration.

Session Manager uses an outbound SSM Agent plus an instance role with AmazonSSMManagedInstanceCore to deliver shell access with no inbound ports, public IP, or keys. Access is controlled by IAM (ssm:StartSession), scoped by tags, encrypted in transit, and reachable privately through VPC endpoints. It also supports secure port forwarding.

Test Session Manager mechanics.

Session Manager gives shell access through the outbound SSM Agent plus an instance role (AmazonSSMManagedInstanceCore), needing no inbound ports, public IP, or keys. Access is governed by IAM (ssm:StartSession), scoped by tags, encrypted with TLS/KMS, and works privately via VPC endpoints for ssm, ssmmessages, and ec2messages. It also supports secure port forwarding.