AWS Systems Manager —
Operational Hub for Hybrid Cloud
Systems Manager (SSM) is the unified operations centre for AWS and on-premises infrastructure. It handles patching, configuration, secrets, automation, remote access, and inventory — all without needing SSH or RDP.
What is AWS Systems Manager?
AWS Systems Manager (SSM) is a collection of operational tools for managing infrastructure at scale. It provides a single pane of glass for patching, configuration, parameter/secret management, remote access, inventory, and automation — across both AWS and on-premises servers.
IT Control Room
- Central dashboard showing all servers
- Remote into any machine without walking to it
- Push patches to 1,000 servers at once
- Store passwords in a locked cabinet, not sticky notes
- Run maintenance scripts on a schedule
Systems Manager
- Fleet Manager shows all managed instances
- Session Manager — browser-based shell, no SSH keys
- Patch Manager — OS and application patching at scale
- Parameter Store — encrypted config and secrets
- Automation — multi-step runbooks on schedule or event
Everything in Systems Manager requires the SSM Agent running on managed instances:
| Requirement | Details |
|---|---|
| SSM Agent | Pre-installed on Amazon Linux 2/2023, Ubuntu 16.04+, Windows Server 2016+. Must be installed manually on on-prem or other OSes. |
| IAM Role | EC2 instances need an instance profile with AmazonSSMManagedInstanceCore policy |
| Network | Outbound HTTPS to SSM endpoints (port 443). No inbound ports required — agent polls the service. |
| On-premises | Install agent + create hybrid activation (activation code + ID). Instances appear with prefix mi- |
Parameter Store
Hierarchical config & secret storage with encryption, versioning, and IAM access control
Patch Manager
Automated OS and application patching with baselines, schedules, and compliance reporting
Run Command
Execute commands on managed instances at scale without SSH — with output logging
Session Manager
Browser-based shell access — no SSH keys, no bastion hosts, full audit trail in CloudTrail
Automation
Multi-step runbooks (SSM Documents) for operational tasks — e.g., AMI creation, patching workflows
Inventory
Collect metadata from instances — installed software, OS versions, network config, Windows updates
- "Manage instances without SSH" → Systems Manager (Session Manager) — requires SSM Agent + IAM role, no inbound ports
- "SSM Agent pre-installed?" → Yes on Amazon Linux 2/2023, Ubuntu 16.04+, Windows Server 2016+
- "On-premises server management" → Install SSM Agent + hybrid activation → managed as
mi-*instances - "SSM requires what IAM policy?" →
AmazonSSMManagedInstanceCoreon EC2 instance profile
Systems Manager is a collection of operational tools unified under one service — Parameter Store, Patch Manager, Run Command, Session Manager, Automation, and Inventory. The SSM Agent (pre-installed on modern AMIs) communicates outbound over HTTPS — no SSH/RDP ports needed. Instances need an IAM role with AmazonSSMManagedInstanceCore. On-premises servers use hybrid activations.
Parameter Store & Secrets Management
SSM Parameter Store provides secure, hierarchical storage for configuration data and secrets — database connection strings, API keys, license codes, and feature flags. It's the recommended alternative to hard-coding values in application code.
| Type | Use Case | Encryption | Max Size |
|---|---|---|---|
String | Plain text config (AMI ID, URL) | None | 4 KB (standard) / 8 KB (advanced) |
StringList | Comma-separated values | None | 4 KB / 8 KB |
SecureString | Passwords, DB connection strings, API keys | KMS encryption | 4 KB / 8 KB |
Parameters use a path-based hierarchy — like a filesystem:
/myapp/prod/db/connection-string/myapp/prod/db/password(SecureString)/myapp/staging/db/connection-string/shared/ami/amazon-linux-latest
Use GetParametersByPath to fetch all parameters under /myapp/prod/ in one call. IAM policies can scope access to specific paths: arn:aws:ssm:*:*:parameter/myapp/prod/*.
| Feature | Standard | Advanced |
|---|---|---|
| Max parameters per account | 10,000 | 100,000 |
| Max value size | 4 KB | 8 KB |
| Parameter policies (TTL, expiry) | No | Yes |
| Cost | Free | $0.05/parameter/month |
| Higher throughput | 40 TPS default | 1,000 TPS ($0.05/10K interactions) |
| Feature | Parameter Store | Secrets Manager |
|---|---|---|
| Automatic rotation | No (manual via Lambda) | Yes — built-in for RDS, Redshift, DocumentDB |
| Cross-account sharing | No (reference by ARN only) | Yes — resource policies |
| Cross-region replication | No | Yes |
| KMS encryption | Optional (SecureString) | Always encrypted |
| Cost | Free (standard) | $0.40/secret/month + $0.05/10K API calls |
| Versioning | Yes (labels) | Yes (staging labels) |
| Integration | SSM ecosystem, CloudFormation, SDKs | RDS, Redshift, Lambda, ECS, EKS |
Need auto-rotation for RDS/Redshift? → Secrets Manager. Need cross-account or cross-region secret sharing? → Secrets Manager. Just storing config values or simple secrets without rotation? → Parameter Store (free). Budget-conscious? → Parameter Store SecureString is free with KMS.
- "Store DB password encrypted, free" → Parameter Store SecureString (KMS encrypted, standard tier free)
- "Auto-rotate RDS credentials" → Secrets Manager (not Parameter Store)
- "Fetch all config for an environment" →
GetParametersByPath(/myapp/prod/) - "Parameter Store max throughput" → 40 TPS standard, 1,000 TPS advanced ($)
- "Expiring parameter (TTL)" → Advanced parameter with parameter policy
- "Cross-account secret sharing" → Secrets Manager (resource policies), not Parameter Store
Parameter Store provides free, hierarchical, versioned storage for config and secrets. SecureString type encrypts with KMS. Use path-based naming (/app/env/key) for organisation and IAM scoping. Standard tier is free (10K params, 4 KB). Choose Secrets Manager over Parameter Store when you need automatic rotation, cross-account sharing, or cross-region replication.
Patch Manager & Run Command
Patch Manager automates the process of patching managed instances with OS and application updates. Run Command executes commands on instances at scale without SSH. Together they form the core operational toolkit.
| Concept | What It Does |
|---|---|
| Patch Baseline | Defines which patches are approved/rejected (by severity, classification, auto-approve after N days) |
| Patch Group | EC2 tag (Patch Group = Production) that associates instances with a baseline |
| Maintenance Window | Scheduled time window (e.g., Sunday 2 AM–5 AM) when patches are applied |
| Scan vs Install | Scan = report compliance only. Install = scan + apply missing patches + optional reboot |
| Compliance | Dashboard showing compliant/non-compliant instances + missing patches |
What Run Command Does
- Execute commands on 1 or 1,000+ instances simultaneously
- No SSH/RDP needed — uses SSM Agent
- Uses pre-built or custom SSM Documents
- Target by tags, instance IDs, or resource groups
- Rate control: max concurrent + max errors before stop
Common SSM Documents
AWS-RunShellScript— run bash on LinuxAWS-RunPowerShellScript— run PS on WindowsAWS-RunPatchBaseline— scan or install patchesAWS-ConfigureAWSPackage— install software (e.g., CloudWatch Agent)AWS-UpdateSSMAgent— update the SSM Agent itself
Run Command output can be sent to S3 (full output) and CloudWatch Logs (streaming). All command executions are logged in CloudTrail. For long-running commands (>2.5 hours), use SSM Automation instead.
- "Patch all production servers on Sunday" → Patch Manager + maintenance window + patch group tag
- "Run a script on 500 instances" → Run Command with
AWS-RunShellScript - "Check patch compliance without patching" → Patch Manager scan operation (not install)
- "Install CloudWatch Agent on all instances" → Run Command with
AWS-ConfigureAWSPackage - "Rate-limit command execution" → Max concurrency + max errors in Run Command
Patch Manager automates patching with baselines (approved patches), maintenance windows (scheduled time), and patch groups (EC2 tags). Scan reports compliance; Install applies patches. Run Command executes commands at scale without SSH — target by tags, control rate, log output to S3/CloudWatch. Both use SSM Documents (pre-built or custom YAML/JSON templates).
Session Manager, Inventory & State Manager
Session Manager replaces SSH/RDP with secure, auditable, browser-based shell access. Inventory collects metadata from instances. State Manager enforces desired configuration continuously.
Why Session Manager
- No SSH keys to manage or rotate
- No bastion hosts — direct secure access
- No inbound ports — port 22/3389 closed
- IAM-controlled — who can start sessions
- Full audit trail — every keystroke logged
- Works through AWS PrivateLink (no internet needed)
Security Features
- Session logs → S3 and/or CloudWatch Logs
- Session activity logged in CloudTrail
- KMS encryption for session data in transit
- IAM policies control: who, which instances, when
- Can enforce run-as user (e.g., root/ec2-user)
- Port forwarding for RDS, databases, internal services
Replace SSH entirely with Session Manager. Close port 22 on all security groups. Use Session Manager port forwarding for database access (aws ssm start-session --target i-xxx --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters host=mydb.rds.amazonaws.com,portNumber=5432,localPortNumber=5432).
SSM Inventory collects metadata from managed instances and stores it centrally:
| Data Collected | Examples |
|---|---|
| Applications | Installed software, versions, publishers |
| AWS components | SSM Agent version, CloudWatch Agent |
| Network config | IP addresses, MAC addresses, DNS settings |
| Windows updates | Installed KB patches, update history |
| Instance details | OS name, version, hostname, CPU, RAM |
| Custom inventory | Your own metadata (rack location, business unit) |
Inventory data can be synced to S3 (via Resource Data Sync) and queried with Athena for fleet-wide analysis (e.g., "which instances run Java 8?").
State Manager ensures instances stay in a defined state by applying SSM Documents on a schedule or at launch:
How It Works
- Create an association: SSM Document + target instances + schedule
- State Manager applies the document automatically
- If instance drifts, re-applies on next schedule
- Reports compliance status per association
Common Use Cases
- Ensure CloudWatch Agent is always installed + running
- Apply security baseline on every launch
- Join instances to Active Directory domain
- Keep SSM Agent updated automatically
- "Secure access without SSH keys or bastion" → Session Manager
- "Audit every command typed on instances" → Session Manager with logging to S3/CW Logs
- "Find all instances running outdated OpenSSL" → SSM Inventory → Athena query
- "Ensure CloudWatch Agent always installed" → State Manager association
- "Port 22 must be closed — how to access?" → Session Manager (uses HTTPS, port 443 outbound)
- "Access RDS without public endpoint" → Session Manager port forwarding
Session Manager replaces SSH with IAM-controlled, auditable, browser-based shell access — no keys, no bastion hosts, no inbound ports. Inventory collects fleet metadata (software, OS, network) — sync to S3 and query with Athena. State Manager enforces desired configuration by applying SSM Documents on a schedule — if instances drift, it re-applies. Together they provide access, visibility, and configuration enforcement.
Automation, Documents & Cost
SSM Automation orchestrates multi-step operational workflows using runbooks — from AMI creation to incident response to Config remediation. It's the engine behind many AWS auto-remediation patterns.
What Automation Does
- Multi-step runbooks (SSM Documents type: Automation)
- Steps can: run commands, invoke Lambda, call APIs, approve, wait
- Built-in error handling and rollback
- Triggered manually, on schedule, or by EventBridge
- Cross-account and cross-region execution
Common Automation Runbooks
AWS-CreateImage— create AMI from running instanceAWS-StopEC2Instance/AWS-StartEC2InstanceAWS-RestartEC2Instance— stop, wait, startAWS-DisableS3BucketPublicReadWrite— Config remediationAWS-PatchInstanceWithRollback— patch + rollback on failure
| Document Type | Used By | Example |
|---|---|---|
| Command document | Run Command, State Manager | AWS-RunShellScript |
| Automation document | SSM Automation, Config remediation | AWS-CreateImage |
| Session document | Session Manager | AWS-StartInteractiveCommand |
| Package document | Distributor | Custom software packages |
| Policy document | State Manager | Inventory collection policy |
The most powerful SSM pattern: Config rule detects non-compliance → triggers SSM Automation runbook → auto-remediates the resource → Config re-evaluates → compliant. This is the engine behind AWS Config auto-remediation. You can also trigger Automation from EventBridge rules for any operational event.
Change Manager
- Approval workflows for operational changes
- Change templates with required approvers
- Integration with SSM Automation for execution
- Audit trail of who approved what
- SNS notifications for pending approvals
Change Calendar
- Define allowed/blocked time windows for changes
- Calendar state: OPEN (changes allowed) or CLOSED
- Automation checks calendar before executing
- Prevent changes during: holidays, peak hours, launches
- Integrates with Change Manager and Automation
| Feature | Cost |
|---|---|
| Parameter Store (standard) | Free (up to 10,000 parameters, 40 TPS) |
| Parameter Store (advanced) | $0.05/parameter/month |
| Run Command | Free |
| Session Manager | Free |
| Patch Manager | Free (AWS instances), $5/server/month (on-prem) |
| Automation | Free (first 100K steps/month), $0.00025/step after |
| State Manager | Free |
| Inventory | Free |
| Change Manager | $0.36/change request |
| OpsCenter | $0.00356/OpsItem |
Most SSM features are free — Parameter Store (standard), Run Command, Session Manager, State Manager, Inventory, and Patch Manager for AWS instances. The main costs come from: advanced parameters, on-premises patch management ($5/server/month), Change Manager, and high-volume automation steps.
| Need | SSM Solution | Third-Party Alternative |
|---|---|---|
| Remote access | Session Manager | SSH + bastion, Teleport |
| Config management | State Manager | Ansible, Chef, Puppet |
| Patching | Patch Manager | WSUS, SCCM, Ansible |
| Secrets | Parameter Store | HashiCorp Vault, Doppler |
| Automation | SSM Automation | Ansible, Terraform, Jenkins |
- "Create AMI automatically" → SSM Automation
AWS-CreateImage - "Multi-step operational workflow with approval" → Change Manager + Automation
- "Block changes during peak hours" → Change Calendar (CLOSED state)
- "Config remediation engine" → SSM Automation documents (behind Config auto-remediation)
- "Free operational tools" → Run Command, Session Manager, State Manager, Inventory, standard Parameter Store — all free
- "On-prem patching cost" → $5/instance/month (managed by SSM)
SSM Automation orchestrates multi-step runbooks for operational tasks — triggered manually, on schedule, or by EventBridge/Config. SSM Documents are the building blocks (command, automation, session, package, policy types). Change Manager adds approval workflows; Change Calendar blocks changes during sensitive periods. Most SSM features are free — the service is remarkably cost-effective for its breadth of capabilities.
Systems Manager — Complete Domain Summary
- Foundation — SSM Agent (pre-installed on modern AMIs) + IAM instance profile + outbound HTTPS. No SSH/inbound ports needed.
- Parameter Store — free hierarchical config/secret storage. SecureString encrypts with KMS. Use Secrets Manager when you need auto-rotation or cross-account sharing.
- Patch Manager — baselines define approved patches, maintenance windows schedule, patch groups target via tags. Scan or install mode.
- Run Command — execute commands at scale without SSH using SSM Documents. Target by tags, control rate, log to S3/CloudWatch.
- Session Manager — replaces SSH/RDP entirely. IAM-controlled, auditable, encrypted. No keys, no bastions, no inbound ports.
- Automation — multi-step runbooks for operational workflows. Powers Config auto-remediation. Change Manager adds approvals; Change Calendar blocks changes.
- Cost — most features free (Run Command, Session Manager, State Manager, Inventory, standard Parameter Store). On-prem patching: $5/server/month.