AWS Cloud Operations & Migrations Blog

Improving Security through Delegated Administration with Amazon EC2 Systems Manager Automation

EC2 Systems Manager Automation simplifies common system maintenance and deployment tasks. You can create workflows to automate repetitive tasks such as systems configuration, deployment and maintenance. Workflows are authored in JSON and saved as Automation documents.

Automation service operates in the context of the user that invokes the execution. Automation documents can be authored with an optional service role (also called an assume Role) with an attached managed policy (AmazonSSMAutomationRole).

  • When the service role is specified: The Automation service executes the document in the context of the role.
  • When the service role is not specified: The Automation service creates a temporary session in the context of the user and then executes the document.

In this blog, we are going to show the two methods for executing Automation. If you are using Automation for the first time or when you would like to automate and execute simple workflows in the context of your Account, the service role is not required. When you would like to control the context in which Automation workflows are executed, and limit permissions needed by a user that executes workflows you will use the service role.

Note: For Automation documents that you expect to run longer than 12 hours, you must specify a service role because the temporary session to execute Automation in the user’s context expires 12 hours after starting the execution.

By including a service role in the Automation document, you can achieve higher security and control. Here’s how delegated administration can be accomplished in the context of personas, where the personas could be different users or the same users within the organization.

  • Author – Creates Automation documents in JSON. For example, a document can take a service role as one parameter, and an AMI ID as another parameter. The document can incorporate Automation actions such as aws:runInstances and awscreateTags to launch and tag instances per corporate IT policies. The author shares the document with other users in the organization. Every time someone executes this document, EC2 instances are created with the specified tags.
  • Administrator – Manages the infrastructure and ensures that appropriate permissions allow users to perform their IT systems management and configuration tasks. For example, the administrator requires the author to create tags with values that help easily identify the instance, and enforces that a service role is used in the document to perform actions. The administrator determines which users can create and launch EC2 instances, and configures permissions to select roles and users to execute the Automation document.
  • Operator – Performs IT tasks. In this post, it is a user who needs to launch an EC2 instance. The user does not require permissions to launch EC2 instances as they have permissions to execute the Automation document.

In this model, administrators can ensure that only users with permissions to execute the document are able to launch EC2 instances. Thus, you can avoid having to grant permissions directly to operators. The administrator can work with the author to also enforce IT policies on an ongoing basis.


To view this model in action, follow the steps below:

  1. Create an IAM user and attach the following policy that explicitly denies the user permissions to launch EC2 instances:
       "Version": "2012-10-17",
       "Statement": [{
          "Action": ["ec2:*"],
  2. Login as the IAM user and launch an EC2 instance via the console or AWS CLI. This step fails.
  3. Create a service role. For more information see Task4: Attach the iam:PassRole Policy to your Automation Role.
  4. Create an Automation document and include the service role that you created in step 4. Allow permissions to execute the document for the IAM user that you created in step 1.
  5. Login as the IAM user and execute the Automation document. This step succeeds and you can successfully launch the EC2 instance.


Automation documents can be executed by any IAM user in their own context without requiring an additional service role. However, it is a best practice to create a service role and enforce delegated administration via Automation. This ensures higher security and control for resources, in addition to auditing. When you use the service role you can tightly scope user permissions. As an administrator, you should also use this model to perform your own operations, and improve safety when managing resources at scale.

About the author

Venkat Krishnamachari is a Product Manager in the Amazon EC2 Systems Manager team. Venkat is excited by the opportunities presented by cloud computing, and loves helping customers benefit from the value of efficient infrastructure and management. In his personal time Venkat volunteers with NGOs and loves producing live theater and music shows.