What Is AWS Systems Manager (SSM)? Session Manager, Parameter Store, Run Command & Patch Manager — Plus What's Free vs Paid

AWS Systems Manager (SSM) is a unified management service that gives you a single console and API for operating your entire fleet — EC2 instances, on-premises servers, Azure VMs, edge devices, and containers — without opening a single inbound port or managing a single SSH key. The part almost everyone misses: the core features (Session Manager for terminal access, Run Command for remote execution, Patch Manager for OS updates, Inventory for tracking, and Parameter Store for configuration) are free for EC2 instances. Not freemium, not trial — genuinely free with no per-instance charge. If you are still using bastion hosts and manually patching servers, you are paying for infrastructure that replaces a service AWS already gives you at no additional cost.

Jake had been running his shop's infrastructure on EC2 for three years. He had a bastion host in a public subnet, a security group allowing SSH from his office IP, and a text file on his desktop with the key pair names for each environment. When his office IP changed last month because the ISP assigned a new dynamic address, he locked himself out for forty-five minutes. Ethan, who had been telling him about Session Manager since 2023, finally sat him down. "Every problem you just described — the bastion cost, the key management, the IP allowlisting — AWS solved all of it with Systems Manager. You just never looked."

This post is that sit-down. We'll go through every capability in the Systems Manager toolbox — Session Manager, Run Command, Parameter Store, Patch Manager, and the dozen-plus features around them — with honest pricing, the setup steps, the failure modes nobody warns you about, and when each tool is the right answer versus when you should use something else.

What AWS Systems Manager Actually Is (and Why It's Called SSM)

AWS Systems Manager is a secure end-to-end management solution for resources on AWS and in multicloud and hybrid environments. The "SSM" abbreviation comes from the original service name — Amazon Simple Systems Manager (SSM), which was later renamed to EC2 Systems Manager, then to just Systems Manager when AWS expanded it beyond EC2. The abbreviation stuck, which is why you see "SSM Agent," "SSM Parameter," and "SSM Document" throughout the AWS ecosystem.

At its core, Systems Manager is a management plane — a layer that sits above your infrastructure and lets you see, operate, and automate everything from one place. Instead of logging into individual servers, writing custom scripts to patch fleets, or maintaining separate tools for on-prem and cloud, Systems Manager gives you a unified interface where all your nodes — regardless of where they run — appear and can be managed consistently.

The key architectural insight: Systems Manager works through an agent (SSM Agent) that runs on each managed node. The agent makes outbound connections to AWS service endpoints — no inbound ports need to be open. This is what makes Session Manager possible without bastion hosts, and what makes Run Command work on instances in private subnets without any network path from the internet.

What Systems Manager is not: it is not a monitoring service (that is CloudWatch), not a configuration compliance scanner (that is AWS Config), not a CI/CD pipeline (that is CodePipeline), and not a full secrets manager (that is Secrets Manager, though Parameter Store handles many secrets use cases). It is specifically the operational layer — the "how do I actually do things to my servers" layer.

Ethan's analogy for Jake: "Think of Systems Manager as the back office of your phone shop. The storefront is your application — customers come in, they see phones, they buy things. The back office is where you track inventory, manage repairs, handle returns, run reports. Customers never see it, but without it, the storefront collapses. Systems Manager is that back office for your cloud infrastructure."

The Complete Capability Map: Every Feature in the Toolbox

Systems Manager is not one tool — it is a collection of more than a dozen capabilities, each solving a different operational problem. Most teams use only two or three and never discover the rest. Here is the full map, organized by what each feature does.

Two features are worth noting because they are no longer open to new customers: Change Manager (for managing change requests through approval workflows) and Incident Manager (for incident response automation). AWS has deprecated both for new customers and points to OpsCenter and other alternatives. If you were considering these, look at OpsCenter instead.

Also worth noting: on June 30, 2026, AWS removed the Advanced Instances Tier. Previously, on-premises and multicloud nodes required an advanced instance tier with per-instance pricing. Now, you can register any number of hybrid and multicloud nodes at no registration or per-instance charge — though Session Manager and Run Command on those nodes will incur charges starting September 30, 2026.

Session Manager: Terminal Access Without Ports, Keys, or Bastions

Session Manager is the feature that, once you understand it, makes you question why you ever did it any other way. It provides fully managed shell access to your EC2 instances, on-premises servers, edge devices, and VMs — through either an interactive browser-based shell or the AWS CLI. No inbound ports. No bastion hosts. No SSH keys to manage, rotate, or lose.

How Session Manager Works Under the Hood

The SSM Agent on your instance makes an outbound HTTPS connection to AWS Systems Manager endpoints. When you start a session from the console or CLI, AWS brokers the connection through that outbound channel. Your commands travel to the instance, the output travels back, and the entire session flows through AWS's infrastructure — never through an open port on your instance's security group.

This architecture has three practical consequences. First, your instances can live in private subnets with no route to the internet (as long as they can reach AWS endpoints via a VPC endpoint or NAT). Second, you can close port 22 and port 3389 in your security groups entirely — eliminating the most common attack surface on EC2. Third, access control moves from network-level (IP allowlists) to IAM-level (who has ssm:StartSession permission on which instances), which is far more granular and auditable.

Session Logging and Auditing

Every session can be logged — the commands entered and their output — to Amazon S3 or Amazon CloudWatch Logs. You can also enable encryption of session data using AWS KMS. This turns every terminal session into an auditable record: who connected, when, what they typed, and what the system returned. For compliance-heavy environments, this replaces the ad-hoc "we hope someone was watching" approach with a systematic audit trail.

To prevent sensitive data like passwords from appearing in session logs, AWS recommends using specific commands during sessions — for example, on Linux, prefixing sensitive commands in ways that keep them out of the standard shell history that gets logged.

Port Forwarding and SSH Tunneling

Session Manager also supports port forwarding and SSH tunneling through the same outbound-only connection. This means you can access databases, web interfaces, or other services on your instances without opening their ports either. The start-session CLI command with the --document-name AWS-StartPortForwardingSession parameter establishes a tunnel from your local machine through AWS to the target port on the instance.

Jake's reaction when Ethan showed him this: "So I can connect to my RDS database through a tunnel that goes through Systems Manager, without opening the RDS port to my IP?" Ethan nodded. "And when your office IP changes tomorrow, nothing breaks, because there is no IP allowlist to update."

Session Manager Pricing

For Amazon EC2 instances: no additional charges. For hybrid and multicloud nodes (on-premises servers, Azure VMs, etc.): starting September 30, 2026, $0.05 per session. During the transition period (June 30 – September 30, 2026), usage on hybrid nodes is not billed.

Prerequisites for Session Manager

1. SSM Agent installed on the instance (preinstalled on AMIs for Amazon Linux 2, Amazon Linux 2023, Windows Server provided by AWS, and Ubuntu Server; manual install required for some other operating systems).
2. IAM instance profile attached to the instance with the AmazonSSMManagedInstanceCore policy (or equivalent permissions).
3. Network connectivity from the instance to Systems Manager endpoints — either internet access, a NAT gateway, or a VPC endpoint for SSM.
4. IAM user/role permission to start sessions (ssm:StartSession on the target instance).

Run Command: Execute Anything on Any Fleet, Instantly

Run Command lets you remotely and securely manage the configuration of your managed nodes. Using Run Command, you can automate common administrative tasks and perform one-time configuration changes at scale. You can use it from the AWS Management Console, the AWS CLI, AWS Tools for Windows PowerShell, or the AWS SDKs.

How Run Command Works

Run Command uses SSM Documents — JSON or YAML files that define what actions to take. AWS provides dozens of pre-built documents (like AWS-RunShellScript for Linux and AWS-RunPowerShellScript for Windows), and you can create your own custom documents for anything the pre-built ones do not cover.

When you run a command, you specify: the document to use, the parameters (like the actual shell commands to execute), and the targets (which instances to run on — selected by instance IDs, tags, or resource groups). Run Command then executes the commands on all targets in parallel and shows you the output from each instance.

Common Run Command Use Cases

• Restart a service on 50 instances — one command, targets selected by tag
• Check disk space across your fleet — df -h on all Linux instances, results in a table
• Install a package everywhere — yum install or apt-get install across hundreds of instances
• Update the SSM Agent itself — using the appropriate AWS-provided document for agent updates
• Run a diagnostic script — execute a custom script that collects logs or checks configuration
• Manage users — create or delete OS users across a fleet

Run Command Pricing

For Amazon EC2 instances: no additional charges. For hybrid and multicloud nodes: starting September 30, 2026, $0.002 per invocation.

Run Command vs Automation

Run Command executes a single document (one set of commands) on targets. Automation executes multi-step workflows (runbooks) that can include Run Command steps, Lambda invocations, API calls, waits, and branching logic. If you need to "run this script on these servers," use Run Command. If you need to "stop the server, snapshot the volume, resize it, restart the server, and verify it is healthy," use Automation.

Parameter Store: Configuration Management That Is Actually Simple

Parameter Store lets you create, organize, and manage configuration data and secrets that your applications use at runtime. It simplifies configuration management across environments — you can standardize how applications access critical data without hardcoding values or relying on fragmented storage solutions.

Parameter Types

Parameter Store supports three parameter types, each for a different use case:

• String — plain text values, such as environment names, endpoint URLs, or resource identifiers
• StringList — comma-separated lists of plain text values, like subnet-123abc,subnet-456def,subnet-789ghi
• SecureString — values that require encryption, such as database passwords, API keys, or license codes. SecureString parameters are encrypted using AWS KMS.

Standard vs Advanced Parameters

Parameters come in two tiers. Standard parameters are free and support values up to 4 KB with a quota of 10,000 parameters per account/region. Advanced parameters cost $0.05 per parameter per month but support values up to 8 KB, a quota of 100,000 parameters, and parameter policies (like expiration and change notification).

Parameter Store vs Secrets Manager

This is a common confusion. Parameter Store handles configuration data and can handle secrets (via SecureString). Secrets Manager is a dedicated secrets management service with automatic rotation, cross-account access, and finer-grained access policies. The rule of thumb: if you just need to store and retrieve a database password and you do not need automatic rotation, Parameter Store's SecureString is sufficient and free. If you need automatic credential rotation, fine-grained per-secret IAM policies, or native integration with RDS/Redshift for rotation, use Secrets Manager.

Ethan's take: "Most teams use Parameter Store for 90% of their configuration and Secrets Manager for the 10% that needs rotation. That's the right split. Don't pay for Secrets Manager to store a non-secret configuration value like 'environment=production' — that's what Parameter Store is for."

Patch Manager: Automated OS Patching That Actually Works

Patch Manager automates the process of patching managed nodes with both security-related updates and other types of updates for operating systems and applications. It supports Windows, Amazon Linux, Ubuntu Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS, Debian Server, Oracle Linux, and Raspberry Pi OS.

Patch Baselines

A patch baseline defines which patches should be approved for installation on your instances. AWS provides default patch baselines for each supported operating system — these auto-approve security-related updates within a specified number of days of release. You can use the defaults or create custom baselines with your own approval rules, including rules based on patch classification (Security, Bugfix, Enhancement, etc.) and severity (Critical, High, Medium, Low).

Custom baselines are useful when the defaults do not align with your security policies — for example, if you need to wait 30 days after a patch is released before installing it (a common "let someone else find the bugs" strategy), you can create a baseline that approves patches only after 30 days.

Patch Groups and Maintenance Windows

Patch groups are tags you apply to instances to organize them into patching cohorts (e.g., "dev", "staging", "production"). Maintenance Windows define when patching operations run — you specify a schedule (cron or rate), a duration, and which patch groups are included. Combined, these let you patch dev every night, staging weekly, and production monthly during a Sunday 2 AM window.

Patching Operations: Scan vs Install

Patch Manager supports two operation modes. Scan checks instances for missing patches and reports compliance status without installing anything. Install actually installs approved patches. You can (and should) run scans regularly and installs during maintenance windows.

On Windows, Patch Manager uses the AWS-RunPatchBaseline document, which can also handle application updates released by Microsoft (not just OS updates). On Linux, the same document handles distribution-specific package managers (yum, apt, zypper).

Patch Manager Pricing

For Amazon EC2 instances: no additional charges. For hybrid and multicloud nodes, patching operations that rely on Run Command will be charged as Run Command usage ($0.002 per invocation starting September 30, 2026). If you use the Generate Report option, it executes an Automation document, which is charged based on Automation pricing ($0.002 per step).

Patch Compliance Tracking

After a scan or install, Patch Manager reports compliance status for each instance: compliant (all required patches installed) or non-compliant (missing patches). The Systems Manager Compliance dashboard aggregates this across your fleet, showing which instances are behind on patching and which specific patches are missing.

Automation: Multi-Step Runbooks for Real Operations

Automation allows you to safely automate common and repetitive IT operations and management tasks across AWS resources. Where Run Command executes a single document on targets, Automation executes multi-step workflows called runbooks that can chain together multiple actions — Run Command steps, Lambda invocations, AWS API calls, sleeps, approvals, and branching logic.

AWS-Provided Runbooks

AWS ships with dozens of pre-built runbooks covering common scenarios: restarting EC2 instances, creating AMIs, updating Linux AMIs, configuring Windows Update, and many more. Before writing a custom runbook, check if AWS already provides one that does what you need.

Automation Actions

Automation runbooks are built from action steps. Key action types include:

• aws:runCommand — execute a command document on targets
• aws:executeScript — run Python or PowerShell code inline
• aws:executeAwsApi — call any AWS API
• aws:changeInstanceState — stop, start, or restart instances
• aws:createImage — create an AMI from an instance
• aws:sleep — pause for a specified duration
• aws:approve — require manual approval before proceeding
• aws:invokeLambdaFunction — call a Lambda function

Automation Pricing

Automation is charged based on the number and duration of steps. Each step costs $0.002. Additionally, each aws:executeScript action step is charged $0.00003 for every second of execution time. There is no duration charge for other action types. Runbook attachments are charged $0.046 per GB per month for storage.

Example: running 25,000 steps in a month, of which 10,000 are aws:executeScript steps that ran for a total of 100,000 seconds, would cost $50 (step count) + $3 (script duration) = $53 per month.

Automation vs Lambda

A common question: when to use Automation vs a Lambda function? Automation is better for operations that involve AWS resources (start/stop instances, create AMIs, run commands on servers) because it has native actions for those. Lambda is better for custom business logic, complex data processing, or integrations with external systems. They are complementary — Automation runbooks can invoke Lambda functions, and Lambda functions can start Automation executions.

State Manager: Enforce Configuration, Not Just Set It

State Manager is a secure and scalable configuration management service that ensures your managed nodes maintain a defined state. Where Run Command is "run this once," State Manager is "ensure this is always true." If an instance drifts from the desired state, State Manager brings it back.

How State Manager Works

You create a State Manager association that links a document (the same SSM Documents used by Run Command) to targets (instances, selected by tag or ID). The association specifies a schedule (run once, every N hours, on a cron schedule). State Manager then executes the document on the targets according to the schedule and reports compliance status.

Common use cases: ensuring the CloudWatch agent is always installed and configured, enforcing antivirus software presence, maintaining specific firewall rules on the OS, or keeping a configuration file in a known state.

State Manager Pricing

No additional charges. Limits may apply.

State Manager vs AWS Config

AWS Config tracks resource configuration at the AWS API level (security groups, IAM policies, etc.) and can remediate drift using remediation runbooks (which often use Systems Manager Automation). State Manager works at the OS level — inside the instance, managing software, files, and OS configuration. They are complementary: Config for AWS resource state, State Manager for in-guest state.

Inventory: Know What Is Actually Running on Your Fleet

Systems Manager Inventory collects metadata about your managed nodes — operating system information, installed applications, network configuration, Windows updates, custom metadata you define — and makes it queryable in the console or via the CLI. It answers questions like "which instances are running an EOL version of the OS?" or "where is this vulnerable package installed?" without you having to SSH into anything.

What Inventory Collects

Inventory can collect: OS name and version, installed applications and versions, network configuration (IP addresses, MAC addresses, DNS), Windows roles and features, Windows updates and hotfixes, services and drivers, custom inventory (any data you want via a custom schema), and file system metadata.

Inventory Pricing

No additional charges. Limits may apply.

Resource Data Sync

For multi-account or multi-region environments, Resource Data Sync automatically aggregates inventory data from all managed nodes into a central Amazon S3 bucket. This gives you a single place to query fleet-wide inventory using Athena, QuickSight, or your own tooling.

Distributor: Software Package Management for Your Fleet

Distributor helps you distribute and maintain software packages on your instances. These packages can be AWS service agents, third-party owned, or your own agents imported into Systems Manager. Think of it as an internal package repository that works across your fleet.

Distributor Pricing

AWS packages and third-party owned packages: no charge. For non-AWS packages (your own custom packages): storage at $0.046 per GB per month, Get/Describe API calls at $0.025 per 1,000, and data transfer out of Region at $0.900 per GB.

OpsCenter and Explorer: The Operations Dashboard

OpsCenter provides a central location where operations engineers and IT professionals can view, investigate, and resolve operational issues related to AWS resources. Operational issues — called OpsItems — are aggregated and standardized in a consolidated view, providing contextually relevant data for diagnosis and remediation.

Explorer is a customizable operations dashboard that aggregates data from across your AWS accounts and Regions. It shows metrics like patch compliance rates, inventory counts, and OpsItem trends — giving leadership visibility into operational health.

OpsCenter Pricing

OpsCenter is priced on a pay-per-use model. You are charged $2.97 per 1,000 OpsItems created, plus $0.039 per 1,000 Get, Describe, Update, and GetOpsSummary API requests.

Explorer Pricing

No additional charges for enabling Explorer. However, Explorer uses priced OpsCenter APIs (GetOpsSummary) to populate its dashboard, so those charges apply. The Export to CSV option executes an Automation document, which may incur Automation charges.

Complete Pricing Breakdown: What Costs Money and What Does Not

The pricing model is where Systems Manager surprises people — in a good way for EC2 users, less so for hybrid deployments. The core features that most teams need (Session Manager, Run Command, Patch Manager, Inventory, State Manager, Fleet Manager) are completely free for EC2 instances. The paid features are the advanced ones that most small teams never touch.

*Explorer itself is free, but it uses OpsCenter APIs that are charged.

Real-World Cost Example

Assume you have 50 EC2 instances that you manage entirely with the free features (Session Manager, Run Command, Patch Manager, Inventory). Your Systems Manager bill is $0. Now assume you run 10 Automation runbooks per week, each with 5 steps: 10 × 5 × 4 weeks × $0.002 = $0.40/month. If you also use 100 advanced Parameter Store parameters: 100 × $0.05 = $5/month. Total: $5.40/month for serious operational tooling.

The Hybrid/Multicloud Transition

The June 2026 removal of the Advanced Instances Tier changed the hybrid/multicloud pricing model significantly. Previously, on-prem and other-cloud nodes required paid registration. Now, registration is free — but Session Manager and Run Command on those nodes start billing on September 30, 2026, at $0.05/session and $0.002/invocation respectively. For a fleet of 200 hybrid nodes each running 4 Run Command invocations and 1 Session Manager session per month, the cost would be $1.60 (Run Command) + $10 (Session Manager) = $11.60/month.

Getting Started: From Zero to Session Manager in Five Minutes

Enough theory. Here is the fastest path from "I have EC2 instances and no Systems Manager" to "I am using Session Manager right now."

For New Instances

1. Launch an EC2 instance from an AMI that has SSM Agent preinstalled (AMIs for Amazon Linux 2, Amazon Linux 2023, Windows Server provided by AWS, and Ubuntu Server).
2. Attach the AmazonSSMManagedInstanceCore managed policy to an IAM role, and attach that role to your instance at launch.
3. Ensure the instance can reach Systems Manager endpoints — either through internet access, a NAT gateway, or (recommended for private subnets) a VPC endpoint for SSM.
4. Open the Systems Manager console, go to Fleet Manager, and confirm your instance appears as "Managed."
5. Go to Session Manager, click "Start session," select your instance, and you have a browser-based shell.

For Existing Instances

1. Create an IAM role with the AmazonSSMManagedInstanceCore policy if you do not have one.
2. Attach the role to your existing EC2 instances (this can be done without stopping the instance).
3. If SSM Agent is not preinstalled on your AMI, install it manually — AWS provides installation procedures for various operating systems.
4. Verify the instance appears as managed in the Systems Manager console.
5. Close port 22 (or port 3389) in your security group, because you do not need it anymore.

VPC Endpoints for Private Subnets

If your instances are in private subnets with no internet route, create interface VPC endpoints for: ssm (the API), ssmmessages (Session Manager), and ec2messages (messaging). This allows the SSM Agent to reach AWS without any outbound internet path, keeping your instances fully isolated.

Default Host Management Configuration

AWS offers a Default Host Management Configuration setting that allows Systems Manager to manage your EC2 instances automatically as managed instances — without requiring an IAM instance profile. This is the easiest setup path: enable it once per account/region, and every EC2 instance that meets the SSM Agent requirements becomes managed automatically.

The SSM Agent: What It Is, Where It Runs, and When It Breaks

The SSM Agent is the software that runs on your managed nodes and enables all Systems Manager functionality. Without the agent, none of the features work. Understanding what it is and how to troubleshoot it is essential.

Where SSM Agent Is Preinstalled

SSM Agent is preinstalled by default on AMIs for Amazon Linux 2, Amazon Linux 2023, Windows Server that are provided by AWS, and Ubuntu Server. For other operating systems — RHEL, CentOS, SLES, Debian, AlmaLinux, CentOS Stream, Oracle Linux, Rocky Linux — you need to install it manually. AWS maintains a page listing AMIs with the SSM Agent preinstalled that you can search.

Keeping the Agent Updated

AWS regularly updates the SSM Agent with new features and bug fixes. On instances created from AMIs where the agent is preinstalled, the agent typically auto-updates by default. You can also use Run Command with the appropriate AWS-provided document to manually update across a fleet, or use State Manager to ensure the agent stays current.

Troubleshooting: Instance Not Showing as Managed

The most common Systems Manager problem: an instance that should be managed is not appearing in the console. The causes, in order of likelihood:

• Missing or wrong IAM role — the instance does not have the AmazonSSMManagedInstanceCore policy or equivalent permissions
• Agent not installed or not running — check the agent service status on the instance
• No network path to SSM endpoints — the instance cannot reach the Systems Manager endpoints for its region
• Wrong region — you are looking in the wrong Systems Manager region (instances appear in the region they are running in)
• Agent version too old — very old agent versions may not support current features

Systems Manager offers automated diagnosis capabilities to help identify why nodes are not reporting as managed, including networking misconfigurations. The unified console includes a dashboard that provides a high-level overview of your nodes with the ability to drill down and see which nodes have agent issues.

AWS Systems Manager vs the Alternatives: When to Use Something Else

Systems Manager is not the only tool in this space. Ansible, Chef, Puppet, Azure Arc, and Google Cloud Operations Suite all compete for the "manage my fleet" workload. The honest comparison:

The pattern: Systems Manager wins for AWS-centric operations because it is native, free for the core features, and requires no infrastructure to run. Ansible/Chef/Puppet win for complex multi-cloud configuration management with mature module ecosystems. Azure Arc wins if Azure is your primary cloud. For most teams running primarily on AWS, Systems Manager covers 90% of what they need without leaving the AWS ecosystem.

Ethan's perspective: "I've seen teams deploy Ansible to manage five EC2 instances. That's not wrong, but it's heavier than it needs to be. Start with Systems Manager, and if you hit a wall — usually because you need complex multi-cloud orchestration — then add Ansible on top. They work together fine."

Multi-Account Management with AWS Organizations

For organizations using AWS Organizations with multiple accounts, Systems Manager supports a delegated administrator model. You designate one account as the Systems Manager administrator, and that account can view and manage nodes across all accounts in the organization — or specific organizational units.

This means your central operations team can: see all managed and unmanaged nodes across the entire organization, run commands on instances in any account, view patch compliance across the fleet, and maintain consistent configuration — all from one console. Member account teams retain control over their own resources, but the central team gains visibility and the ability to enforce standards.

Explorer aggregates operational data from across accounts and Regions into a single dashboard, giving leadership a bird's-eye view of operational health without requiring anyone to log into individual accounts.

Hybrid and Multicloud: Managing On-Prem and Azure from AWS

Systems Manager is not limited to EC2. Through hybrid activations, you can register on-premises servers, edge devices, and VMs running in other cloud environments (like Azure or GCP) as managed nodes. This gives you the same Session Manager, Run Command, Patch Manager, and Inventory capabilities across your entire hybrid estate.

How Hybrid Activations Work

You create a hybrid activation in your AWS account, which generates an activation code and activation ID. You then install the SSM Agent on your on-prem server or VM, configure it with the activation code, and the agent registers itself as a managed node in your AWS account. From that point, the node appears in the Systems Manager console alongside your EC2 instances and can be managed identically.

Azure VM Support

Systems Manager supports managing Microsoft Azure virtual machines through a Cloud Connector. You set up an AWS Config connector to Azure, then a Systems Manager Cloud Connector, and enable VM onboarding. This allows you to use Systems Manager to manage Azure VMs alongside your AWS infrastructure.

The Pricing Shift for Hybrid Nodes

The June 2026 removal of the Advanced Instances Tier made hybrid node registration free, but starting September 30, 2026, Session Manager ($0.05/session) and Run Command ($0.002/invocation) on hybrid nodes begin billing. Inventory, State Manager, and Patch Manager scanning remain free — only the interactive and command execution features are priced.

Best Practices: What Experienced Teams Do Differently

After covering all the features, a set of practices emerges that separates teams who get real value from Systems Manager and teams who enable it and forget about it.

1. Replace bastion hosts with Session Manager on day one. If you are setting up new infrastructure, do not create a bastion. Do not open port 22. Use Session Manager from the start, and never develop the SSH habit that you will have to break later.

2. Use tags for targeting, not instance IDs. Run Command, Patch Manager, and State Manager all support tag-based targeting. A tag like patch-group=production scales to hundreds of instances without maintenance; a list of instance IDs breaks the first time someone terminates an instance and launches a new one.

3. Enable session logging before you need it. Set up S3 or CloudWatch logging for Session Manager sessions from day one. When an auditor asks "who did what on this server," you will have the answer. Retrofitting logging after an incident is too late.

4. Use VPC endpoints for instances in private subnets. If your instances have no internet route, create interface VPC endpoints for ssm, ssmmessages, and ec2messages. This is more secure than a NAT gateway and keeps traffic on the AWS network.

5. Start with the free tier and add paid features as needed. For most teams, Session Manager + Run Command + Patch Manager + Inventory covers 90% of operational needs at zero cost. Add Automation and OpsCenter only when you have a specific use case that requires them.

6. Use Default Host Management Configuration to auto-enroll instances. Instead of manually attaching IAM roles and verifying agent status for each instance, enable Default Host Management Configuration once per region and let AWS handle the enrollment automatically.

7. Separate patch groups by environment. Tag instances as patch-group=dev, patch-group=staging, patch-group=production, and create separate maintenance windows for each. Patch dev aggressively, staging cautiously, production only during approved windows.

8. Use Parameter Store hierarchies for organization. Structure parameters as paths like /myapp/dev/database-url, /myapp/prod/database-url. This enables hierarchical retrieval (get all parameters under /myapp/prod/) and keeps environments cleanly separated.

When Systems Manager Is Not the Right Tool

Honesty time: Systems Manager is not always the answer. Here are the situations where something else is better:

Complex configuration management across multiple clouds: If you are managing hundreds of servers across AWS, Azure, GCP, and bare metal, and you need sophisticated configuration templating, Ansible or Puppet may be more appropriate. Systems Manager handles hybrid well, but Ansible's module ecosystem is broader for cross-platform configuration.

Application deployment: Systems Manager does not deploy application code to servers. For that, use AWS CodeDeploy (which integrates with EC2 and handles blue/green and rolling deployments) or a container orchestration platform.

Secrets with automatic rotation: Parameter Store can store secrets (SecureString), but it does not rotate them automatically. For database credentials that need scheduled rotation, use AWS Secrets Manager.

Container-native workloads: If your applications run in ECS or EKS, container-native tooling (Kubernetes operators, Helm, ECS task definitions) is more appropriate than managing individual container instances with SSM.

Serverless: If you have no servers — only Lambda functions — Systems Manager has nothing to manage. Parameter Store is still useful for Lambda configuration, but the fleet management features are irrelevant.

Frequently Asked Questions

Is AWS Systems Manager free?

The core features (Session Manager, Run Command, Patch Manager, Inventory, State Manager, Fleet Manager, Maintenance Windows, Compliance) are free for Amazon EC2 instances with no per-instance or per-use charge. Paid features include Automation ($0.002/step), OpsCenter ($2.97/1,000 OpsItems), advanced Parameter Store parameters ($0.05/parameter/month), and Just-in-Time Access ($0.0137/hour/node). For hybrid and multicloud nodes, Session Manager and Run Command start billing at $0.05/session and $0.002/invocation respectively from September 30, 2026.

Does Session Manager work with instances in private subnets?

Yes. Session Manager works with instances in private subnets as long as the SSM Agent can reach AWS Systems Manager endpoints. This can be through a NAT gateway with internet access, or (more securely) through interface VPC endpoints for SSM, SSM Messages, and EC2 Messages. No inbound ports need to be open.

Do I need to install anything on my instances?

You need the SSM Agent. On many AMIs (Amazon Linux 2, Amazon Linux 2023, Windows Server provided by AWS, Ubuntu Server), the agent is preinstalled and auto-updates. On other operating systems (RHEL, CentOS, SLES, Debian, and others), you need to install it manually. You also need an IAM instance profile with the AmazonSSMManagedInstanceCore policy or equivalent permissions.

Can I use Session Manager to SSH into instances?

Session Manager provides a browser-based shell or CLI access that is functionally equivalent to SSH — you get a terminal on the instance. If you specifically need SSH (for tools that use the SSH protocol), you can use Session Manager's port forwarding to establish an SSH tunnel through the Session Manager channel, without opening port 22.

What is the difference between Run Command and Automation?

Run Command executes a single SSM Document (one set of commands) on targets — it is a one-shot execution. Automation executes multi-step runbooks that can chain together multiple actions: Run Command steps, Lambda invocations, AWS API calls, sleeps, approvals, and branching logic. Use Run Command for "run this script on these servers" and Automation for "perform this multi-step workflow."

Is Parameter Store free?

Standard parameters are free — up to 10,000 parameters per account/region with values up to 4 KB, and no charge for API interactions at standard throughput. Advanced parameters cost $0.05 per parameter per month, support up to 8 KB values and 100,000 parameters, and API interactions are charged at $0.05 per 10,000 (for both standard and advanced parameters when using higher throughput).

What is the difference between Parameter Store and Secrets Manager?

Parameter Store handles configuration data (and can store secrets via SecureString with KMS encryption) at no cost for standard parameters. Secrets Manager is a dedicated secrets management service with automatic rotation, fine-grained per-secret IAM policies, and native integration with RDS/Redshift. Use Parameter Store for most configuration values; use Secrets Manager when you need automatic credential rotation.

Can Patch Manager update applications or just the OS?

On Windows Server, Patch Manager can handle both OS updates and application updates released by Microsoft (using the AWS-RunPatchBaseline document with the appropriate operation type). On Linux, Patch Manager handles distribution package updates (via yum, apt, zypper). For custom application deployment, use CodeDeploy or your CI/CD pipeline.

Does Systems Manager work with on-premises servers?

Yes. Through hybrid activations, you can register on-premises servers and VMs as managed nodes. You install the SSM Agent on the server, use an activation code to register it with your AWS account, and from that point it appears alongside your EC2 instances in the Systems Manager console and can be managed identically. Starting September 30, 2026, Session Manager and Run Command on hybrid nodes are billed at $0.05/session and $0.002/invocation respectively.

Why is my instance not showing up in Systems Manager?

The most common causes: (1) the instance lacks the required IAM role with AmazonSSMManagedInstanceCore permissions, (2) the SSM Agent is not installed or not running, (3) the instance cannot reach SSM endpoints due to network configuration, or (4) you are looking in the wrong AWS region. Systems Manager offers automated diagnosis capabilities to help identify why nodes are not reporting as managed.

Can I use Systems Manager with Azure VMs?

Yes. Systems Manager supports managing Microsoft Azure virtual machines through a Cloud Connector. You set up an AWS Config connector to Azure, then a Systems Manager Cloud Connector, and enable VM onboarding. This allows you to manage Azure VMs using Systems Manager tools alongside your AWS infrastructure.

What is Default Host Management Configuration?

Default Host Management Configuration is a setting that allows AWS Systems Manager to manage your Amazon EC2 instances automatically as managed instances — without requiring you to create or attach an IAM instance profile. When enabled, every EC2 instance in the account/region that meets the SSM Agent requirements becomes a managed instance automatically.

Can I use Systems Manager with Terraform?

Yes. Systems Manager resources are fully supported in Terraform through the AWS provider — including aws_ssm_parameter, aws_ssm_document, aws_ssm_association, aws_ssm_maintenance_window, and related resources. You can manage your Systems Manager configuration as code alongside the rest of your infrastructure.

What are SSM Documents?

SSM Documents are JSON or YAML files that define actions that Systems Manager performs on managed nodes. There are several types: Command documents (define commands to run, used by Run Command and State Manager), Automation documents (define multi-step workflows, used by Automation), Policy documents (define IAM policies for managed instances), and Session documents (define session configurations for Session Manager). AWS provides dozens of pre-built documents, and you can create custom ones.

Is there a CLI for Systems Manager?

Yes. Systems Manager is fully accessible via the AWS CLI (aws ssm commands), the AWS SDKs (including boto3 for Python with the ssm client), and AWS Tools for Windows PowerShell. Every operation available in the console is available programmatically. There is also a Session Manager plugin for the AWS CLI that enables session initiation from the command line.

What is the Just-in-Time Access feature?

Just-in-Time (JIT) node access is a Systems Manager feature that provides temporary elevated access to managed nodes. Instead of having permanent admin access, users request temporary access for a specific duration, and access is automatically revoked when the time expires. It is priced per node per hour, starting at $0.0137/hour for the first 72,000 node-hours. There is a free trial for the remainder of the billing cycle when enabled plus one additional billing cycle.

Revision note. Written September 2026. Feature availability and pricing change as AWS evolves the service — check the current AWS Systems Manager documentation before making architectural decisions. If you have been running bastion hosts, manually patching servers, and managing SSH keys across environments, the fix has been sitting in the AWS console this whole time.