AWS Systems Manager
Systems Manager (SSM) is a collection of operational tools under one umbrella for managing EC2 instances, on-prem servers, and configuration at scale: connecting without SSH, running scripts across fleets, patching, storing parameters, automating workflows, and taking inventory. Most of it works through a small agent pre-installed on standard AWS AMIs.
It is the Swiss Army knife of AWS operations — the value shows up with fleets, not a single instance.
Session Manager and Run Command
Session Manager opens an interactive shell to a managed instance through the AWS API — no open port 22, no bastion, no keys, with IAM authorization and every command logged. The right pattern is instances with no public IP, inbound traffic only through load balancers, and operators connecting via Session Manager.
Run Command runs a script or AWS-published command across many instances at once, targeted by tag — restart a service everywhere tagged Environment=production, run a one-off diagnostic — with results landing in CloudWatch Logs.
Patch Manager and Parameter Store
Patch Manager patches operating systems at scale: define a baseline, assign instances to a patch group by tag, and set a maintenance window. AWS's default baselines cover most security patches; most teams customize lightly and let the rest run on autopilot.
Parameter Store is a hierarchical key-value store for configuration — strings, KMS-encrypted SecureStrings, and lists. Standard parameters are free (up to 10,000, 4 KB each); advanced parameters add size and policies. Use it for non-rotating config and Secrets Manager for rotating credentials.
Automation, Inventory, and State Manager
Automation runs multi-step runbooks defined as documents — AWS publishes many (snapshot an instance, restart an RDS database) and you write your own for repeatable operations. Inventory collects installed software and configuration across instances for compliance and audit.
State Manager continuously enforces a configuration on managed instances on a schedule — lightweight configuration management for teams that do not need full Puppet, Chef, or Ansible.
Session Manager — operator access to instances with no open ports, IAM auth, and full audit — replacing SSH and bastions.
Run Command / State Manager — lightweight fleet operations and configuration enforcement by tag.
Puppet / Chef / Ansible — full configuration management when SSM's lightweight tools are not enough.
- Keeping port 22 open and using SSH and bastions instead of Session Manager, which needs no inbound access.
- Forgetting to attach
AmazonSSMManagedInstanceCoreto instance profiles, so Session Manager, Run Command, and Patch Manager do not work. - Storing rotating credentials in Parameter Store instead of Secrets Manager, losing built-in rotation.
- Running manual one-off commands for repeatable operations instead of auditable Automation runbooks.
- Expecting SSM to manage Lambda or Fargate — it is built around an agent on managed instances.
- Leaving long-running EC2 fleets unpatched instead of using Patch Manager with maintenance windows.
- Use Session Manager instead of SSH; close port 22 and audit sessions to CloudWatch Logs.
- Attach AmazonSSMManagedInstanceCore to every EC2 instance profile.
- Use Patch Manager with maintenance windows for any long-running EC2 fleet.
- Use Parameter Store for non-sensitive config and Secrets Manager for credentials.
- Use Automation runbooks for any operation you run more than once.
- Integrate with AWS Organizations for multi-account fleet management.
Knowledge Check
What is the main security advantage of Session Manager over SSH?
- It needs no open inbound port or bastion — access runs through the AWS API with IAM auth and full audit
- It transparently encrypts each instance's attached EBS disk volumes for you whenever a new session opens
- It opens a faster, lower-latency shell connection than plain SSH
- It works without configuring any IAM permissions at all
Which SSM capability runs a script across many instances at once, targeted by tag?
- Run Command
- Parameter Store
- Inventory
- Patch Manager
For a rotating database password, which is the right store?
- Secrets Manager — Parameter Store lacks built-in rotation
- A KMS-encrypted Parameter Store SecureString value type
- A State Manager association that resets the password nightly
- An Automation runbook that stores the value
What kind of workload is Systems Manager NOT built for?
- Lambda functions and Fargate tasks — SSM is built around an agent on managed instances
- Long-running EC2 fleets that need regular operating-system patching on a fixed schedule
- On-prem servers brought under management as hybrid nodes
- Storing application configuration parameters and flags
You got correct