Get started with AWS SSM Automation

Hey, I'm a postgraduate in Cyber Security with practical experience in Software Engineering and DevOps Operations. The top player on TryHackMe platform, multilingual speaker (Kazakh, Russian, English, Spanish, and Turkish), curios person, bookworm, geek, sports lover, and just a good guy to speak with!
AWS Systems Manager (SSM) Automation allows you to automate common and repetitive IT operations and management tasks across AWS resources. With SSM Automation, you can create automation workflows using pre-defined "automation documents" or you can create your own custom workflows.
Automation documents define the sequence of actions to perform on managed instances and other AWS resources. The actions include running shell commands or scripts, making API calls, executing AWS Lambda functions, and more.
AWS SSM Automation can be triggered manually, scheduled, or started in response to changes in system states or AWS CloudWatch events. It can be used for a variety of use-cases such as patch management, deployment tasks, resource provisioning, etc.
Workshop: Stop the EC2 Instances with a custom Automation document
In this workshop exercise, you'll create an EC2 instance and then use AWS SSM Automation to stop the instance automatically.
Prerequisites
An AWS Account with proper permissions to create EC2 instances and use Systems Manager
AWS CLI installed and configured
Steps
1. Create an EC2 instance
Navigate to the EC2 console and launch a new instance with Amazon Linux 2.
2. Install SSM Agent on EC2
If you chose Amazon Linux, the SSM agent should be pre-installed. Otherwise, you'll need to install it.
3. Create an IAM Role for EC2
Go to the IAM console.
Create a new Role.
Attach the
AmazonEC2RoleforSSMpolicy.Attach the role to the EC2 instance you created.
4. Create Automation Document
Go to the Systems Manager Console.
Navigate to
Automationand chooseExecute automation.
Choose
Create automationthen go toEditorand paste the following JSON definition (If you prefer you can also define SSM Documents in YAML format):
{
"description": "Stop an EC2 instance",
"schemaVersion": "0.3",
"description": "This automation stops an EC2 instance",
"parameters": {
"InstanceId": {
"type": "String",
"description": "(Required) The ID of the EC2 instance to stop."
}
},
"mainSteps": [
{
"name": "stopInstance",
"action": "aws:changeInstanceState",
"inputs": {
"InstanceIds": [
"{{InstanceId}}"
],
"DesiredState": "stopped"
}
}
]
}
Give your document a name and save it.

5. Execute Automation
In the Systems Manager Console, navigate to
Automationand chooseExecute automation.Select the automation document you created.

Provide the
InstanceIdparameter (ID of the EC2 instance you created).
Execute the automation.

Your EC2 instance should now be stopped. You can verify this in the EC2 console.

Cleanup
Terminate the EC2 instance to avoid ongoing charges.
Delete any resources you created as part of this workshop.
This workshop provides a basic introduction to AWS SSM Automation. For more complex workflows, you can use features like branching, error handling, and invoking other automation documents or Lambda functions.
Workshop: Applying Security Patches Using AWS Managed Pre-Defined Automation Runbook
In this exercise, you'll use a predefined AWS Systems Manager (SSM) Automation runbook to apply security patches to an EC2 instance running Amazon Linux 2. This helps simulate a typical patch management operation, using AWS's managed resources to make the process easier and more scalable.
Prerequisites
An AWS account with permissions to create and manage EC2 instances and SSM Automations.
An EC2 instance running Amazon Linux 2. Ensure that this instance has the
AmazonEC2RoleforSSMandAmazonSSMAutomationRoleIAM roles attached to it so SSM can manage the instance.
Create AmazonSSMAutomationRole for SSM service
Choose Systems Manager service

Attach
AmazonSSMAutomationRole:
Give proper naming for the role:

Steps
Step 1: Navigate to Systems Manager
Open the AWS Management Console in your web browser.
Navigate to
AWS Systems Managerfrom the list of all services.
Step 2: Choose Runbook
In the left-hand navigation pane, click on
Automation.Click on the
Execute automationbutton.In the "Automation document" section, toggle from "Owned by me" to "Owned by Amazon"
Search for
AWS-UpdateLinuxAmiand select it. This is a pre-defined AWS runbook to update a Linux AMI.
Step 3: Specify Parameters
AWS-UpdateLinuxAmi will create a new AMI after updating the source AMI you specify. You'll need the ID of an existing Amazon Linux 2 AMI for this.
For
SourceAmiId, provide the ID of the Amazon Linux 2 AMI. AMI ID for Amazon Linux 2 t2.micro in us-east-1:ami-0f34c5ae932e6f0e4For
IamInstanceProfileName, andAutomationAssumeRoleuse the roles that you've attached to your EC2 instance (or a role with similar permissions).
Fill in any additional parameters as required for your setup.

Step 4: Execute Automation
- Review your parameters and click on the
Executebutton to start the automation.
The Automation execution will launch a temporary instance with the given source AMI, apply patches, create a new AMI, and terminate the temporary instance.
Step 5: Monitor Execution
After you execute the automation, you'll be redirected to the
Executionspage.Click on the
Execution IDto view the progress and details.Once the status changes to
Success, the automation has completed successfully, and a new AMI with the patches applied is now available.
Step 6: Verify the New AMI
Navigate to the
EC2 Dashboard.Under
Images, clickAMIs.Search for the new AMI created by the automation process. You should see this AMI listed.
(Optional) You may launch a new EC2 instance with this patched AMI to verify that the patches have been applied successfully.
Cleanup
Deregister the new AMI if you do not plan to use it.
Delete the associated snapshot.
Terminate any temporary EC2 instances that were created during this exercise.
This exercise demonstrates how to utilize AWS Managed pre-defined Automation runbooks for common administrative tasks like patch management. It saves time and ensures that you're following AWS-recommended best practices.





