Use cases and best practices
This topic lists common use cases and best practices for AWS Systems Manager capabilities. If available, this topic also includes links to relevant blog posts and technical documentation.
Note
The title of each section here is an active link to the corresponding section in the technical documentation.
Automation
-
Create self-service Automation runbooks for infrastructure.
-
Use Automation, a capability of AWS Systems Manager, to simplify creating Amazon Machine Images (AMIs) from the AWS Marketplace or custom AMIs, using public Systems Manager documents (SSM documents) or by authoring your own workflows.
-
Build and maintain AMIs using the
AWS-UpdateLinuxAmi
andAWS-UpdateWindowsAmi
Automation runbooks, or using custom Automation runbooks that you create.
Inventory
-
Use Inventory, a capability of AWS Systems Manager, with AWS Config to audit your application configurations over time.
Maintenance Windows
-
Define a schedule to perform potentially disruptive actions on your nodes such as operating system (OS) patching, driver updates, or software installations.
-
For information about the differences between State Manager and Maintenance Windows, capabilities of AWS Systems Manager, see Choosing between State Manager and Maintenance Windows.
Parameter Store
-
Use Parameter Store, a capability of AWS Systems Manager, to centrally manage global configuration settings.
-
Reference AWS Secrets Manager secrets from Parameter Store parameters.
Patch Manager
-
Use Patch Manager, a capability of AWS Systems Manager, to roll out patches at scale and increase fleet compliance visibility across your nodes.
-
Integrate Patch Manager with AWS Security Hub to receive alerts when nodes in your fleet go out of compliance and monitor the patching status of your fleets from a security point of view. There is a charge to use Security Hub. For more information, see Pricing
. -
Use only one method at a time for scanning managed nodes for patch compliance to avoid unintentionally overwriting compliance data.
Run Command
-
Manage Instances at Scale without SSH Access Using EC2 Run Command
. -
Audit all API calls made by or on behalf of Run Command, a capability of AWS Systems Manager, using AWS CloudTrail.
When you send a command using Run Command, don't include sensitive information formatted as plaintext, such as passwords, configuration data, or other secrets. All Systems Manager API activity in your account is logged in an S3 bucket for AWS CloudTrail logs. This means that any user with access to S3 bucket can view the plaintext values of those secrets. For this reason, we recommend creating and using
SecureString
parameters to encrypt sensitive data you use in your Systems Manager operations.For more information, see Restricting access to Parameter Store parameters using IAM policies.
Note
By default, the log files delivered by CloudTrail to your bucket are encrypted by Amazon server-side encryption with Amazon S3-managed encryption keys (SSE-S3). To provide a security layer that is directly manageable, you can instead use server-side encryption with AWS KMS–managed keys (SSE-KMS) for your CloudTrail log files.
For more information, see Encrypting CloudTrail log files with AWS KMS–managed keys (SSE-KMS) in the AWS CloudTrail User Guide.
-
Use the targets and rate control features in Run Command to perform a staged command operation.
State Manager
-
Update SSM Agent at least once a month using the pre-configured AWS-UpdateSSMAgent document.
-
(Windows) Upload the PowerShell or DSC module to Amazon Simple Storage Service (Amazon S3), and use
AWS-InstallPowerShellModule
. -
Use tags to create application groups for your nodes. And then target nodes using the
Targets
parameter instead of specifying individual node IDs. -
Automatically remediate findings generated by Amazon Inspector by using Systems Manager
. -
For information about the differences between State Manager and Maintenance Windows, see Choosing between State Manager and Maintenance Windows.
Managed nodes
-
Systems Manager requires accurate time references to perform its operations. If your node's date and time aren't set correctly, they might not match the signature date of your API requests. This might lead to errors or incomplete functionality. For example, nodes with incorrect time settings won't be included in your lists of managed nodes.
For information about setting the time on your nodes, see Set the time for your Amazon EC2 instance.
-
On Linux managed nodes, verify the signature of SSM Agent.