AWS Management Tools Blog

More Automation Actions for Amazon EC2 Systems Manager

Recently, AWS released five new Amazon EC2 Systems Manager Automation actions. These actions allow you to:

  • Launch an AWS CloudFormation stack
  • Delete the stack
  • Insert a delay in your workflow
  • Copy and encrypt Amazon Machine Images (AMIs)
  • Tag AWS resources

These actions extend the existing collection of actions, which can be used to orchestrate tasks such as instance launch, OS-level instance configuration and patching, AWS Lambda function invocation, and AMI creation.

In this post, I introduce the actions, discuss possible uses, and include examples.

Automation Overview

Automation allows you to patch, update agents, or bake applications into an AMI. With Automation, you can avoid the time and effort associated with manual image updates, and instead build AMIs through a streamlined, repeatable, and auditable process. Automation workflows are composed of a series of steps, where each step is based on an action.

Automation actions

Here are the actions:

  • aws:createStack
  • aws:deleteStack
  • aws:sleep
  • aws:createTags
  • aws:copyImage


aws:createStack

Creates a new CloudFormation stack from a template.

Use this action when running a workflow that requires creation of AWS resources. An example is a workflow that creates a new AMI and subsequently invokes a Lambda function, where the Lambda function updates an Auto Scaling group’s launch configuration with the new AMI ID.

By embedding the creation of the Lambda function and the needed IAM permissions directly into the Automation workflow, aws:createStack enables a self-contained solution for both automation and resource creation.

aws:createStack is also helpful when running an Automation workflow requiring AWS resources in a newly created account. In your primary account, create an Automation workflow as a shared Systems Manager document, then execute the workflow locally in each account.

The following example shows an Automation step of type aws:createStack:

{  
   "name":"makeStack",
   "action":"aws:createStack",
   "maxAttempts":1,
   "onFailure":"Abort",
   "inputs":{  
      "Capabilities":[  
         "CAPABILITY_IAM"
      ],
      "StackName":"myStack",
      "TemplateURL":"http://s3.amazonaws.com/mybucket/myStackTemplate",
      "TimeoutInMinutes":5
   }
}

 

aws:deleteStack

Deletes a CloudFormation stack.

To complete the example above, you can add the aws:deleteStack step to your workflow to remove all resources created during the execution of the Automation workflow.

{  
   "name":"deleteStack",
   "action":"aws:deleteStack",
   "maxAttempts":1,
   "onFailure":"Abort",
   "inputs":{  
      "StackName":"{{stackName}}"
   }
}

 

aws:sleep

Delays Automation execution for a specified amount of time.

Use this action to insert a delay in your workflow. You can set the delay over a specific duration, or until a specific time is reached. Let’s say you have multiple Run Command steps of type aws:runCommand that you’re running to configure an instance, and you’d like to ensure a pause between them. Using aws:sleep, you can insert a delay.

The following examples show how to define the sleep interval using either a duration or timestamp―both are formatted following ISO 8601.

{  
   "name":"sleep",
   "action":"aws:sleep",
   "inputs":{  
      "Duration":"PT10M"
   }
}

Duration passed in as a parameter:

{  
   "name":"sleep",
   "action":"aws:sleep",
   "inputs":{  
      "Duration":"PT{{delayInMinutes}}M"
   }
}

Using a timestamp to terminate the sleep interval:

{  
   "name":"sleep",
   "action":"aws:sleep",
   "inputs":{  
      "Timestamp":"2020-01-01T01:00:00Z"
   }
}

aws:createTags
Creates new tags for resources such as Amazon EC2 instances or Amazon Machine Images (AMIs).

Tagging is a popular way to keep track of AMIs. With aws:createTags, your workflow can tag images after it creates them. Similarly, you can use tags to keep track of any temporary instances created by your workflow. In the event that your workflow ceases before terminating the instances, your tagged temporary instances are easier to track down.

The following example shows how to tag an AMI and an instance as production resources for a particular department:

{  
   "name":"createTags",
   "action":"aws:createTags",
   "maxAttempts":3,
   "onFailure":"Abort",
   "inputs":{  
      "ResourceType":"EC2",
      "ResourceIds":[  
         "ami-9a3768fa",
         "i-02951acd5111a8169"
      ],
      "Tags":[  
         {  
            "Key":"production",
            "Value":""
         },
         {  
            "Key":"department",
            "Value":"devops"
         }
      ]
   }
}

 

aws:copyImage
Copies an AMI from any region into the current region. This action can also encrypt the new AMI.

An example use case is to copy images across regions. To automate the process, you can use a Lambda function to post to an SNS topic upon the creation of a new image in the source region. A Lambda function in the target region is then trigged by this topic, and invokes Automation to copy the image. After you’ve copied the shared image, you can encrypt using a second aws:copyImage action in the workflow.

The following example creates a copy of an AMI from the Seoul region. The new AMI is copied to the region where you initiated the Automation action.

 { 
    "name": "createEncryptedCopy",
    "action": "aws:copyImage",
    "maxAttempts": 3,
    "onFailure": "Abort",
    "inputs": {
       "SourceImageId": "ami-0fe10819",
       "SourceRegion": "ap-northeast-2",
       "ImageName": "Encrypted copy of LAMP base AMI in ap-northeast-2",
       "Encrypted": false
    } 
} 

Summary

In this post, I discussed five recently released Automation actions that can help you orchestrate even more tasks with other AWS services.

Before creating your own Automation workflow, try the Getting Started Walkthrough and run your first workflow using a AWS-managed Automation document. Then, try creating your own workflow, using AWS-UpdateLinuxAmi or AWS-UpdateWindowsAmi (coming soon!) as a template.

 

About the author

Taylor Anderson is a product manager for EC2 Systems Manager. When he’s not working on new hybrid-cloud management tools, he enjoys spending time writing code for Arduino projects, or kiteboarding the waters of Puget Sound.