Amazon EC2 Auto Scaling identity-based policy examples
By default, a brand new user in your AWS account has no permissions to do anything. An IAM administrator must create and assign IAM policies that give an IAM identity (such as a user or role) permission to perform Amazon EC2 Auto Scaling API actions.
To learn how to create an IAM policy using these example JSON policy documents, see Creating policies on the JSON tab in the IAM User Guide.
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/
purpose
": "testing
" } } }, { "Effect": "Allow", "Action": "autoscaling:Describe*", "Resource": "*" }] }
This sample policy grants permissions to create, update, and delete Auto Scaling groups, but
only if the group uses the tag
.
Because purpose=testing
Describe
actions do not support resource-level permissions, you
must specify them in a separate statement without conditions. To launch instances with a
launch template, the user must also have the ec2:RunInstances
permission.
For more information, see Control Amazon EC2 launch template usage in Auto Scaling groups.
Note
You can create your own custom IAM policies to allow or deny permissions for IAM identities (users or roles) to perform Amazon EC2 Auto Scaling actions. You can attach these custom policies to the IAM identities that require the specified permissions. The following examples show permissions for some common use cases.
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.
Examples
- Control the size of the Auto Scaling groups that can be created
- Control which tag keys and tag values can be used
- Control which Auto Scaling groups can be deleted
- Control which scaling policies can be deleted
- Control access to instance refresh actions
- Create a service-linked role
- Control which service-linked role can be passed (using PassRole)
Control the size of the Auto Scaling groups that can be created
The following policy grants permissions to create and update all Auto Scaling groups with
the tag
, as long as the
requester doesn't specify a minimum size less than environment=development
1
or a
maximum size greater than 10
. Whenever possible, use tags to
help you control access to the Auto Scaling groups in your account.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:UpdateAutoScalingGroup" ], "Resource": "*", "Condition": { "StringEquals": { "autoscaling:ResourceTag/
environment
": "development
" }, "NumericGreaterThanEqualsIfExists": { "autoscaling:MinSize":1
}, "NumericLessThanEqualsIfExists": { "autoscaling:MaxSize":10
} } }] }
Alternatively, if you are not using tags to control access to Auto Scaling groups, you can use ARNs to identify the Auto Scaling groups that the IAM policy applies to.
An Auto Scaling group has the following ARN.
"Resource": "arn:aws:autoscaling:
region
:account-id
:autoScalingGroup:*:autoScalingGroupName/my-asg
"
You can also specify multiple ARNs by enclosing them in a list. For more
information about specifying the ARNs of Amazon EC2 Auto Scaling resources in the
Resource
element, see Policy
resources for Amazon EC2 Auto Scaling.
Control which tag keys and tag values can be used
You can also use conditions in your IAM policies to control the tag keys and tag
values that can be applied to Auto Scaling groups. To grant permissions to create or tag an
Auto Scaling group only if the requester specifies 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 the requester to specify a tag with the key
in the request. The
environment
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 the requester can only tag Auto Scaling groups with
the tags
and
purpose=webserver
, and allows only the
cost-center=cc123
and
purpose
tags (no other tags can be
specified).cost-center
{ "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 the requester to specify at least one tag in the
request, and allows only the
and
cost-center
keys.owner
{ "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 which Auto Scaling groups can be deleted
The following policy allows deletion of an Auto Scaling group only if the group has the
tag
.environment=development
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "autoscaling:DeleteAutoScalingGroup", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/
environment
": "development
" } } }] }
Alternatively, if you are not using condition keys to control access to Auto Scaling
groups, you can specify the ARNs of resources in the Resource
element
to control access instead.
The following policy gives users permissions to use the
DeleteAutoScalingGroup
API action, but only for only for Auto Scaling
groups whose name begins with
.devteam-
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "autoscaling:DeleteAutoScalingGroup", "Resource": "arn:aws:autoscaling:
region
:account-id
: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
:account-id
:autoScalingGroup:uuid
:autoScalingGroupName/devteam-1
", "arn:aws:autoscaling:region
:account-id
:autoScalingGroup:uuid
:autoScalingGroupName/devteam-2
", "arn:aws:autoscaling:region
:account-id
:autoScalingGroup:uuid
:autoScalingGroupName/devteam-3
" ]
Control which scaling policies can be deleted
The following policy grants permissions to use the DeletePolicy
action to delete a scaling policy. However, it also denies the action if the Auto Scaling
group being acted upon has the tag
. Whenever
possible, use tags to help you control access to the Auto Scaling groups in your
account.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 access to instance refresh actions
The following policy grants permission to start, roll back, and cancel an instance
refresh only if the Auto Scaling group being acted upon has the tag
. Because
environment=testing
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:StartInstanceRefresh", "autoscaling:CancelInstanceRefresh", "autoscaling:RollbackInstanceRefresh" ], "Resource": "*", "Condition": { "StringEquals": { "autoscaling:ResourceTag/
environment
": "testing
" } } }, { "Effect": "Allow", "Action": "autoscaling:DescribeInstanceRefreshes", "Resource": "*" }] }
To specify a desired configuration in the StartInstanceRefresh
call,
users might need some related permissions, such as:
-
ec2:RunInstances – To launch EC2 instances using a launch template, the user must have the
ec2:RunInstances
permission in an IAM policy. For more information, see Control Amazon EC2 launch template usage in Auto Scaling groups. -
ec2:CreateTags – To launch EC2 instances from a launch template that adds tags to the instances and volumes on creation, the user must have the
ec2:CreateTags
permission in an IAM policy. For more information, see Permissions required to tag instances and volumes. -
iam:PassRole – To launch EC2 instances from a launch template that contains an instance profile (a container for an IAM role), the user must also have the
iam:PassRole
permission in an IAM policy. For more information and an example IAM policy, see IAM role for applications that run on Amazon EC2 instances. -
ssm:GetParameters – To launch EC2 instances from a launch template that uses an AWS Systems Manager parameter, the user must also have the
ssm:GetParameters
permission in an IAM policy. For more information, see Use AWS Systems Manager parameters instead of AMI IDs in launch templates.
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 AWS 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)
Users who create or update Auto Scaling groups and specify a custom suffix service-linked
role in the request require the iam:PassRole
permission.
You can use the iam:PassRole
permission to protect the security of
your AWS KMS customer managed keys if you give different service-linked roles access to
different keys. Depending on your organization's needs, you might have a key 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 key, for example, a
service-linked role named
AWSServiceRoleForAutoScaling_devteamkeyaccess. Then, attach
the policy to an IAM identity, such as a user or role.
The following policy grants permissions to pass the
AWSServiceRoleForAutoScaling_devteamkeyaccess
role to any Auto Scaling group whose name begins with
. If the IAM identity that creates
the Auto Scaling group tries 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.devteam-
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::
account-id
:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling_devteamkeyaccess
", "Condition": { "StringEquals": { "iam:PassedToService": [ "autoscaling.amazonaws.com" ] }, "StringLike": { "iam:AssociatedResourceARN": [ "arn:aws:autoscaling:region
:account-id
:autoScalingGroup:*:autoScalingGroupName/devteam-
*" ] } } }] }
For more information about custom suffix service-linked roles, see Service-linked roles for Amazon EC2 Auto Scaling.