An Overview of AWS Systems Manager (SSM)
Session Manager,
Focus:
- Tailored for DevOps / SRE / DevSecOps.
Breakdown:
- The concept: Session Manager Is (and 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.
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
and 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.
- Clues for connection failures can often be
found in the SSM Agent logs located at
/var/log/amazon/ssm/amazon-ssm-agent.logfor Linux.
Official documentation link,
https://docs.aws.amazon.com/systems-manager/latest/userguide/docconventions.html
1. The concept: 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
# 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)
# bashaws 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.
- AWS Systems Manager (SSM) Session Manager provides interactive one-click shell access to Amazon EC2 instances, edge devices, and on-premises servers.
Step-1:
- Search for AWS EC2 service and create an: Instance (virtual machine or server in cloud)
Launch Instance:
Proceed without a key pair because: SSH is not needed (to fortifies the security Posture)
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 (show all instance registered with SSM
roles)
Step-5:
- Once the instance features on fleet manager and show
Online status, twtech can start running secure shell on it.
- Return 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 can run commands like:
ping google.com
ping think-with-tech.blogspot.com
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:
twtech can at this point successfully access instances via:
- SSH Connect via port: 22 (+ key pair)
- EC2 instance connect, ( port 22 must be opened for SSH
forwarding)
- Session manager ( No SSH, No ports opened to access the
instance, but
SSM
IAM role must be attached to instance to access internet)
No comments:
Post a Comment