• The AWS Systems Manager CloudWatch Dashboard will no longer be available after April 30, 2026. Customers can continue to use Amazon CloudWatch console to view, create, and manage their Amazon CloudWatch dashboards, just as they do today. For more information, see [Amazon CloudWatch Dashboard documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). # Setting up Automation To set up Automation, a tool in AWS Systems Manager, you must verify user access to the Automation service and situationally configure roles so that the service can perform actions on your resources. We also recommend that you opt in to the adaptive concurrency mode in your Automation preferences. Adaptive concurrency automatically scales your automation quota to meet your needs. For more information, see [Allowing Automation to adapt to your concurrency needs](adaptive-concurrency.md). To ensure proper access to AWS Systems Manager Automation, review the following user and service role requirements. ## Verifying user access for runbooks Verify that you have permission to use runbooks. If your user, group, or role is assigned administrator permissions, then you have access to Systems Manager Automation. If you don't have administrator permissions, then an administrator must give you permission by assigning the `AmazonSSMFullAccess` managed policy, or a policy that provides comparable permissions, to your user, group, or role. **Important** The IAM policy `AmazonSSMFullAccess` grants permissions to Systems Manager actions. However, some runbooks require permissions to other services, such as the runbook `AWS-ReleaseElasticIP`, which requires IAM permissions for `ec2:ReleaseAddress`. Therefore, you must review the actions taken in a runbook to ensure your user, group, or role is assigned the necessary permissions to perform the actions included in the runbook. ## Configuring a service role (assume role) access for automations Automations can be initiated under the context of a service role (or *assume role*). This allows the service to perform actions on your behalf. If you don't specify an assume role, Automation uses the context of the user who invoked the automation. However, the following situations require that you specify a service role for Automation: + When you want to restrict a user's permissions on a resource, but you want the user to run an automation that requires elevated permissions. In this scenario, you can create a service role with elevated permissions and allow the user to run the automation. + When you create a Systems Manager State Manager association that runs a runbook. + When you have operations that you expect to run longer than 12 hours. + When you're running a runbook not owned by Amazon that uses the `aws:executeScript` action to call an AWS API operation or to act on an AWS resource. For information, see [Permissions for using runbooks](automation-document-script-considerations.md#script-permissions). If you need to create a service role for Automation, you can use one of the following methods. **Topics** + [Verifying user access for runbooks](#automation-setup-user-access) + [Configuring a service role (assume role) access for automations](#automation-setup-configure-role) + [Create service roles for Automation by using CloudFormation](automation-setup-cloudformation.md) + [Create the service roles for Automation using the console](automation-setup-iam.md) + [Setting up identity based policies examples](automation-setup-identity-based-policies.md) + [Allowing Automation to adapt to your concurrency needs](adaptive-concurrency.md) + [Configuring automatic retry for throttled operations](automation-throttling-retry.md) + [Implement change controls for Automation](automation-change-calendar-integration.md) # Create service roles for Automation by using CloudFormation You can create a service role for Automation, a tool in AWS Systems Manager, from an AWS CloudFormation template. After you create the service role, you can specify the service role in runbooks using the parameter `AutomationAssumeRole`. ## Create the service role using CloudFormation Use the following procedure to create the required AWS Identity and Access Management (IAM) role for Systems Manager Automation by using CloudFormation. **To create the required IAM role** 1. Download and unzip the [https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/AWS-SystemsManager-AutomationServiceRole.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/AWS-SystemsManager-AutomationServiceRole.zip) file. This file includes the `AWS-SystemsManager-AutomationServiceRole.yaml` CloudFormation template file. 1. Open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Choose **Create Stack**. 1. In the **Specify template** section, choose **Upload a template file**. 1. Choose **Browse**, and then choose the `AWS-SystemsManager-AutomationServiceRole.yaml` CloudFormation template file. 1. Choose **Next**. 1. On the **Specify stack details** page, in the **Stack name** field, enter a name. 1. On the **Configure stack options** page, you don’t need to make any selections. Choose **Next**. 1. On the **Review** page, scroll down and choose the **I acknowledge that CloudFormation might create IAM resources** option. 1. Choose **Create**. CloudFormation shows the **CREATE\$1IN\$1PROGRESS** status for approximately three minutes. The status changes to **CREATE\$1COMPLETE** after the stack is created and your roles are ready to use. **Important** If you run an automation workflow that invokes other services by using an AWS Identity and Access Management (IAM) service role, be aware that the service role must be configured with permission to invoke those services. This requirement applies to all AWS Automation runbooks (`AWS-*` runbooks) such as the `AWS-ConfigureS3BucketLogging`, `AWS-CreateDynamoDBBackup`, and `AWS-RestartEC2Instance` runbooks, to name a few. This requirement also applies to any custom Automation runbooks you create that invoke other AWS services by using actions that call other services. For example, if you use the `aws:executeAwsApi`, `aws:createStack`, or `aws:copyImage` actions, configure the service role with permission to invoke those services. You can give permissions to other AWS services by adding an IAM inline policy to the role. For more information, see [(Optional) Add an Automation inline policy or customer managed policy to invoke other AWS services](automation-setup-iam.md#add-inline-policy). ## Copy role information for Automation Use the following procedure to copy information about the Automation service role from the CloudFormation console. You must specify these roles when you use a runbook. **Note** You don't need to copy role information using this procedure if you run the `AWS-UpdateLinuxAmi` or `AWS-UpdateWindowsAmi` runbooks. These runbooks already have the required roles specified as default values. The roles specified in these runbooks use IAM managed policies. **To copy the role names** 1. Open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. Select the Automation **Stack name** you created in the previous procedure. 1. Choose the **Resources** tab. 1. Choose the **Physical ID** link for **AutomationServiceRole**. The IAM console opens to a summary of the Automation service role. 1. Copy the Amazon Resource Name (ARN) next to **Role ARN**. The ARN is similar to the following: `arn:aws:iam::12345678:role/AutomationServiceRole` 1. Paste the ARN into a text file to use later. You have finished configuring the service role for Automation. You can now use the Automation service role ARN in your runbooks. # Create the service roles for Automation using the console If you need to create a service role for Automation, a tool in AWS Systems Manager, complete the following tasks. For more information about when a service role is required for Automation, see [Setting up Automation](automation-setup.md). **Topics** + [Task 1: Create a service role for Automation](#create-service-role) + [Task 2: Attach the iam:PassRole policy to your Automation role](#attach-passrole-policy) ## Task 1: Create a service role for Automation Use the following procedure to create a service role (or *assume role*) for Systems Manager Automation. **Note** You can also use this role in runbooks, such as the `AWS-CreateManagedLinuxInstance` runbook. Using this role, or the Amazon Resource Name (ARN) of an AWS Identity and Access Management (IAM) role, in runbooks allows Automation to perform actions in your environment, such as launch new instances and perform actions on your behalf. **To create an IAM role and allow Automation to assume it** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**, and then choose **Create role**. 1. Under **Select type of trusted entity**, choose **AWS service**. 1. In the **Choose a use case** section, choose **Systems Manager**, and then choose **Next: Permissions**. 1. On the **Attached permissions policy** page, search for the **AmazonSSMAutomationRole** policy, choose it, and then choose **Next: Review**. 1. On the **Review** page, enter a name in the **Role name** box, and then enter a description. 1. Choose **Create role**. The system returns you to the **Roles** page. 1. On the **Roles** page, choose the role you just created to open the **Summary** page. Note the **Role Name** and **Role ARN**. You will specify the role ARN when you attach the **iam:PassRole** policy to your IAM account in the next procedure. You can also specify the role name and the ARN in runbooks. **Note** The `AmazonSSMAutomationRole` policy assigns the Automation role permission to a subset of AWS Lambda functions within your account. These functions begin with "Automation". If you plan to use Automation with Lambda functions, the Lambda ARN must use the following format: `"arn:aws:lambda:*:*:function:Automation*"` If you have existing Lambda functions whose ARNs don't use this format, then you must also attach an additional Lambda policy to your automation role, such as the **AWSLambdaRole** policy. The additional policy or role must provide broader access to Lambda functions within the AWS account. After creating your service role, we recommend editing the trust policy to help prevent the cross-service confused deputy problem. The *confused deputy problem* is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that Automation gives another service to the resource. If the `aws:SourceArn` value doesn't contain the account ID, such as an Amazon S3 bucket ARN, you must use both global condition context keys to limit permissions. If you use both global condition context keys and the `aws:SourceArn` value contains the account ID, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement. Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use. The value of `aws:SourceArn` must be the ARN for automation executions. If you don't know the full ARN of the resource or if you're specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. For example, `arn:aws:ssm:*:123456789012:automation-execution/*`. The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys for Automation to prevent the confused deputy problem. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:ssm:*:123456789012:automation-execution/*" } } } ] } ``` ------ **To modify the role's trust policy** 1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. 1. In the list of roles in your account, choose the name of your Automation service role. 1. Choose the **Trust relationships** tab, and then choose **Edit trust relationship**. 1. Edit the trust policy using the `aws:SourceArn` and `aws:SourceAccount` global condition context keys for Automation to prevent the confused deputy problem. 1. Choose **Update Trust Policy** to save your changes. ### (Optional) Add an Automation inline policy or customer managed policy to invoke other AWS services If you run an automation that invokes other AWS services by using an IAM service role, the service role must be configured with permission to invoke those services. This requirement applies to all AWS Automation runbooks (`AWS-*` runbooks) such as the `AWS-ConfigureS3BucketLogging`, `AWS-CreateDynamoDBBackup`, and `AWS-RestartEC2Instance` runbooks, to name a few. This requirement also applies to any custom runbooks you create that invoke other AWS services by using actions that call other services. For example, if you use the `aws:executeAwsApi`, `aws:CreateStack`, or `aws:copyImage` actions, to name a few, then you must configure the service role with permission to invoke those services. You can give permissions to other AWS services by adding an IAM inline policy or customer managed policy to the role. **To embed an inline policy for a service role (IAM console)** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **Roles**. 1. In the list, choose the name of the role that you want to edit. 1. Choose the **Permissions** tab. 1. In the **Add permissions** dropdown, choose **Attach policies** or **Create inline policy**. 1. If you choose **Attach policies**, select the check box next to the policy you want to add and choose **Add permissions**. 1. If you choose **Create inline policy**, choose the **JSON** tab. 1. Enter a JSON Policy document for the AWS services you want to invoke. Here are two example JSON Policy documents. **Amazon S3 PutObject and GetObject Example** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] } ``` ------ **Amazon EC2 CreateSnapshot and DescribeSnapShots Example** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":"ec2:CreateSnapshot", "Resource":"*" }, { "Effect":"Allow", "Action":"ec2:DescribeSnapshots", "Resource":"*" } ] } ``` ------ For details about the IAM policy language, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*. 1. When you're finished, choose **Review policy**. The [Policy Validator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_policy-validator.html) reports any syntax errors. 1. On the **Review policy** page, enter a **Name** for the policy that you're creating. Review the policy **Summary** to see the permissions that are granted by your policy. Then choose **Create policy** to save your work. 1. After you create an inline policy, it's automatically embedded in your role. ## Task 2: Attach the iam:PassRole policy to your Automation role Use the following procedure to attach the `iam:PassRole` policy to your Automation service role. This allows the Automation service to pass the role to other services or Systems Manager tools when running automations. **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. 1. Choose **Add inline policy**. 1. On the **Create policy** page, choose the **Visual editor** tab. 1. Choose **Service**, and then choose **IAM**. 1. Choose **Select actions**. 1. In the **Filter actions** text box, type **PassRole**, and then choose the **PassRole** option. 1. Choose **Resources**. Verify that **Specific** is selected, and then choose **Add ARN**. 1. In the **Specify ARN for role** field, paste the Automation role ARN that you copied at the end of Task 1. The system populates the **Account** and **Role name with path** fields. **Note** If you want the Automation service role to attach an IAM instance profile role to an EC2 instance, then you must add the ARN of the IAM instance profile role. This allows the Automation service role to pass the IAM instance profile role to the target EC2 instance. 1. Choose **Add**. 1. Choose **Review policy**. 1. On the **Review Policy** page, enter a name and then choose **Create Policy**. # Setting up identity based policies examples The following sections provide example IAM identity-based policies for AWS Systems Manager Automation service. For more information about how to create an IAM identity-based policy using these example JSON Policy documents, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*. **Note** All examples contain fictitious account IDs. The account ID shouldn't be specified in the Amazon Resource Name (ARN) for AWS owned public documents. **Examples** + [Example 1: Allow a user to run an automation document and view the automation execution](#automation-setup-identity-based-policies-example-1) + [Example 2: Allow a user to run a specific version of an automation document](#automation-setup-identity-based-policies-example-2) + [Example 3: Allow a user to execute automation documents with a specific tag](#automation-setup-identity-based-policies-example-3) + [Example 4: Allow a user to run an automation document when a specific tag parameter is provided for the automation execution](#automation-setup-identity-based-policies-example-4) ## Example 1: Allow a user to run an automation document and view the automation execution The following example IAM policy allows a user to do the following: + Run the automation document specified in the policy. The name of the document is determined by the following entry. ``` arn:aws:ssm:*:111122223333:document/{{DocumentName}} ``` + Stop and send signals to an automation execution. + View details about the automation execution after it has been started. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:StartAutomationExecution", "Effect": "Allow", "Resource": [ "arn:aws:ssm:*:111122223333:document/{{DocumentName}}", "arn:aws:ssm:*:111122223333:automation-execution/*" ] }, { "Action": [ "ssm:StopAutomationExecution", "ssm:GetAutomationExecution", "ssm:DescribeAutomationExecutions", "ssm:DescribeAutomationStepExecutions", "ssm:SendAutomationSignal" ], "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ], "Effect": "Allow" } ] } ``` ------ ## Example 2: Allow a user to run a specific version of an automation document The following example IAM policy allows a user to run a specific version of an automation document: + The name of the automation document is determined by the following entry. ``` arn:aws:ssm:*:111122223333:document/{{DocumentName}} ``` + The version of the automation document is determined by the following entry. ``` "ssm:DocumentVersion": "5" ``` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:StartAutomationExecution", "Effect": "Allow", "Resource": [ "arn:aws:ssm:*:111122223333:document/{{DocumentName}}" ], "Condition": { "ForAnyValue:StringEquals": { "ssm:DocumentVersion": ["5"] } } }, { "Action": [ "ssm:StartAutomationExecution" ], "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ], "Effect": "Allow" }, { "Action": [ "ssm:StopAutomationExecution", "ssm:GetAutomationExecution", "ssm:DescribeAutomationExecutions", "ssm:DescribeAutomationStepExecutions", "ssm:SendAutomationSignal" ], "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ], "Effect": "Allow" } ] } ``` ------ ## Example 3: Allow a user to execute automation documents with a specific tag The following example IAM policy allows a user to run any automation document that has a specific tag: + The name of the automation document is determined by the following entry. ``` arn:aws:ssm:*:111122223333:document/{{DocumentName}} ``` + The tag of the automation document is determined by the following entry. ``` "ssm:DocumentVersion": "5" ``` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:StartAutomationExecution", "Effect": "Allow", "Resource": [ "arn:aws:ssm:*:111122223333:document/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/stage": "production" } } }, { "Action": [ "ssm:StartAutomationExecution" ], "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ], "Effect": "Allow" }, { "Action": [ "ssm:StopAutomationExecution", "ssm:GetAutomationExecution", "ssm:DescribeAutomationExecutions", "ssm:DescribeAutomationStepExecutions", "ssm:SendAutomationSignal" ], "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ], "Effect": "Allow" } ] } ``` ------ ## Example 4: Allow a user to run an automation document when a specific tag parameter is provided for the automation execution The following example IAM policy grants permissions to a user to run automation documents when a specific tag parameter is provided for the automation execution: + Run the automation document specified in the policy. The name of the document is determined by the following entry. ``` arn:aws:ssm:*:111122223333:document/{{DocumentName}} ``` + Must provide a specific tag parameter for the automation execution. The tag parameter for the automation execution resource is determined by the following entry. ``` "aws:ResourceTag/stage": "production" ``` + Stop and send signals to automation executions that have the specified tag. + View details about the automation executions that have the specified tag. + Add the specified tag to SSM resources. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:StartAutomationExecution", "Effect": "Allow", "Resource": [ "arn:aws:ssm:*:111122223333:document/{{DocumentName}}" ] }, { "Action": [ "ssm:StartAutomationExecution", "ssm:StopAutomationExecution", "ssm:GetAutomationExecution", "ssm:DescribeAutomationExecutions", "ssm:DescribeAutomationStepExecutions", "ssm:SendAutomationSignal" ], "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ], "Effect": "Allow", "Condition": { "StringEquals": { "aws:ResourceTag/environment": "beta" } } }, { "Action": "ssm:AddTagsToResource", "Effect": "Allow", "Resource": [ "arn:aws:ssm:*:111122223333:automation-execution/*" ] } ] } ``` ------ # Allowing Automation to adapt to your concurrency needs By default, Automation allows you to run up to 100 concurrent automations at a time. Automation also provides an optional setting that you can use to adjust your concurrency automation quota automatically. With this setting, your concurrency automation quota can accommodate up to 500 concurrent automations, depending on available resources. **Note** If your automation calls API operations, adaptively scaling to your targets can result in throttling exceptions. If recurring throttling exceptions occur when running automations with adaptive concurrency turned on, you might have to request quota increases for the API operation if available. **To turn on adaptive concurrency using the AWS Management Console** 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, choose **Automation**. 1. Choose the **Preferences** tab, and then choose **Edit**. 1. Select the check box next to **Enable adaptive concurrency**. 1. Choose **Save**. **To turn on adaptive concurrency using the command line** + Open the AWS CLI or Tools for Windows PowerShell and run the following command to turn on adaptive concurrency for your account in the requesting Region. ------ #### [ Linux & macOS ] ``` aws ssm update-service-setting \ --setting-id /ssm/automation/enable-adaptive-concurrency \ --setting-value True ``` ------ #### [ Windows ] ``` aws ssm update-service-setting ^ --setting-id /ssm/automation/enable-adaptive-concurrency ^ --setting-value True ``` ------ #### [ PowerShell ] ``` Update-SSMServiceSetting ` -SettingId "/ssm/automation/enable-adaptive-concurrency" ` -SettingValue "True" ``` ------ # Configuring automatic retry for throttled operations There is a limit on the number of concurrent automation executions that can run in each account. Attempting to run several automations concurrently in an account can lead to throttling issues. You can use the automatic throttling retry capability to configure retry behavior for throttled automation steps. Automatic throttling retry for automation actions provides a more resilient execution environment for high-scale operations. The throttling retry capability supports all [automation actions](automation-actions.md) except for `aws:executeScript`. The throttling retry setting works in addition to the existing `maxAttempts` step property. When both are configured, the system first attempts throttling retries within the specified time limit, then applies the `maxAttempts` setting if the step continues to fail. **To configure throttling retry using the AWS Management Console** 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, choose **Automation**. 1. Choose the **Preferences** tab, and then choose **Edit**. 1. In the **Throttling retry time limit** field, enter a value between 0 and 3600 seconds. This specifies the maximum time that the system retries a step that is throttled. 1. Choose **Save**. **To configure throttling retry using the command line** + Open the AWS CLI or Tools for Windows PowerShell and run the following command to configure throttling retry for your account in the requesting Region. ------ #### [ Linux & macOS ] ``` aws ssm update-service-setting \ --setting-id /ssm/automation/throttled-retry-time-limit \ --setting-value 3600 ``` ------ #### [ Windows ] ``` aws ssm update-service-setting ^ --setting-id /ssm/automation/throttled-retry-time-limit ^ --setting-value 3600 ``` ------ #### [ PowerShell ] ``` Update-SSMServiceSetting ` -SettingId "/ssm/automation/throttled-retry-time-limit" ` -SettingValue "3600" ``` ------ # Implement change controls for Automation By default, Automation allows you to use runbooks without date and time constraints. By integrating Automation with Change Calendar, you can implement change controls to all automations in your AWS account. With this setting, AWS Identity and Access Management (IAM) principals in your account can only run automations during the time periods allowed by your change calendar. To learn more about working with Change Calendar, see [Working with Change Calendar](systems-manager-change-calendar-working.md). **To turn on change controls (console)** 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, choose **Automation**. 1. Choose the **Preferences** tab, and then choose **Edit**. 1. Select the check box next to **Turn on Change Calendar integration**. 1. In the **Choose a change calendar** dropdown list, choose the change calendar that you want Automation to follow. 1. Choose **Save**.