Administrative access without SSH keys
Lesson 5 of 6 in Securing Compute Workloads.
The bastion host is a 2010 answer to a 2026 problem. It needs a public address, an open port 22, a key-pair distribution process, its own patching, its own logging, and a story for what happens when someone leaves the company still holding a private key. Every one of those is a control you now have to operate.
Systems Manager Session Manager removes the problem instead of managing it. The SSM Agent on the instance opens an outbound connection to the Systems Manager service; your shell session is brokered through that channel. The consequences are the reason this is the exam's default answer for secure administrative access: no inbound ports, no bastion host, no SSH keys, no public IP address required. Authorization is IAM — ssm:StartSession on specific instance ARNs or, better, conditioned on instance tags, so "the database team may open sessions on Role=db instances in production" is a policy rather than a key-distribution convention. Every session start is a CloudTrail event, and the session transcript itself can be streamed to CloudWatch Logs or S3 and encrypted with a KMS key.
The prerequisites are the other half of the exam question: the instance needs the SSM Agent running, an instance profile granting AmazonSSMManagedInstanceCore, and a network path to the Systems Manager endpoints. In a private subnet with no NAT gateway, that path means interface VPC endpoints for ssm and ssmmessages (plus ec2messages for some agent features). "Session Manager does not work on my private instances" is nearly always a missing endpoint or a missing instance profile — never a missing security-group rule, because there is no inbound rule to miss.
| Session Manager | EC2 Instance Connect | Bastion + SSH key | |
|---|---|---|---|
Inbound port needed | none | port 22 — from your network, or through an EC2 Instance Connect Endpoint | port 22 open to the internet or to your ranges |
Credential | IAM identity; no key material at all | IAM call pushes a short-lived public key to the instance (valid about 60 seconds) | a long-lived private key, held by a human, copied wherever they like |
Works without a public IP | yes — with VPC endpoints for | only via an EC2 Instance Connect Endpoint, which provides the private path | only if the bastion itself is reachable |
Needs the SSM Agent | yes | no — it needs the instance’s SSH daemon and the | no |
Session logging | built in: transcript to CloudWatch Logs or S3, KMS-encrypted | the API call is in CloudTrail; the SSH session itself is yours to log on the host | whatever you build on the bastion |
Port forwarding / tunnels | yes, including to a remote host such as a database | standard SSH forwarding, once connected | standard SSH forwarding |
The exam reads it as | the default correct answer for secure administrative access | the right answer when a question insists on SSH with ephemeral keys | the thing being replaced |
EC2 Instance Connect deserves its distinction stated precisely, because the two services are easy to blur. Instance Connect does not remove SSH — it removes the long-lived key. The ec2-instance-connect:SendSSHPublicKey API pushes a one-time public key onto the instance, your client then makes a normal SSH connection within a short window, and the key expires. You still need an SSH network path, which historically meant a public IP or a bastion; an EC2 Instance Connect Endpoint now supplies that path privately, so a private instance can be reached over SSH without a public address. What Instance Connect does not give you is the session transcript, the shell preferences, or the no-agent-needed/no-port-needed combination that makes Session Manager the default.
Two controls make Session Manager audit-ready rather than merely convenient. Session preferences (an account-level document) set the KMS key for session encryption, the log destination, idle timeout, maximum session duration, and the RunAs user — so sessions do not silently run as root. And tag-based authorization in the ssm:StartSession policy, with ssm:resourceTag/ conditions, is how you express "this team, these instances" without maintaining a list of instance ids. For break-glass, keep a separate role with wider session rights, require MFA in its trust policy, and alarm on its use — an access path you expect to be used twice a year should page someone when it is used at all.
Key terms: Session Manager, EC2 Instance Connect, Instance profile
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.