AWS Cloud Practitioner Study Notes · Part 51

AWS Systems Manager (SSM): Session Manager, Run Command, and Automation

AWS Cloud Practitioner study notes explaining AWS Systems Manager, SSM Agent, private access, Session Manager, Run Command, Patch Manager, Parameter Store, and State Manager.

Tan Chin SiangBackend & Cloud Software Engineer

22 Aug 2026 15 min read

AWS Systems Manager is a managed operations service for viewing, managing, configuring, patching, and accessing managed nodes. A managed node can be an EC2 instance, an on-premises server, an edge device, or a virtual machine in a hybrid environment.

This is Part 51 of the AWS Cloud Practitioner Study Notes. Think of Systems Manager as a central operations hub:

Systems Manager
├── Access nodes securely       → Session Manager
├── Run commands at scale       → Run Command
├── Apply patches               → Patch Manager
├── Automate procedures         → Automation
├── Store configuration         → Parameter Store
├── Enforce configuration       → State Manager
├── Discover installed software → Inventory
└── Schedule fleet operations   → Maintenance Windows

How Systems Manager works

Systems Manager does not normally connect to an EC2 instance by opening an inbound SSH connection. The SSM Agent runs on the managed node, receives approved requests from the Systems Manager service, executes the requested operation, and sends status back to AWS.

Administrator
        ↓ IAM-authorised request
Systems Manager service
        ↓
SSM Agent on managed node
        ↓
Command, session, patch, or automation result

This makes it practical to manage hundreds of nodes without logging in to each server individually.

Requirements for a managed EC2 instance

An EC2 instance generally needs three things:

1. SSM Agent

The SSM Agent must be installed and running. Many AWS-provided AMIs include the agent, but verify the agent version and service status for custom AMIs, older images, and non-AWS operating systems.

The agent can run on EC2, on-premises servers, edge devices, and supported virtual machines. It processes Systems Manager requests and communicates status back to the service.

2. IAM permissions

The managed node needs an instance profile or equivalent IAM permissions that allow the agent to communicate with Systems Manager. AWS-managed policies and default-role options can change over time; use the current Systems Manager setup documentation and grant only the permissions required for the node’s operations.

The administrator also needs IAM permissions for the Systems Manager actions they intend to perform, such as starting sessions, sending commands, or starting Automation runbooks.

Node IAM permissions
→ Agent can communicate with Systems Manager

Operator IAM permissions
→ Person or workload can request the desired operation

3. Network connectivity

The managed node needs outbound connectivity to Systems Manager endpoints. This can be through:

Internet access
A NAT gateway for a private subnet
VPC Interface endpoints for private connectivity

For private environments, common Interface endpoints include the Regional Systems Manager endpoint and message-channel endpoints such as ssmmessages. Some Regions and older agent versions may also use ec2messages.

Private EC2
        ↓
Interface VPC endpoints
        ↓
Systems Manager service

Security groups, DNS, route tables, endpoint policies, and IAM permissions must all allow the required communication.

Session Manager

Session Manager provides interactive shell access to managed nodes through the AWS console or AWS CLI. It is one of the most valuable Systems Manager features for private EC2 instances.

Administrator
        ↓
Session Manager
        ↓
SSM Agent
        ↓
Private EC2 instance

Session Manager can avoid the need for:

A public IP address
An inbound SSH or RDP rule
Port 22 or 3389 open from an administrator network
A bastion host
Managing SSH private keys for each server

Session Manager access is controlled by IAM, and session activity can be logged to CloudWatch Logs or Amazon S3 when configured. It provides a more controlled and auditable access path than giving every administrator direct SSH access.

Exam shortcut: connect to a private EC2 instance without opening port 22 or maintaining a bastion host → Session Manager.

Session Manager is not magic access without prerequisites: the agent, IAM permissions, and network path still need to work.

Run Command

Run Command executes commands remotely on one or more managed nodes. It is useful for on-demand administration at fleet scale:

Run Command
        ↓
Target production instances by tags or groups
        ↓
SSM Agent executes shell or PowerShell command
        ↓
Collect output and status

Examples include:

Run a Linux shell script on 500 instances
Run a PowerShell command on Windows servers
Restart a service
Install a package
Collect diagnostic output
Apply a configuration change

Run Command uses Systems Manager documents such as AWS-RunShellScript or AWS-RunPowerShellScript. Targeting by tags makes it possible to operate on groups of nodes without maintaining an individual server list.

Exam shortcut: run one command across many EC2 instances without SSH → Run Command.

Patch Manager

Patch Manager helps scan and install operating-system patches across managed nodes. A typical workflow is:

Define patch baseline or patch policy
        ↓
Select managed nodes
        ↓
Scan or install patches
        ↓
Report compliance
        ↓
Schedule future maintenance

Patch Manager supports patching workflows for supported operating systems. Organisations can schedule patch scans and installations, control reboot behavior, and review missing-patch compliance.

Use Maintenance Windows when patching should happen at a controlled time, such as Sunday at 2:00 AM. Patch Manager is the patch capability; Maintenance Windows provide the scheduling boundary.

Exam shortcut: patch a fleet of Linux or Windows servers on a schedule → Patch Manager, often scheduled with Maintenance Windows.

Parameter Store

Parameter Store stores configuration data and parameters for applications and operations. Examples include:

Environment = Production
API_URL     = https://api.example.com
FeatureFlag = enabled

Parameter types include ordinary String, StringList, and encrypted SecureString. SecureString uses AWS Key Management Service (KMS) encryption and requires the application to have the appropriate IAM permissions.

Application
        ↓
Parameter Store
        ↓
Configuration or SecureString value

Do not hardcode passwords, API keys, or tokens in application source code, AMIs, user data, or plain-text parameters. Use SecureString or Secrets Manager according to the requirements.

Parameter Store versus Secrets Manager

Parameter Store	Secrets Manager
Configuration and operational parameters	Purpose-built secrets and credentials
Supports `SecureString` with KMS	Supports secret-management workflows and rotation integrations
Often suitable for lower-complexity configuration	Strong fit for database credentials and rotating secrets
Retrieved through Systems Manager APIs	Retrieved through Secrets Manager APIs

Parameter Store SecureString is encrypted, but encryption alone does not provide automatic secret rotation. Choose Secrets Manager when built-in rotation and secret lifecycle features are important.

Automation

Systems Manager Automation runs predefined or custom runbooks to perform operational procedures. Examples include:

Restart an EC2 instance
Create an AMI
Modify an instance or resource configuration
Remediate a detected condition
Run a multi-step operational workflow

CloudWatch alarm
        ↓
Systems Manager Automation runbook
        ↓
Restart or remediate resource
        ↓
Notify the operations team

Automation can use a service role or a temporary execution context, depending on how it is started and configured. The runbook’s permissions should be limited to the operations it needs.

Exam shortcut: automate a multi-step operational task or restart after an alarm → Systems Manager Automation.

State Manager

State Manager keeps managed nodes in a defined configuration by applying associations on a schedule or in response to configured conditions.

Examples include ensuring that:

The CloudWatch Agent is installed and running
Docker is installed
A required package remains present
A node has a particular configuration
A server is joined to a supported domain

Desired state: CloudWatch Agent running
        ↓
State Manager association
        ↓
Detect drift and apply configuration

Use State Manager when the requirement is “keep it configured this way.” Use Run Command for a one-time command and Automation for a defined multi-step procedure.

Inventory and Compliance

Systems Manager Inventory collects information about managed nodes, such as:

Operating system details
Installed applications
Agent versions
Network configuration
Instance metadata

Compliance provides fleet-level visibility into patch and configuration compliance. It can aggregate compliance data across accounts and Regions when configured for the organisation.

Managed nodes
        ↓
Inventory collection
        ↓
Installed software and configuration data
        ↓
Compliance and reporting

Inventory answers “what is installed?” Compliance helps answer “does the fleet meet the required state?”

Distributor

Distributor packages and installs software on managed nodes. For example, an organisation can distribute the CloudWatch Agent or an internal software package across a fleet.

Package repository
        ↓
Distributor
        ↓
SSM Agent
        ↓
Many managed nodes

Distributor is about delivering packages; State Manager can help ensure that a package remains installed and configured.

Maintenance Windows

Maintenance Windows schedule operational tasks during an approved time period. A window can run tasks such as:

Patch scans or installations
Run Command operations
Automation runbooks
Package installation
Inventory collection

Sunday 2:00 AM
        ↓
Maintenance Window opens
        ↓
Patch and restart tasks run
        ↓
Compliance result is recorded

Maintenance Windows reduce the risk of making disruptive changes during business hours.

Fleet Manager

Fleet Manager provides a console experience for viewing and managing managed nodes. Depending on the node and available features, operators can inspect files, processes, performance, services, and other operating details without relying on a separate remote-desktop workflow.

Use Fleet Manager for centralised node visibility and operations. Use Session Manager when the main requirement is an interactive shell session.

Systems Manager documents

Systems Manager uses documents to define actions and workflows. Important document categories include:

Command documents for Run Command and State Manager
Automation runbooks for Systems Manager Automation
Session documents for Session Manager
Policy documents used by tools such as Inventory

Document
        ↓
Defines parameters and actions
        ↓
Systems Manager executes through SSM Agent

Documents can be AWS-provided or customer-managed. Review document permissions, parameters, and the execution role before allowing broad use.

How Systems Manager integrates with other AWS services

CloudWatch

CloudWatch alarms can trigger Systems Manager Automation, create OpsItems, or create Incident Manager incidents. CloudWatch monitors the signal; Systems Manager performs the operational procedure.

CloudWatch alarm
        ↓
Systems Manager Automation
        ↓
Restart, remediate, or gather diagnostics

IAM

IAM controls both sides of Systems Manager:

Which operator can start a session or send a command
Which managed node can communicate with Systems Manager
Which Automation runbook actions are allowed
Which parameters or SecureStrings can be read

Never grant unrestricted command execution or unrestricted session access without considering the security impact.

KMS

KMS can encrypt Parameter Store SecureString values and other Systems Manager data. The caller needs both Systems Manager permission and the relevant KMS permission where encryption is involved.

EventBridge and SNS

Systems Manager events and automation outcomes can be routed through EventBridge. SNS can notify the operations team when a patch, command, or automation workflow succeeds or fails.

Session Manager versus SSH

SSH	Session Manager
Usually needs port 22 reachable	No inbound port required
Often uses SSH keys	IAM-based authorisation
May require public IP, VPN, or bastion	Works with private nodes with SSM connectivity
Access audit depends on SSH logging configuration	Session logging can be configured centrally
Host-specific connection process	Central console or CLI workflow

Session Manager does not remove the need for operating-system permissions or network connectivity. It changes the access path and centralises authorisation and auditing.

Choosing the right Systems Manager tool

Need an interactive terminal?
→ Session Manager

Need to run one command across many nodes?
→ Run Command

Need to patch operating systems?
→ Patch Manager

Need a multi-step operational runbook?
→ Automation

Need to store configuration or SecureString values?
→ Parameter Store

Need to enforce a desired node configuration?
→ State Manager

Need to know installed software?
→ Inventory

Need to distribute a package?
→ Distributor

Need to schedule maintenance tasks?
→ Maintenance Windows

Need central node inspection?
→ Fleet Manager

Common exam questions

Connect to a private EC2 instance without opening port 22.

Use Systems Manager Session Manager.

Run a shell command across hundreds of EC2 instances.

Use Run Command.

Patch Linux servers every Sunday.

Use Patch Manager with a Maintenance Window.

Store configuration values and encrypted parameters.

Use Parameter Store, with SecureString for encrypted values.

Automatically restart an instance after a CloudWatch alarm.

Use Systems Manager Automation, or a supported CloudWatch EC2 alarm action when the simpler direct action is sufficient.

Keep the CloudWatch Agent running on every production node.

Use State Manager to maintain the desired configuration.

Find which applications are installed across the fleet.

Use Inventory.

Final memory trick

Session Manager → secure access
Run Command     → remote commands
Patch Manager   → operating-system patches
Automation      → runbooks
Parameter Store → configuration and SecureString
State Manager   → desired state
Inventory       → installed software and metadata
Distributor     → packages
Maintenance     → scheduled operations
Fleet Manager   → central node view

The one-sentence takeaway is: AWS Systems Manager is the central operations hub for managed nodes, allowing teams to access, configure, patch, automate, inspect, and maintain infrastructure without managing individual SSH connections.

Sources

AWSCloud PractitionerAWS Systems ManagerAmazon EC2Cloud Operations

Written by

Tan Chin Siang

Backend and cloud software engineer writing about reliable systems, infrastructure automation, and engineering practice.