Search across all documentation pages
Running more than a handful of EC2 instances raises the same questions over and over. Where does configuration live. How do you run a command on fifty instances at once instead of fifty terminal sessions. How do you turn a runbook into something repeatable instead of a wiki page a human reads at 3am. How do you get a shell on an instance without punching a hole in a security group for SSH.
AWS Systems Manager (SSM) answers all four with one operational surface, driven by one SDK client. This page builds the mental model before the following pages go deep on each piece.
ssm client.AmazonSSMManagedInstanceCore. That prerequisite is the single most common source of "why isn't this working."Systems Manager groups four distinct sub-services under one console area and one SDK client, because they solve related problems and share the same trust model.
Parameter Store is a hierarchical key-value store for configuration and secrets. Instead of baking a database hostname or an API key into an AMI or a deploy script, you put it in Parameter Store once and every instance or Lambda function reads it at runtime.
Run Command executes a predefined or custom command document against many instances in parallel, selected by instance ID or by tag, without you ever opening an SSH connection.
Automation documents (often called runbooks) codify a multi-step operational procedure - patch a fleet, rotate a credential, restart a service and verify health - as a versioned, replayable workflow instead of a script someone runs by hand from memory.
Session Manager opens an interactive shell to an instance over a secure channel, with no inbound port open and no SSH key to distribute or rotate.
All four require the same thing underneath: the target must be a managed instance.
# --- Python (boto3) ---
import boto3
ssm = boto3.client("ssm", region_name="us-east-1")
resp = ssm.describe_instance_information()
for info in resp["InstanceInformationList"]:
print(info["InstanceId"], info["PingStatus"], info["PlatformType"])// --- TypeScript (AWS SDK v3) ---
import { SSMClient, DescribeInstanceInformationCommand } from "@aws-sdk/client-ssm";
const ssm = new SSMClient({ region: "us-east-1" });
const resp = await ssm.send(new DescribeInstanceInformationCommand({}));
for (const info of resp.InstanceInformationList ?? []) {
console.log(info.InstanceId, info.PingStatus, info.PlatformType);
}If an instance does not show up in DescribeInstanceInformation, none of the other Systems Manager operations can reach it, no matter how correct your other code is.
The SSM Agent is a small process that ships pre-installed on Amazon Linux, most current Windows and Ubuntu AMIs, and is installable elsewhere. It runs on the instance and makes outbound HTTPS connections to the SSM service - it never listens for inbound connections. That is what lets Run Command, Automation, and Session Manager all avoid opening ports.
The second requirement is an IAM instance profile attached to the instance that includes (directly or via a custom policy modeled on it) the AWS managed policy AmazonSSMManagedInstanceCore. This grants the Agent permission to register itself, poll for work, and report results back to the service. Without this role, the Agent runs but the instance never appears as managed.
Once both conditions hold, the four capabilities interact through a common pattern: your code (via the SDK) calls an SSM API, the service records the request, the Agent on each target instance polls it up, executes it locally, and reports status back - which your code then polls for.
# --- Python (boto3) ---
import boto3
ssm = boto3.client("ssm", region_name="us-east-1")
resp = ssm.get_parameter(Name="/app/prod/db-host")
print(resp["Parameter"]["Value"])// --- TypeScript (AWS SDK v3) ---
import { SSMClient, GetParameterCommand } from "@aws-sdk/client-ssm";
const ssm = new SSMClient({ region: "us-east-1" });
const resp = await ssm.send(new GetParameterCommand({ Name: "/app/prod/db-host" }));
console.log(resp.Parameter?.Value);Parameter Store is the odd one out in one respect - it does not require a managed instance to be read from. Any caller with IAM permission (an EC2 instance, a Lambda function, your laptop) can call GetParameter. Run Command, Automation, and Session Manager, by contrast, all act on a managed instance and cannot function without one.
Thinking of these four as one toolkit, rather than four unrelated services, changes how you design fleet operations.
A typical pattern: Parameter Store holds the configuration and secrets an application needs at boot or runtime. Run Command is what you reach for to execute something across the fleet right now - restart a service, clear a cache, pull a log file. Automation is what you reach for when that "something" is actually a sequence of steps that needs to run reliably and be auditable - patch, verify, roll back on failure. Session Manager is what you reach for when a human needs to get onto a box interactively to investigate something the other three cannot answer.
The shared IAM/Agent foundation also means access control is centralized. You do not manage a separate SSH key per team or a separate secrets vault; you manage IAM policies against SSM actions, and CloudTrail logs every Run Command invocation, every Automation step, and every Session Manager session start - giving you an audit trail that scattered SSH access never provided.
The main limitation to internalize early: Systems Manager's power is entirely gated on the managed-instance prerequisite. An instance launched without the SSM Agent, or with an instance profile that omits AmazonSSMManagedInstanceCore, is invisible to all of Run Command, Automation, and Session Manager - and it will fail silently from the caller's perspective (a TargetNotConnected or empty result) rather than with an obvious "no agent" error message on first glance.
StartSession call returns connection details; the actual interactive terminal is established by the Session Manager plugin (typically via aws ssm start-session in the CLI).GetParameter; the managed-instance requirement applies to Run Command, Automation, and Session Manager.A family of fleet operations tools - Parameter Store, Run Command, Automation, and Session Manager among others - unified by a common managed-instance model and a single SDK client.
The SSM Agent must be running on it, and it must have an IAM instance profile that includes the AmazonSSMManagedInstanceCore policy so the Agent can register and communicate with the service.
No. The SSM Agent makes outbound connections to the SSM service; Run Command, Automation, and Session Manager all work without any inbound port open on the instance.
No, only to be acted on by Run Command, Automation, or Session Manager. Reading a parameter with GetParameter just requires IAM permission, from any caller.
Call DescribeInstanceInformation. If the instance appears in the result with a recent PingStatus, it is managed and reachable.
A single client per language: boto3.client("ssm") in Python, or SSMClient from @aws-sdk/client-ssm in TypeScript. All four capabilities are operations on that one client.
No. It achieves a similar outcome (an interactive shell) but over a different mechanism - a secure channel through the SSM service, with no SSH key or open port required.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Reviewed by Chris St. John·Last updated Jul 23, 2026