Policy best practices Predefined AWS managed policies Customer managed policy examples Required permissions to create a service-linked role Required permissions for the API

Amazon EC2 Auto Scaling identity-based policy examples

By default, IAM users and roles don't have permission to create or modify Amazon EC2 Auto Scaling resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that give users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.

To learn how to create an IAM identity-based policy using these example JSON policy documents, see Creating policies on the JSON tab in the IAM User Guide.

Topics

Policy best practices
Predefined AWS managed policies
Customer managed policy examples
Required permissions to create a service-linked role
Required permissions for the API

The following shows an example of a permissions policy.


{
   "Version": "2012-10-17",
   "Statement": [
   {
      "Effect": "Allow",
      "Action": [
          "autoscaling:CreateAutoScalingGroup",
          "autoscaling:UpdateAutoScalingGroup",
          "autoscaling:DeleteAutoScalingGroup"
      ],
      "Resource": "*",
      "Condition": {
          "StringEquals": { "autoscaling:ResourceTag/environment": "test" }
      }
   },
   {
      "Effect": "Allow",
      "Action": [
          "autoscaling:*LaunchConfiguration*",
          "autoscaling:Describe*"
      ],
      "Resource": "*"
   }]
}

This sample policy gives users permissions to create, modify, and delete Auto Scaling groups, but only if the group uses the tag environment=test. Because launch configurations do not support tags, and Describe actions do not support resource-level permissions, you must specify them in a separate statement without conditions. To learn more about the elements within an IAM policy statement, see Amazon EC2 Auto Scaling identity-based policies.

Policy best practices

Identity-based policies are very powerful. They determine whether someone can create, access, or delete Amazon EC2 Auto Scaling resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:

Get started using AWS managed policies – To start using Amazon EC2 Auto Scaling quickly, use AWS managed policies to give your employees the permissions they need. These policies are already available in your account and are maintained and updated by AWS. For more information, see Get started using permissions with AWS managed policies in the IAM User Guide.
Grant least privilege – When you create custom policies, grant only the permissions required to perform a task. Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later. For more information, see Grant least privilege in the IAM User Guide.
Enable MFA for sensitive operations – For extra security, require IAM users to use multi-factor authentication (MFA) to access sensitive resources or API operations. For more information, see Using multi-factor authentication (MFA) in AWS in the IAM User Guide.
Use policy conditions for extra security – To the extent that it's practical, define the conditions under which your identity-based policies allow access to a resource. For example, you can write conditions to specify a range of allowable IP addresses that a request must come from. You can also write conditions to allow requests only within a specified date or time range, or to require the use of SSL or MFA. For more information, see IAM JSON policy elements: Condition in the IAM User Guide.

Note

Some Amazon EC2 Auto Scaling API actions allow you to include specific Auto Scaling groups in your policy that can be created or modified by the action. You can restrict the target resources for these actions by specifying individual Auto Scaling group ARNs. As a best practice, however, we recommend that you use tag-based policies that allow (or deny) actions on Auto Scaling groups with a specific tag.

Predefined AWS managed policies

The managed policies that are created by AWS grant the required permissions for common use cases. You can attach these policies to your IAM users, based on the access that they need. Each policy provides access to all or some of the API actions for Amazon EC2 Auto Scaling.

The following are the AWS managed policies for Amazon EC2 Auto Scaling:

AutoScalingConsoleFullAccess — Grants full access to Amazon EC2 Auto Scaling using the AWS Management Console.
AutoScalingConsoleReadOnlyAccess — Grants read-only access to Amazon EC2 Auto Scaling using the AWS Management Console.
AutoScalingFullAccess — Grants full access to Amazon EC2 Auto Scaling.
AutoScalingReadOnlyAccess — Grants read-only access to Amazon EC2 Auto Scaling.

You can also use the AmazonEC2FullAccess policy to grant full access to all Amazon EC2 resources and related services, including Amazon EC2 Auto Scaling, CloudWatch, and Elastic Load Balancing.

Customer managed policy examples

You can create your own custom IAM policies to allow or deny permissions for IAM users or groups to perform Amazon EC2 Auto Scaling actions. You can attach these custom policies to the IAM users or groups that require the specified permissions. The following examples show permissions for several common use cases.

If you are new to creating policies, we recommend that you first create an IAM user in your account and attach policies to the user. You can use the console to verify the effects of each policy as you attach the policy to the user.

When creating and updating Auto Scaling groups, some actions require that certain other actions be carried out. You can specify these other actions in the Action element of an IAM policy statement. For example, there are additional API actions for Elastic Load Balancing, CloudWatch, and Amazon SNS that might be required depending on the access that you want to provide for a user.

Topics

Control which tag keys and tag values can be used
Control access to Auto Scaling resources based on tags
Control the minimum and maximum capacity of Auto Scaling groups
Control which IAM roles can be passed (using PassRole)
Allow users to change the capacity of Auto Scaling groups
Allow users to create and use launch configurations
Allow users to create and use launch templates

Control which tag keys and tag values can be used

You can use conditions in your IAM policies to control the tag keys and tag values that can be applied to Auto Scaling groups.

To give users permissions to create or tag an Auto Scaling group only if they specify certain tags, use the aws:RequestTag condition key. To allow only specific tag keys, use the aws:TagKeys condition key with the ForAllValues modifier.

The following policy requires users to specify a tag with the key environment in the request. The "?*" value enforces that there is some value for the tag key. To use a wildcard, you must use the StringLike condition operator.


{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": [
          "autoscaling:CreateAutoScalingGroup",
          "autoscaling:CreateOrUpdateTags"
      ],
      "Resource": "*",
      "Condition": {
          "StringLike": { "aws:RequestTag/environment": "?*" }
      }
   }]
}

The following policy specifies that users can only tag Auto Scaling groups with the tags purpose=webserver and cost-center=cc123, and allows only the purpose and cost-center tags (no other tags can be specified).


{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": [
          "autoscaling:CreateAutoScalingGroup",
          "autoscaling:CreateOrUpdateTags"
      ],
      "Resource": "*",
      "Condition": {
          "StringEquals": { 
              "aws:RequestTag/purpose": "webserver",
              "aws:RequestTag/cost-center": "cc123"
          },
          "ForAllValues:StringEquals": { "aws:TagKeys": ["purpose", "cost-center"] }
      }
   }]
}

The following policy requires users to specify at least one tag in the request, and allows only the cost-center and owner keys.


{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": [
          "autoscaling:CreateAutoScalingGroup",
          "autoscaling:CreateOrUpdateTags"
      ],
      "Resource": "*",
      "Condition": {
          "ForAnyValue:StringEquals": { "aws:TagKeys": ["cost-center", "owner"] }
      }
   }]
}

Note

For conditions, the condition key is not case-sensitive and the condition value is case-sensitive. Therefore, to enforce the case-sensitivity of a tag key, use the aws:TagKeys condition key, where the tag key is specified as a value in the condition.

Control access to Auto Scaling resources based on tags

You can also provide tag information in your IAM policies to control access based on the tags that are attached to the Auto Scaling group by using the autoscaling:ResourceTag condition key.

Control access to creating and managing Auto Scaling groups and scaling policies

The following policy gives users permissions to use all Amazon EC2 Auto Scaling actions that include the string Scaling in their names, as long as the Auto Scaling group has the tag purpose=webserver. Because the Describe actions do not support resource-level permissions, you must specify them in a separate statement without conditions.


{
   "Version": "2012-10-17",
   "Statement": [
   {
      "Effect": "Allow",
      "Action": ["autoscaling:*Scaling*"],
      "Resource": "*",
      "Condition": {
          "StringEquals": { "autoscaling:ResourceTag/purpose": "webserver" }
      }
   },
   {
      "Effect": "Allow",
      "Action": "autoscaling:Describe*Scaling*",
      "Resource": "*"
   }]
}

Control which scaling policies can be deleted

The following policy allows users to use the autoscaling:DeletePolicy action to delete a scaling policy. However, it also denies the action if the Auto Scaling group being acted upon has the tag environment=production.


{
   "Version": "2012-10-17",
   "Statement": [
      {
      "Effect": "Allow",
      "Action": "autoscaling:DeletePolicy",
      "Resource": "*"
   },
   {
      "Effect": "Deny",
      "Action": "autoscaling:DeletePolicy",
      "Resource": "*",
      "Condition": {
          "StringEquals": { "autoscaling:ResourceTag/environment": "production" }
      }
   }]
}

Control the minimum and maximum capacity of Auto Scaling groups

Amazon EC2 Auto Scaling allows you to restrict the size of the Auto Scaling groups that can be created. The following policy gives users permissions to create and update all Auto Scaling groups with the tag allowed=true, as long as they don't specify a minimum size less than 1 or a maximum size greater than 10.


{
   "Version": "2012-10-17",
   "Statement": [
   {
      "Effect": "Allow",
      "Action": [
          "autoscaling:CreateAutoScalingGroup",
          "autoscaling:UpdateAutoScalingGroup"
      ],
      "Resource": "*",
      "Condition": {
          "StringEquals": { "autoscaling:ResourceTag/allowed": "true" }, 
          "NumericGreaterThanEqualsIfExists": { "autoscaling:MinSize": 1 },
          "NumericLessThanEqualsIfExists": { "autoscaling:MaxSize": 10 }
      }
   }]
}

Control which IAM roles can be passed (using PassRole)

If you want a user to be able to create Amazon EC2 Auto Scaling resources that specify an instance profile (a container for an IAM role), you must use a policy that includes a statement allowing the user to pass the role, like the following example. By specifying the ARN, the policy grants the user the permission to pass only roles whose name begins with qateam-. For more information, see IAM role for applications that run on Amazon EC2 instances.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::123456789012:role/qateam-*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": [
                        "ec2.amazonaws.com",
                        "ec2.amazonaws.com.cn"
                    ]
                }
            }
        }
    ]
}

Allow users to change the capacity of Auto Scaling groups

The following policy gives users permissions to use the SetDesiredCapacity and TerminateInstanceInAutoScalingGroup API actions. The Resource element uses a wildcard (*) to indicate that users can change the capacity of any Auto Scaling group.


{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": [
          "autoscaling:SetDesiredCapacity",
          "autoscaling:TerminateInstanceInAutoScalingGroup"
      ],
      "Resource": "*"
   }]
}

If you are not using tags to control access to Auto Scaling groups, you can adjust the preceding statement to give users permissions to change the capacity of only Auto Scaling groups whose name begins with devteam-. For more information about specifying the ARN value, see Resources.


      "Resource": "arn:aws:autoscaling:region:123456789012:autoScalingGroup:*:autoScalingGroupName/devteam-*"

You can also specify multiple ARNs by enclosing them in a list. Including the UUID ensures that access is granted to the specific Auto Scaling group. The UUID for a new group is different than the UUID for a deleted group with the same name.


      "Resource": [
          "arn:aws:autoscaling:region:123456789012:autoScalingGroup:7fe02b8e-7442-4c9e-8c8e-85fa99e9b5d9:autoScalingGroupName/devteam-1",
          "arn:aws:autoscaling:region:123456789012:autoScalingGroup:9d8e8ea4-22e1-44c7-a14d-520f8518c2b9:autoScalingGroupName/devteam-2",
          "arn:aws:autoscaling:region:123456789012:autoScalingGroup:60d6b363-ae8b-467c-947f-f1d308935521:autoScalingGroupName/devteam-3"
      ]

Allow users to create and use launch configurations

The following policy gives users permissions to create a launch configuration if the instance type is t2.micro, but only if the name of the launch configuration starts with qateam-. For more information about specifying the ARN value, see Resources. They can specify a launch configuration for an Auto Scaling group only if its name starts with qateam-.

The last part of the statement gives users permissions to describe launch configurations and to access certain Amazon EC2 resources in their AWS account. This gives users minimum permissions to create and manage launch configurations from the Amazon EC2 Auto Scaling console.


{
   "Version": "2012-10-17",
   "Statement": [
   {
      "Effect": "Allow",
      "Action": "autoscaling:CreateLaunchConfiguration",
      "Resource": "arn:aws:autoscaling:region:123456789012:launchConfiguration:*:launchConfigurationName/qateam-*",
      "Condition": {
          "StringEquals": { "autoscaling:InstanceType": "t2.micro" }
      }
   },
   {
      "Effect": "Allow",
      "Action": [
          "autoscaling:CreateAutoScalingGroup",
          "autoscaling:UpdateAutoScalingGroup"
      ],
      "Resource": "*",
      "Condition": {
          "StringLikeIfExists": { "autoscaling:LaunchConfigurationName": "qateam-*" }
      }
   },
   {
      "Effect": "Allow",
      "Action": [
          "autoscaling:DescribeLaunchConfigurations",
          "ec2:DescribeImages",
          "ec2:DescribeVolumes",
          "ec2:DescribeInstances",
          "ec2:DescribeInstanceAttribute",
          "ec2:DescribeKeyPairs",
          "ec2:DescribeSecurityGroups",
          "ec2:DescribeSpotInstanceRequests",
          "ec2:DescribeSpotPriceHistory",
          "ec2:DescribeVpcClassicLink",
          "ec2:DescribeVpcs",
          "ec2:DescribeSubnets"
       ],
       "Resource": "*"
   }]
}

You can add API actions to this policy to provide more options for users, for example:

iam:ListInstanceProfiles: To list instance profiles.
ec2:CreateSecurityGroup: To create a new security group.
ec2:AuthorizeSecurityGroupIngress: To add inbound rules.
ec2:CreateKeyPair: To create a new key pair.

Allow users to create and use launch templates

For example policies, see Launch template support.

Required permissions to create a service-linked role

Amazon EC2 Auto Scaling requires permissions to create a service-linked role the first time that any user in your AWS account calls Amazon EC2 Auto Scaling API actions. If the service-linked role does not exist already, Amazon EC2 Auto Scaling creates it in your account. The service-linked role gives permissions to Amazon EC2 Auto Scaling so that it can call other services on your behalf.

For automatic role creation to succeed, users must have permissions for the iam:CreateServiceLinkedRole action.


"Action": "iam:CreateServiceLinkedRole"

The following shows an example of a permissions policy that allows a user to create an Amazon EC2 Auto Scaling service-linked role for Amazon EC2 Auto Scaling.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "arn:aws:iam::*:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling",
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName":"autoscaling.amazonaws.com"
                }
            }
        }
    ]
}

Control which service-linked role can be passed (using PassRole)

If your users require the ability to pass custom suffix service-linked roles to an Auto Scaling group, you must attach a policy to the users or roles, based on the access that they need. We recommend that you restrict this policy to only the service-linked roles that your users must access. For more information about custom suffix service-linked roles, see Service-linked roles for Amazon EC2 Auto Scaling.

The following example is helpful for facilitating the security of your customer managed CMKs if you give different service-linked roles access to different keys. Depending on your needs, you might have a CMK for the development team, another for the QA team, and another for the finance team. First, create a service-linked role that has access to the required CMK, for example, a service-linked role named AWSServiceRoleForAutoScaling_devteamkeyaccess. Then, to grant permissions to pass that service-linked role to an Auto Scaling group, attach the policy to your IAM users as shown.

The policy in this example gives users permissions to pass the AWSServiceRoleForAutoScaling_devteamkeyaccess role to create any Auto Scaling group whose name begins with devteam-. If they try to specify a different service-linked role, they receive an error. If they choose not to specify a service-linked role, the default AWSServiceRoleForAutoScaling role is used instead.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling_devteamkeyaccess",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": [
                        "autoscaling.amazonaws.com"
                    ]
                },
                "StringLike": {
                    "iam:AssociatedResourceARN": [
                        "arn:aws:autoscaling:region:123456789012:autoScalingGroup:*:autoScalingGroupName/devteam-*"
                    ]
                }
            }
        }
    ]
}

Required permissions for the API

When calling the following actions from the Amazon EC2 Auto Scaling API, users must have permissions from Amazon EC2 and IAM to perform certain actions. You specify the following actions in the Action element of an IAM policy statement.

Create an Auto Scaling group using a launch configuration

autoscaling:CreateAutoScalingGroup
iam:CreateServiceLinkedRole (Needed if you are using the default service-linked role and that role does not yet exist)

Create an Auto Scaling group using a launch template

autoscaling:CreateAutoScalingGroup
ec2:RunInstances
iam:CreateServiceLinkedRole (Needed if you are using the default service-linked role and that role does not yet exist)

Update an Auto Scaling group that uses a launch template

autoscaling:UpdateAutoScalingGroup
ec2:RunInstances

Create a launch configuration

autoscaling:CreateLaunchConfiguration
ec2:DescribeImages
ec2:DescribeInstances
ec2:DescribeInstanceAttribute
ec2:DescribeKeyPairs
ec2:DescribeSecurityGroups
ec2:DescribeSpotInstanceRequests
ec2:DescribeVpcClassicLink

Warning Javascript is disabled or is unavailable in your browser.

To use the AWS Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Service-linked roles

Launch template support