This chapter covers AWS Systems Manager Session Manager, a fully managed service that enables secure interactive shell access to EC2 instances without opening inbound ports, using SSH keys, or managing bastion hosts. For the SOA-C02 exam, questions on Session Manager appear in the Security domain (Objective 4.1) and typically account for 5–10% of the exam. Mastering this topic is essential because it represents a modern, auditable, and secure access method that replaces traditional SSH/RDP, and the exam tests both configuration steps and troubleshooting scenarios.
Jump to a section
Imagine a secure office building with no public entrances. Employees enter via a tunnel that connects directly to a central security kiosk. Each employee has an ID badge (IAM role) that grants them access only to specific floors (instances). When an employee wants to enter the building, they present their badge at the kiosk (SSM service), which verifies their identity and checks if they are authorized to access a particular floor. The kiosk then opens a private, encrypted door (session) that leads directly to that floor, bypassing all public hallways (internet). No one outside the building can see which employee entered which floor, and the employee never touches a public street. The kiosk logs every entry and exit (CloudTrail). If an employee loses their badge, the kiosk can revoke access instantly without changing locks. This is exactly how SSM Session Manager works: the SSM agent on the instance acts as the floor door, the SSM service is the kiosk, and IAM policies are the badge rules. There is no SSH key, no bastion host, and no open inbound port. The session is established over an outbound connection from the instance to the SSM service, making the instance invisible to the internet.
What is SSM Session Manager?
AWS Systems Manager Session Manager is a capability of AWS Systems Manager that allows you to manage your EC2 instances, on-premises servers, and virtual machines through an interactive, browser-based shell or the AWS CLI. It does not require opening inbound ports, maintaining bastion hosts, or managing SSH keys. Sessions are initiated from the AWS Management Console, AWS CLI, or SDK, and all session activity can be logged to Amazon S3 or Amazon CloudWatch Logs for auditing.
Why Session Manager Exists
Traditional remote access methods (SSH, RDP) require opening inbound ports (22, 3389) and managing keys or passwords. This creates security risks: exposed ports are targets for brute-force attacks, SSH keys can be stolen, and bastion hosts add complexity and cost. Session Manager solves these problems by:
Eliminating the need for inbound ports: instances only need outbound HTTPS (port 443) to the SSM service endpoints.
Removing SSH key management: access is controlled via IAM policies, not key pairs.
Providing centralised auditing: all session input/output can be logged to S3 or CloudWatch Logs.
Supporting port forwarding and SSH tunneling through Session Manager for accessing other services.
How Session Manager Works Internally
Prerequisites: The EC2 instance must have the AWS Systems Manager Agent (SSM Agent) installed and running. The instance must also have an IAM role that grants permissions to communicate with the SSM service (AmazonSSMManagedInstanceCore managed policy). The instance must be able to reach the SSM endpoints over HTTPS (port 443) – typically via a VPC endpoint or NAT gateway if in a private subnet.
Registration: When the SSM Agent starts, it registers the instance with the SSM service by sending a registration request. The service responds with a unique instance ID. The instance then periodically sends heartbeat signals (every 5 minutes by default) to maintain its managed status.
Session Initiation: A user initiates a session via the Console, CLI (aws ssm start-session), or SDK. The request is authenticated and authorised by IAM. The SSM service creates a session record and sends a message to the SSM Agent on the target instance over the existing outbound connection.
Session Establishment: The SSM Agent receives the session request and opens a WebSocket connection back to the SSM service. This WebSocket is used for bidirectional, encrypted communication. The user’s client also connects to the SSM service via WebSocket (if using CLI) or via the Console’s browser-based terminal. The SSM service relays data between the client and the agent. No direct network connection exists between the user and the instance.
Session Termination: When the user ends the session, the client sends a termination signal, the SSM service closes the WebSocket, and the agent terminates the shell process. The session record is updated with end time and logged activity.
Key Components, Values, Defaults, and Timers
SSM Agent: Must be version 2.3.68.0 or later for Session Manager. On Amazon Linux 2, it is pre-installed. On other OS, install manually. Agent checks for updates every 5 minutes.
Heartbeat Interval: 5 minutes by default. If the agent fails to send heartbeats for 30 minutes, the instance is marked as unreachable.
Idle Session Timeout: Configurable via Session Manager preferences, default is 20 minutes. If no input for the timeout period, the session is automatically terminated.
Max Session Duration: Default is 60 minutes, configurable up to 1440 minutes (24 hours).
Port: Uses TCP 443 for outbound HTTPS to SSM endpoints.
VPC Endpoints: For instances in private subnets without internet access, create VPC endpoints for ssm, ssmmessages, and ec2messages. These are interface endpoints (powered by AWS PrivateLink).
IAM Policies: To start a session, a user needs ssm:StartSession permission. To terminate, ssm:TerminateSession. For logging, s3:PutObject or logs:PutLogEvents. The instance role needs ssm:UpdateInstanceInformation, ssm:DescribeAssociation, etc. (provided by AmazonSSMManagedInstanceCore).
Configuration and Verification Commands
1. Install SSM Agent (if not present):
# Amazon Linux 2 (pre-installed)
sudo yum install -y amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent2. Verify Agent is Running:
sudo systemctl status amazon-ssm-agent
sudo journalctl -u amazon-ssm-agent -f # View logs3. Start a Session from CLI:
aws ssm start-session --target i-1234567890abcdef04. Check Instance is Managed:
aws ssm describe-instance-information --filters "Key=ResourceType,Values=EC2Instance"Look for PingStatus: Online.
5. Configure Session Manager Preferences (Console): - Enable CloudWatch logging: specify log group and region. - Enable S3 logging: specify bucket, prefix, and encryption. - Set idle session timeout (e.g., 30 minutes). - Enable Run As support (Linux only) to run commands as a different user.
Interaction with Related Technologies
AWS CloudTrail: Captures API calls like StartSession, TerminateSession, ResumeSession. Use for auditing.
Amazon CloudWatch Logs: Stream session logs to a log group. Agent sends input/output as log events.
Amazon S3: Store session logs as files. Optionally encrypt with SSE-S3 or SSE-KMS.
AWS KMS: Encrypt session data in transit and at rest. Session Manager uses TLS for transport. For S3 logging, KMS keys can encrypt logs.
AWS IAM: Central access control. Use tags to restrict sessions to specific instances or users.
AWS PrivateLink: VPC endpoints for private connectivity without internet.
SSH Tunneling: Session Manager supports port forwarding (e.g., aws ssm start-session --target i-xxx --document-name AWS-StartPortForwardingSession --parameters portNumber=3389). This allows RDP to a Windows instance without opening port 3389.
Security Benefits Over SSH
No SSH keys to manage or rotate.
No bastion hosts to patch and secure.
No inbound security group rules for SSH.
All sessions are logged and can be reviewed.
Access can be revoked instantly by changing IAM policies.
Session activity can be monitored in real-time with CloudWatch Logs.
Common Troubleshooting
Instance not showing as managed: Check SSM Agent is running, IAM role is attached, and outbound connectivity to SSM endpoints. Verify VPC endpoints if in private subnet.
Cannot start session: Check IAM user permissions (ssm:StartSession) and instance role. Check that the instance is in Online state.
Session idle timeout: Adjust preferences. Max idle timeout is 60 minutes.
Logging not working: Verify IAM permissions for S3 or CloudWatch Logs. Ensure log group exists.
Exam Tip
The exam often presents scenarios where you need to choose between Session Manager and a bastion host. The deciding factors are: security (no open ports), auditing (built-in logging), and cost (no extra bastion instance). Also, remember that Session Manager does not require the instance to have a public IP address – it works with private instances via VPC endpoints.
Prerequisites and Agent Registration
Ensure the EC2 instance has the SSM Agent installed and running. Attach an IAM role with the AmazonSSMManagedInstanceCore policy. The agent registers with the SSM service by sending a registration request over HTTPS (port 443). The service assigns a unique instance ID. The agent then sends heartbeats every 5 minutes to maintain the managed status. If the instance is in a private subnet, create VPC endpoints for ssm, ssmmessages, and ec2messages. Without these, the instance cannot reach the SSM service.
User Initiates Session via CLI or Console
The user runs `aws ssm start-session --target i-xxx` or clicks 'Start session' in the Console. The AWS CLI or Console authenticates the user via IAM. The SSM service checks if the user has `ssm:StartSession` permission and if the target instance is managed. If authorized, the service creates a session record and sends a message to the SSM Agent on the instance over the existing outbound connection.
WebSocket Connection Establishment
The SSM Agent receives the session request and opens a WebSocket connection back to the SSM service. This WebSocket is encrypted with TLS. The user's client also establishes a WebSocket to the SSM service. The service now acts as a relay, forwarding data between the client and the agent. No direct network connection exists between the client and the instance. The session is now active.
Interactive Shell and Logging
The user interacts with the shell. All input and output (keystrokes, command output) are sent over the WebSocket through the SSM service. If logging is enabled, the agent sends the session data to CloudWatch Logs or S3. The agent can also support 'Run As' to execute commands as a different OS user. The idle session timer starts; if no input for the configured timeout, the session is terminated.
Session Termination and Cleanup
The user types `exit` or closes the terminal. The client sends a termination signal to the SSM service. The service closes the WebSocket with the client and sends a termination message to the agent. The agent terminates the shell process and closes its WebSocket. The session record is updated with end time. CloudTrail logs the `TerminateSession` API call. Logs are finalized in CloudWatch or S3.
Enterprise Scenario 1: Secure Access for a Financial Services Company
A financial services company manages hundreds of EC2 instances across multiple VPCs. Previously, they used bastion hosts with SSH keys. The security team was concerned about key management and the attack surface of open SSH ports. They migrated to SSM Session Manager. They created VPC endpoints for SSM in each VPC so that instances in private subnets could communicate with the SSM service without internet access. They attached the AmazonSSMManagedInstanceCore IAM role to all instances. They then configured Session Manager preferences to log all sessions to CloudWatch Logs with a retention policy of 7 years for compliance. IAM policies were written to allow only senior engineers to start sessions on production instances, using resource tags. The result: no inbound SSH ports, no bastion hosts, full audit trail, and instant revocation of access when an engineer left the company.
Enterprise Scenario 2: RDP Access Without Opening Port 3389
A healthcare organization needed to provide RDP access to Windows instances for administrators, but compliance required that no inbound RDP ports be open. They used Session Manager's port forwarding feature. Administrators run the following command to start a port forwarding session:
aws ssm start-session --target i-xxx --document-name AWS-StartPortForwardingSession --parameters portNumber=3389,localPortNumber=13389Then they connect their RDP client to localhost:13389. The traffic is tunneled through the SSM service to the instance's port 3389. No security group rule for RDP is needed. The session is logged and audited.
Common Pitfalls and Misconfigurations
Missing VPC endpoints: If instances are in private subnets without NAT or VPC endpoints, they cannot reach the SSM service. The instance will show as 'Offline' or 'Unreachable' in the Fleet Manager.
Incorrect IAM permissions: Users need ssm:StartSession on the instance resource. If they have only ssm:StartSession on *, but the instance has a tag-based policy restricting access, sessions fail.
Idle timeout too short: Default idle timeout is 20 minutes. If engineers run long scripts without input, the session may be terminated prematurely. Adjust preferences accordingly.
Logging not configured: Without logging, there is no audit trail. The exam may test that you must enable logging in Session Manager preferences, not just in CloudTrail.
Objective Code: SOA-C02 Domain 4.1 – Implement secure network and access controls
Session Manager is tested under this objective. The exam expects you to know:
How to configure Session Manager for secure access.
The prerequisites (SSM Agent, IAM role, VPC endpoints).
How to log sessions to S3 or CloudWatch Logs.
How to use port forwarding for RDP/SSH without opening inbound ports.
How to restrict access using IAM policies and tags.
Common Wrong Answers and Why Candidates Choose Them
1. 'Session Manager requires the instance to have a public IP address.' - *Why wrong*: Session Manager works with private instances via VPC endpoints. Candidates confuse it with traditional SSH which requires public IP or bastion.
2. 'Session Manager uses SSH keys for authentication.' - *Why wrong*: Session Manager uses IAM for authentication, not SSH keys. Candidates familiar with SSH assume keys are needed.
3. 'Session Manager requires inbound port 443 to be open.' - *Why wrong*: The connection is outbound from the instance. Inbound is not needed. Candidates think of client-server model.
4. 'Session Manager can only be used from the AWS Management Console.' - *Why wrong*: It also works via AWS CLI and SDK. Candidates may only have used the Console.
Specific Numbers and Values to Memorize
Default idle session timeout: 20 minutes (configurable up to 60).
Max session duration: 1440 minutes (24 hours).
SSM Agent heartbeat interval: 5 minutes.
Required VPC endpoints: ssm, ssmmessages, ec2messages.
IAM managed policy for instances: AmazonSSMManagedInstanceCore.
CLI command: aws ssm start-session --target instance-id.
Edge Cases and Exceptions
Run As support: Only for Linux instances. Allows executing commands as a different OS user (e.g., root). Configured in Session Manager preferences.
KMS encryption: Session data is encrypted in transit via TLS. For logging to S3, you can use SSE-KMS. For CloudWatch, KMS encryption is at the log group level.
Cross-account sessions: Not natively supported. You would need to assume a role in the target account.
Session Manager does not support file transfer natively. Use aws ssm send-command or S3 for file transfer.
How to Eliminate Wrong Answers
If the question mentions 'no inbound ports', 'no bastion', 'no SSH keys', the answer is likely Session Manager.
If the question requires auditing of shell commands, Session Manager with logging is correct.
If the question involves a private instance without internet, look for VPC endpoints as part of the solution.
If the question mentions 'port forwarding', Session Manager can do that.
Eliminate options that require SSH keys or bastion hosts when the scenario demands zero-trust access.
Session Manager provides secure, auditable shell access without opening inbound ports or managing SSH keys.
Instances must have the SSM Agent installed and an IAM role with AmazonSSMManagedInstanceCore.
For private instances, create VPC endpoints for ssm, ssmmessages, and ec2messages.
Session logging must be explicitly enabled in Session Manager preferences – CloudTrail only logs API calls.
Default idle session timeout is 20 minutes; maximum session duration is 1440 minutes.
Port forwarding allows RDP/SSH access through Session Manager without inbound rules.
IAM policies control who can start sessions and on which instances (using tags).
These come up on the exam all the time. Here's how to tell them apart.
SSM Session Manager
No inbound ports required; instances only need outbound HTTPS.
No SSH keys to manage; access via IAM policies.
Built-in session logging to S3 or CloudWatch Logs.
No additional EC2 instance to manage; no patching of bastion.
Works with private instances via VPC endpoints.
Bastion Host (Jump Box)
Requires inbound SSH (port 22) or RDP (3389) on bastion.
Requires SSH key pairs or password management.
Logging must be set up separately (e.g., auditd, syslog).
Bastion host is an EC2 instance that must be patched and secured.
Bastion must have a public IP or be reachable via VPN.
Mistake
Session Manager requires the instance to have a public IP address.
Correct
Session Manager works with private instances using VPC endpoints (ssm, ssmmessages, ec2messages). No public IP is needed.
Mistake
Session Manager uses SSH keys for authentication.
Correct
Session Manager uses IAM for authentication and authorization. No SSH keys are involved.
Mistake
Session Manager requires inbound security group rules on port 443.
Correct
The instance initiates outbound HTTPS connections to the SSM service. No inbound rules are needed.
Mistake
Session Manager can only be used from the AWS Management Console.
Correct
Session Manager is also accessible via AWS CLI and SDK. The command `aws ssm start-session` is commonly used.
Mistake
Session Manager automatically logs all sessions to CloudTrail.
Correct
CloudTrail logs API calls (StartSession, TerminateSession), but session input/output logging must be explicitly configured in Session Manager preferences to S3 or CloudWatch Logs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Go to Systems Manager > Session Manager > Preferences. Under 'Logging', enable S3 logging (specify bucket and prefix) or CloudWatch logging (specify log group and region). You need IAM permissions for the instance role to write to S3 or CloudWatch. For CloudWatch, the log group must exist. Once enabled, all session input/output is streamed to the destination.
Yes, by using VPC endpoints. Create interface endpoints for ssm, ssmmessages, and ec2messages in the same VPC and subnet. Attach security groups that allow outbound HTTPS to these endpoints. The instance can then communicate with the SSM service without internet access.
Session Manager provides interactive one-to-one shell sessions (like SSH). Run Command is for running scripts or commands on multiple instances at once (one-to-many). Both use the SSM Agent, but Session Manager is interactive and supports port forwarding, while Run Command is for automation.
Use IAM policies with conditions based on resource tags. For example, allow ssm:StartSession only if the instance has the tag 'Environment:Production'. Also, you can use the 'ssm:resourceTag' condition key. The user needs ssm:StartSession permission on the instance ARN.
No, Session Manager does not natively support file transfer. To transfer files, use AWS Systems Manager Run Command with an S3 bucket, or use the AWS CLI to copy files via S3. Alternatively, you can use port forwarding to tunnel SCP or SFTP, but it's not built-in.
The instance will be marked as 'Offline' or 'Unreachable' in the Systems Manager console after missing heartbeats for 30 minutes. You cannot start a session. Check the agent logs (/var/log/amazon/ssm/amazon-ssm-agent.log) and ensure the agent is running and has network connectivity.
Yes, if you install the SSM Agent on the on-premises server and register it as a managed instance. The server must have outbound HTTPS access to the SSM service. You need to create a managed instance activation (activation code and ID) to register the server.
You've just covered SSM Session Manager for Secure Access — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?