AWS Systems Manager Session Manager: Private Access, IAM, and Session Evidence

AWS Systems Manager Session Manager provides an interactive shell or command session to managed nodes without requiring an inbound SSH port, bastion host, or operator-managed SSH key. A node’s SSM Agent establishes outbound connectivity to Systems Manager; the operator is authorized through IAM. This can simplify private fleet access, but a safe deployment still requires the right instance permissions, reachable service endpoints, controlled session documents, logging configuration, and an explicit model for who can become an administrator on the host.

Session Manager is not a universal replacement for every SSH workflow. It supports interactive sessions, port forwarding, and SSH tunneling through Session Manager; Systems Manager Run Command is the separate facility for one-off managed commands. The observability and logging properties differ by session type. In particular, Session Manager cannot record the contents of SSH or port-forwarding sessions because those payloads are encrypted inside the tunnel. If a security requirement needs command-level evidence, use an interactive shell with supported session logging and verify that the chosen command path actually produces it.

Establish the managed-node path

A target must be registered as a Systems Manager managed node, have a supported operating system, run a sufficiently recent SSM Agent, and have the required instance profile or hybrid activation role. The instance role normally includes the permissions required for Systems Manager core operations. Do not reuse a broad administrator role merely to make the node appear online. Grant the operator’s user or role the session-start permissions separately from the node’s agent permissions.

For a private subnet, the node needs outbound HTTPS connectivity to the Systems Manager endpoints in its Region. You can use controlled internet egress or interface VPC endpoints through AWS PrivateLink. For current SSM Agent connectivity, allow ssm and ssmmessages; ec2messages is optional in Regions launched before 2024 and is not supported in Regions launched in 2024 or later. Logging to S3 or CloudWatch Logs adds destination connectivity and permissions; encryption also has caller and key-policy requirements. Verify the current regional and feature-specific requirements rather than opening unrestricted outbound access.

Check security groups, route tables, DNS, endpoint policies, and network ACLs. Interface endpoint security groups must allow the node’s HTTPS connection, and private DNS should resolve the service hostname to the intended endpoint. A node can appear managed through one Systems Manager feature while a session data channel fails, because API control and interactive data paths involve different endpoints.

Control who can start which session

IAM policies can scope StartSession to approved managed nodes and session documents. Use resource tags or explicit instance ARNs where possible, and limit the session document to the intended mode. Consider separate operator roles for standard shell, privileged break-glass work, and port forwarding. Restrict TerminateSession and ResumeSession based on operational needs, and audit the impact of granting access to shared session documents.

The default SSM-SessionManagerRunShell document contains account-level preferences such as logging destination, KMS settings, and run-as behavior. A custom session document can limit commands or define a different session type, but it must be reviewed like code because it controls what the operator can execute on the node. Avoid a broad policy that lets operators select any session document or target any managed node.

The ssm-user account has administrative permissions by default on supported SSM Agent versions unless explicitly configured otherwise. This may be acceptable for controlled break-glass administration, but it must be an intentional privilege decision. Configure run-as behavior or restrict the account according to the platform’s hardening policy. A Session Manager login is not automatically least privilege just because it uses IAM.

# Start an interactive session to one approved managed node.
aws ssm start-session \
  --target "$INSTANCE_ID" \
  --document-name SSM-SessionManagerRunShell

# Start a single managed command without opening an interactive shell.
aws ssm send-command \
  --instance-ids "$INSTANCE_ID" \
  --document-name AWS-RunShellScript \
  --parameters commands='["id","uname -a"]'

The first command requires the local Session Manager plugin when run through the AWS CLI; browser-based sessions use a different client path. The second command is Systems Manager Run Command, not an interactive Session Manager transcript. Use it only when the operator role is authorized for the document and the selected commands are approved. Set and verify the AWS account and region before either command, and do not put credentials or sensitive command output in the shell arguments.

Design transcript and audit logging

CloudTrail records Session Manager API activity such as session starts, but an API event is not the same thing as a complete transcript of commands typed inside a shell. Session Manager can stream supported session data to Amazon S3 or CloudWatch Logs, where you can configure encryption, retention, access policies, and downstream alerting. Test that the transcript contains the required input and output for the exact operating system and session mode used by responders.

Port-forwarding and SSH sessions are a critical exception: Session Manager logging is not available for the session payload because Session Manager serves as an encrypted tunnel. If you allow those modes, make the logging limitation explicit and add alternate controls such as destination application logs, endpoint audit records, short-lived authorization, and a recorded change ticket. Do not claim that every Session Manager command is centrally recorded merely because CloudTrail is enabled.

Protect log sinks from operators who can start sessions. Use a dedicated S3 bucket or CloudWatch log group with encryption and retention controls, deny routine deletion where feasible, and ensure node egress can reach the sink. If using PrivateLink, configure S3 gateway or CloudWatch Logs interface endpoints as needed. Validate bucket and log-group policies with the exact service principal and encryption key; a logging preference that targets a deleted or inaccessible sink may cause a session to fail or produce incomplete evidence.

Keep sessions private with VPC endpoints

PrivateLink endpoints allow managed nodes to reach Systems Manager APIs without public internet access. This can reduce egress exposure and remove NAT dependencies, but it moves the network policy decision to endpoint placement, private DNS, route tables, security groups, endpoint policies, and IAM. Ensure endpoint availability across the subnets and zones where the managed fleet runs. A single endpoint subnet can become a failure or cross-zone dependency if capacity is not planned.

Optional features require their own connectivity. KMS encryption, CloudWatch Logs streaming, and S3 session output need access to the corresponding AWS services. A session may start successfully and still fail to upload logs if the logs or s3 endpoint is absent, or if the node’s role lacks permission. Use a least-privilege endpoint policy and instance role, then run a test session that checks both command output and final log delivery.

Diagnose offline nodes and failed sessions

If the managed node is not available, inspect SSM Agent service health and version, instance profile association, Systems Manager inventory/managed-node status, DNS resolution, outbound route, endpoint policy, and CloudTrail. For nodes using VPC endpoints, check the endpoint’s private DNS and security group on port 443. Confirm that the agent can reach the required regional endpoints and that clock synchronization is adequate for signed requests.

If session start is denied, inspect the operator role’s StartSession permission, target resource scope, allowed document, node tags, and explicit denies. A managed node can be online while a user is unauthorized. If the session opens but transcript logging fails, check the SSM Agent version, account preferences, S3 or CloudWatch destination, KMS access, and endpoint reachability. Inspect the Systems Manager troubleshooting guidance before weakening IAM or allowing public inbound access.

If terminal input appears but not in a transcript, determine whether the operator used SSH or port forwarding. Those modes tunnel encrypted payloads and are not logged as interactive commands by Session Manager. Move to a supported shell session if command transcript is mandatory, or document compensating controls before allowing the tunnel. Retain session start/stop metadata, operator identity, node identity, and incident ticket in the audit record.

Use Session Manager as a controlled access plane

Removing inbound SSH exposure is valuable, but operators still need least privilege, short-lived access, reviewable session documents, patched SSM Agent, and a host hardening baseline. Route emergency sessions through an approved role, require a change or incident reference, and send session lifecycle events to monitoring. Periodically test that a user outside the approved group cannot start a session and that an authorized user cannot target a node outside the intended fleet.

Review whether a session needs root, network tunneling, or direct shell access. Prefer scoped Run Command documents for repeatable maintenance tasks where interactive administration is unnecessary. Separate read-only diagnostics from write-capable break-glass access. Close traditional inbound ports only after verifying the alternate access path and monitoring; preserve out-of-band recovery for control-plane or endpoint outages.

Session Manager changes the network direction and identity model of remote administration, but it does not remove the need for an access policy or trustworthy evidence. Treat the SSM Agent, instance role, operator role, session document, VPC endpoints, and log sink as one end-to-end system and test each component under normal and failure conditions.

Related:

Sources: