Systems Manager Automation simplifies common maintenance and deployment tasks of EC2 instances and other AWS resources. At times automation failed to start error triggers with a message access denied or invalid assume role.

As a part of our AWS Support Services, we help our Customers to fix AWS related errors regularly.

Let us today discuss the possible causes and fixes for this error.

Automation failed to start error

Systems Manager Automation helps to simplify the common tasks of EC2 instances and other AWS resources.

Automation enables you to build automation workflows, create custom workflows, receive notifications about automation tasks, and monitor automation progress.

However, automation execution can fail with an access denied error or an invalid assume role error. This can happen due to improper configuration of IAM users, roles, and policies for automation.

Access Denied to Systems Manager API

A very common message with the Automation failed to start error is the access denied. It can occur when the IAM user attempting to start the Automation execution does not have permission to invoke the StartAutomationExecution API or if it does not have permission to invoke the API by using the specific Automation document. A typical error message resembles:

Error message: User: user xxx is not authorized to perform: ssm:StartAutomationExecution on resource: document arn (Service: AWSSimpleSystemsManagement; Status Code: 400; Error Code: AccessDeniedException; Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

To resolve this issue, we need to attach the required IAM policy to the corresponding user account.

Use the following procedure to configure a user account to use Automation. The user account we choose will have permission to configure and run Automation.

1. In the IAM navigation pane, choose Users, and then choose the user account we want to configure.
2. On the Permissions tab, in the policies list, verify that either the AmazonSSMFullAccess policy is listed or there is a comparable policy that gives the account permissions to access Systems Manager.
3. Choose to Add inline policy.
4. On the Create policy page, choose Visual Editor, and then choose Choose a service.
5. From AWS Services, choose AWS Identity and Access Management.
6. For Actions, enter PassRole in the Filter actions prompt, and choose PassRole.
7. In the Resources section, choose Add ARN, paste the ARN for the Automation service role, and then choose Add.
8. Choose Review policy.
9. On the Review Policy page, provide a Name for the policy and then choose to Create policy.

Access Denied Because of Missing PassRole Permissions

Another common cause for an access denied message is when the IAM user does not have PassRole permission. The error message looks like:

Error message: User: user xxx is not authorized to perform: iam:PassRole on resource: automation assume role arn (Service: AWSSimpleSystemsManagement; Status Code: 400; Error Code: AccessDeniedException; Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

To resolve this issue, attach the iam:PassRole policy to the role of the IAM user attempting to start the Automation execution.

This enables the Automation service to pass the role to other services or Systems Manager capabilities when running Automation workflows.

To attach the iam:PassRole policy to your Automation role:

1. In the Summary page for the role you just created, choose the Permissions tab.
2. Choose to Add inline policy.
3. On the Create policy page, choose the Visual editor tab.
4. Choose Service, and then choose IAM.
5. Choose Select actions.
6. In the Filter actions text box, type PassRole, and then choose the PassRole option.
7. Choose Resources. Verify that Specific is selected, and then choose Add ARN.
8. In the Specify ARN for role field, paste the Automation role ARN.
9. Choose Add.
10. Choose Review policy.
11. On the Review Policy page, type a name and then choose Create Policy.

Invalid assume role

While we run Automation, it either provides an assume role in the document or passes a parameter value for the document. If the assume role is not specified or configured properly, it leads to errors.

For instance, a malformed assume role can trigger an error “The assume role is improperly formatted”.

To resolve this issue, verify that a valid assume the role is specified in the Automation document or as a runtime parameter when running the Automation.

Likewise, when the assume role does not exist, it triggers the error “The defined assume role is unable to be assumed.

To resolve this issue, we need to create a role for automation. Use the following procedure to create a service role (or assume role) for Systems Manager Automation.

1. Open the IAM console at https://console.aws.amazon.com/iam/.
2. In the navigation pane, choose Roles, and then choose Create role.
3. For the select type of trusted entity, choose AWS service.
4. In the Choose a use case section, choose Systems Manager, and then choose Next: Permissions.
5. On the Attached permissions policy page, search for the AmazonSSMAutomationRole policy, choose it, and then choose Next: Review.
6. Then, on the Review page, type a name in the Role name box, and then type a description.
7. Choose to Create role. The system returns you to the Roles page.
8. Now on the Roles page, choose the role you just created to open the Summary page. Note the Role Name and Role ARN.

[Need any further assistance in fixing Automation errors? – We’re available 24*7]

Conclusion

In short, Systems Manager Automation simplifies common maintenance and deployment tasks of EC2 instances and other AWS resources. At times automation fails to start with an access denied error or an invalid assume role error. Today, we saw how our Support Engineers fix this error.