AWS Systems Manager (SSM) Session Manager | Overview & Hands-On.

AWS Systems Manager (SSM) Session Manager - Overview & Hands-On.

Focus:

• Tailored for:
• DevOps 
• SRE 
• DevSecOps.

Scope:

• Intro,
• Key Features and Benefits,
• Prerequisites for Setup,
• Configuration & Usage,
• Troubleshooting Common Issues,
• Link to Official documentation,
• The concept of Session Manager Is & Why It Matters,
• Core Problems Session Manager Solves,
• High-Level Architecture,
• Components Breakdown,
• Network Architecture (Zero Trust Friendly),
• Logging, Auditing & Compliance,
• Security Controls (DevSecOps Focus),
• Session Manager vs Bastion Host,
• Advanced Use Cases,
• Cost Model,
• Common Failure Points (and Fixes),
• Best Practices (Enterprise-Grade).
• Where Session Manager Fits in Modern Cloud Architecture,
• Project: Hands-On.

Intro:

• AWS Systems Manager (SSM) Session Manager is a fully managed capability that allows for:
• secure, 
• audited instance management without the need to:
• open inbound ports, 
• maintain bastion hosts, 
• or manage SSH keys.
• AWS Systems Manager (SSM) Session Manager provides:
• Interactive one-click shell access to Amazon EC2 instances, 
• Edge devices, 
• And on-premises servers.

Key Features and Benefits

No Inbound Ports Required: (better Security posture)

•  Communication occurs via the SSM Agent using an outbound connection over HTTPS on port 443.

Centralized Access Control:

•  Administrators can grant or deny access to instances through IAM policies, eliminating the need for individual SSH keys.

Enhanced Security:

• Session Manager can be used in conjunction with AWS PrivateLink to keep traffic within the AWS network.

Auditing and Logging:

•  It tracks session activity, providing a record of who accessed which instance and what commands were run.

Prerequisites for Setup

SSM Agent Installation:

• The instance must have the SSM Agent installed. It is pre-installed on many official AWS AMIs, such as Amazon Linux 2 and AL2023.

IAM Permissions:

• Instances must be associated with an IAM role that has the necessary permissions to communicate with the Systems Manager service.

Connectivity:

• Managed nodes must have internet connectivity or be configured with VPC endpoints to reach the SSM service. 

Configuration & Usage

ssm-user Account:

• By default, Session Manager creates a local user named ssm-user on the managed node.
• This user is granted administrative permissions by default, which can be modified or disabled as needed.

Session Preferences:

• Administrators can configure specific settings, such as idle session timeouts, maximum session duration, and KMS key encryption for session data.

CLI Access:

•  To use Session Manager via the AWS CLI, users must install the Session Manager plugin on their local machine.

Run As Support:

• On Linux and macOS nodes, twtech can enable "Run As" support to allow users to start sessions as a specific OS user, such as ec2-user, instead of the default ssm-user,

Troubleshooting Common Issues

Instance Not Appearing:

•  If an instance is not visible in Systems Manager, check if the SSM Agent is running (using sudo status amazon-ssm-agent) and verify the instance's IAM role permissions.

Connection Failures:

• Ensure the instance can reach the SSM endpoint on port 443. Check security group rules, NAT gateways, or VPC endpoint configurations.

Agent Logs:

• Clues for connection failures can often be found in the SSM Agent logs located at /var/log/amazon/ssm/amazon-ssm-agent.log for Linux.

Link to Official documentation 

https://docs.aws.amazon.com/systems-manager/latest/userguide/docconventions.html

1. The concept of Session Manager Is (and Why It Matters)

• SSM Session Manager is a fully managed, secure interactive access service that lets twtech connect to:
• EC2 instances
• On-prem servers
• Hybrid / edge nodes
• ECS tasks (with exec integration)

 Without:

• SSH keys
• Bastion hosts
• Open inbound ports
• Jump boxes
• VPN (in many cases)

NB:

• SSM Session Manager replaces traditional SSH/RDP with IAM-based, auditable, encrypted access.

2. Core Problems Session Manager Solves

Traditional Access	Session Manager
SSH keys everywhere	IAM + temporary credentials
Bastion hosts	No bastions needed
Port 22 / 3389 open	Zero inbound ports
Poor auditing	Full session logging
Hard to revoke access	IAM policy change = instant
Weak compliance story	SOC2, HIPAA, PCI friendly

3. High-Level Architecture

Key Points

•  Outbound-only connectivity from instances
•  Uses AWS-managed endpoints
•  Sessions are stateful, encrypted, and logged
•  Works across accounts & regions

4. Components Breakdown

4.1 SSM Agent

• Installed by default on:
•    Amazon Linux
•    Ubuntu
•    Windows AMIs
• Communicates with:
•    ssm
•    ssmmessages
•    ec2messages
• Uses HTTPS (443) outbound

4.2 IAM (The Security Backbone)

# User-side permissions

# json

{

  "Effect": "Allow",

  "Action": [

    "ssm:StartSession"

  ],

  "Resource": "*"

}

# Instance role permissions

# json

{

  "Effect": "Allow",

  "Action": [

    "ssm:UpdateInstanceInformation",

    "ssmmessages:*",

    "ec2messages:*"

  ],

  "Resource": "*"

}

 # Fine-grained control:

• Restrict by instance tags
• Restrict shell vs port forwarding
• Require MFA via IAM conditions

4.3 Session Types

Session Type	Use Case
Shell session	SSH replacement
Port forwarding	Secure DB access
SSH-over-SSM	Gradual SSH migration
ECS Exec	Container shell access

5. Network Architecture (Zero Trust Friendly)

Option A: Public AWS Endpoints

• Instances need outbound internet access
• No inbound rules required

Option B: Private VPC Endpoints (Enterprise Standard)

Benefits:

•  No internet gateway required
•  Traffic stays on AWS backbone
•  Required for regulated environments

6. Logging, Auditing & Compliance

6.1 Session Logging Options

Destination	Purpose
CloudWatch Logs	Real-time session logs
S3	Long-term retention
CloudTrail	Who started/stopped sessions

NB:

• Everything typed can be logged (including commands).

6.2 Compliance Alignment

• SOC 2 – Full audit trail
• PCI-DSS – No shared credentials
• HIPAA – Encrypted, logged access
• ISO 27001 – Centralized access control

7. Security Controls (DevSecOps Focus)

# IAM Conditions (conditions are use to replace many Polieies)

# json

"Condition": {

  "Bool": {

    "aws:MultiFactorAuthPresent": "true"

  }

}

# Session Restrictions

• Disable clipboard
• Disable port forwarding
• Read-only shell (via sudo controls)
• Time-bound access via IAM roles

8. Session Manager vs Bastion Host

Feature	Bastion	Session Manager
Inbound ports	Required	❌  None
Key rotation	Manual	❌  Not needed
Auditing	Limited	✅  Full
Scaling	Manual	Automatic
Cost	EC2 + Ops	Mostly free
Blast radius	High	Low

9. Advanced Use Cases

9.1 Secure Database Access (No VPN)

# bash

aws ssm start-session \

  --target i-123456 \

  --document-name AWS-StartPortForwardingSession \

  --parameters '{"portNumber":["5432"],"localPortNumber":["5432"]}'

9.2 Break-Glass Access

•  No SSH keys required
•  IAM emergency role
•  MFA enforced
•  Logged automatically

9.3 Multi-Account Access

• Central tooling account
• Cross-account IAM role assumption
• Tag-based instance targeting

10. Cost Model

• Session Manager is free
•  twtech pays for:
•  CloudWatch Logs
•  S3 storage
•  VPC endpoints (if used)
• This makes it cheaper than:
•  Bastions
•  VPN appliances
•  Third-party access tools

11. Common Failure Points (and Fixes)

Issue	Root Cause	Fix
Instance not showing	No IAM role	Attach SSM role
Session won’t start	Agent outdated	Update SSM agent
Works in console only	CLI plugin missing	Install session-manager-plugin
No logs	Logging not configured	Enable CW/S3

12. Best Practices (Enterprise-Grade)

✅   Disable SSH entirely
✅   Enforce MFA for session access
✅   Use VPC endpoints
✅   Log everything
✅   Restrict access via tags
✅   Use temporary IAM roles
✅   Rotate instance AMIs with agent preinstalled

13. Where Session Manager Fits in Modern Cloud Architecture

•  Zero Trust access layer
•  Foundation for SRE operations
• Secure alternative to VPN
• Critical building block for regulated workloads

 

Project: Hands-On

•  How twtech uses Session Manager to fully managed capability that allows for secure, audited instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.
•   This AWS Systems Manager (SSM) Session Manager provides interactive one-click shell access to Amazon EC2 instances, edge devices, and on-premises servers within twtech environment.

Step-1:

• Search for AWS EC2 service and create an: Instance (virtual machine or server in cloud)

Launch Instance:

NB:

• Proceed without a key pair because: SSH is not needed.
• This fortifies the security Posture with twtech environment.

• Edit Network settings: uncheck or disable SSH traffic

Advanced details:

• Create a new IAM instance Profile to: talk to SSH service

Step-2:

• Create an SSM Core-role for AWS service for : EC2 (instance under creatiom)

• Filter permissions for : SSM (AmazonManagedInstanceCore)

• Name, review, and create

• Create role:

Step-3:

• Reture to the EC2 console : refresh , select and attach role ( twechSSM-core) to instance

• Launch instance

Step-4

• Search for AWS service: SSM

• On service listings under AWS System Manager (SSM) navigate to: Fleet manager .
• This tab shows all instance registered with SSM roles

Step-5:

•  Once the instance features on fleet manager show Online status, twtech can start running secure shell on it.
•  twtech Returns to AWS System Manager Console and look for: Session Manager.

• Start a Session: to get a secure shell & begin running commands

• Specify session document - optional

• Review and launch

Successfully, 

• twtech is able to access the secure shell and start running commands.

• twtech does not need SSH access: but  it can run commands like:

ping google.com

ping think-with-tech.blogspot.com

Step-6:

• How twtech terminates (stops)  a session

• How twtech accesses logs from session history:

• twtech can also enable encryption, and to send logs to AWS CloudWatch or S3 bucket:

Final thoughts:

• Session manager needs:
• No SSH, 
• No ports opened to access the instance, 
• But, SSM IAM role must be attached to instance to access internet.