Imagine managing five hundred servers. Logging into each one individually to apply security patches, install software, and check status is practically impossible. AWS Systems Manager (SSM) solves this problem with centralized, automated management.
What is Systems Manager?
Think of Systems Manager as the building management system for a large apartment complex. The building manager does not visit each apartment individually. From a central control room, they can see the status of every unit, handle problems remotely, and schedule maintenance for entire floors at once.
There are two prerequisites before you can use Systems Manager with any EC2 instance. First, the SSM Agent must be installed on the instance. Most official AWS-provided AMIs like Amazon Linux 2 and Windows Server already have it pre-installed. Custom AMIs you create yourself will need it installed manually. Second, the EC2 instance needs an IAM role with the AmazonSSMManagedInstanceCore policy attached. Without this role, the instance cannot communicate with the Systems Manager service.
If either of these prerequisites is missing, none of the Systems Manager features will work on that instance.
Patch Manager — Automating Security Patches
You run an online store and the security team says "apply the latest security patches to all servers by Friday midnight." If you have two hundred servers, how do you do that? Patch Manager handles it.
Patch Manager starts with Patch Baselines, which are rules that define which patches to automatically approve. AWS provides a default baseline that automatically approves security patches after seven days. You can create custom baselines to approve specific patches immediately or permanently block certain patches you do not want installed.
Once you have a patch baseline, you need to decide when to apply patches. That is where Maintenance Windows come in. You define a time window like "every Sunday from 2 AM to 4 AM" — a time when your service traffic is low. During that window, Patch Manager automatically applies the approved patches to the targeted instances.
Exam tip: "Automate EC2 patching outside of business hours" — the answer is Patch Manager plus Maintenance Window.
Run Command — Remote Commands Without SSH
You need to deploy a new configuration file to two hundred servers. The traditional approach is SSH into each server, run the command, repeat. You need SSH keys, open port 22 in security groups, and repeat the process hundreds of times. Run Command eliminates all of this.
With Run Command, you type the command once in the AWS console or CLI, select your target instances using tags or instance IDs, and the command runs on all of them simultaneously.
Here are the key characteristics. No SSH keys are needed at all. You do not need to open port 22 in any security group. If your instances have tags like Environment=Production and Role=WebServer, you can say "run this command on all Production WebServer instances" and it targets them automatically. Results are saved to S3 or CloudWatch Logs automatically. The Rate Control feature lets you set how many instances run simultaneously and how many failures to allow before stopping.
Exam tip: "Run scripts on hundreds of EC2 instances simultaneously without SSH" — the answer is Run Command.
Session Manager — Secure Server Access
The development team needs to log into a production server to check some logs. Traditionally this means issuing SSH keys or routing through a bastion host. Session Manager simplifies all of this.
Session Manager lets you connect to an EC2 instance without SSH, RDP, bastion hosts, or any inbound security group rules. You click the "Connect" button in the AWS console and a browser-based terminal opens. You can also connect via the AWS CLI.
From a security perspective, Session Manager is exceptionally strong. Every session is automatically recorded in AWS CloudTrail. You always have a record of who accessed which server and when. If you want, the full content of every session — every command typed and every output shown — can be saved to S3 or CloudWatch Logs.
You control access through IAM policies. You can restrict access to specific instances, only during certain hours, or require MFA before connecting.
Exam tip: "Security team needs to audit all server access" or "Connect to EC2 without SSH" — the answer is Session Manager.
State Manager — Keeping Instances in the Desired State
Suppose a critical monitoring agent must always be running on every server. But someone accidentally stops it, or a bad deployment removes it. State Manager prevents drift from desired configuration.
State Manager maintains a "desired state" for your instances. You create an Association that says "these instances must always be in this configuration." State Manager periodically checks each instance and if it has drifted from the desired state, it automatically remediates.
An example: "CloudWatch Agent must always be installed and running on all EC2 instances." With that Association in place, if the agent is stopped or uninstalled, State Manager reinstalls and restarts it automatically.
Automation — Building Self-Healing Runbooks
At 3 AM your production server's CPU hits 100%. An on-call engineer wakes up, logs in, diagnoses the issue, and restarts the server — thirty minutes of lost sleep. With Automation, this entire process can happen without human intervention.
Automation lets you build Runbooks: multi-step workflows that execute automatically. AWS provides ready-made Runbooks for common tasks like restarting an EC2 instance, creating an AMI, or taking an EBS snapshot.
You can also build custom Runbooks. For example: "When CPU alarm fires → capture top processes to S3 → restart instance → send completion notification." Multiple steps chained together into one automated workflow.
For critical operations, you can include approval steps. "Before restarting the database, require approval from the operations lead." This lets you combine automation with human oversight when needed.
Connect Automation to CloudWatch Alarms or EventBridge rules and Runbooks trigger automatically when specific events occur.
Exam tip: "Automatically restart EC2 when a CloudWatch alarm fires" — the answer is Automation Runbook plus CloudWatch Alarm.
!4 Systems Manager capabilities
Parameter Store — Safely Storing Configurations and Secrets
Your application needs a database address, username, and password to connect. Putting these values directly in your code is a serious security risk. Parameter Store is the right place to store them.
Parameter Store has three value types.
String stores plain text. Use this for non-sensitive configuration values like database host addresses or API endpoints.
StringList stores a comma-separated list of values. Useful for things like a list of allowed IP addresses.
SecureString stores the value encrypted using a KMS key. Use this for sensitive data like database passwords, API keys, and certificates.
You can organize values in a hierarchy: /myapp/prod/db/password gives you a clean structure for managing values across environments. Version history is tracked automatically.
Parameter Store is often compared to Secrets Manager. Parameter Store Standard tier is free; Secrets Manager is paid but offers automatic secret rotation. "Store encrypted config values for free" points to Parameter Store SecureString. "Automatically rotate a database password on a schedule" points to Secrets Manager.
Exam tip: "Store configuration values encrypted at no cost" — the answer is Parameter Store SecureString.
EC2 Image Builder — Automating Golden AMI Creation
Your company maintains a standard server image with all required security settings, software, and policies baked in. This is called a "golden AMI." EC2 Image Builder automates the creation and updating of this golden AMI.
The pipeline works like this: select a base image (AWS official Amazon Linux, for example), define which software to install and which settings to apply, run a test phase to verify the image is correct, then distribute the tested image to one or more regions.
You can schedule this pipeline to run automatically whenever a new security patch is released, keeping your golden AMI always up to date.
Inventory — Knowing What is Installed
If you need to know which software is installed on one hundred servers — and which version — Systems Manager Inventory collects that information automatically.
From a single dashboard you can see installed applications, network configuration, Windows update status, and running services for every managed instance. This is useful for quickly finding all servers running a specific software version, or for auditing license usage across your fleet.
Exam Key Points
"Run commands on hundreds of servers simultaneously without SSH" -- Run Command