Did this page help you? Yes No Tell us about it...

Auto Scaling and AWS Identity and Access Management

Auto Scaling integrates with AWS Identity and Access Management (IAM), a service that lets your organization do the following:

Create users and groups under your organization's AWS account
Easily share your AWS account resources between the users in the account
Assign unique security credentials to each user
Granularly control users access to services and resources
Get a single AWS bill for all users under the AWS account

For example, you can use IAM with Auto Scaling to control which users in your AWS Account can create launch configurations, or Auto Scaling groups and triggers.

For general information about IAM, go to:

Using IAM with Auto Scaling

Topics

Auto Scaling does not offer its own resource-based permissions system. However, Auto Scaling integrates with IAM so that you can specify which Auto Scaling actions a User in your AWS Account can perform with Auto Scaling resources in general. However, you can't specify a particular Auto Scaling resource in the policy (e.g., a specific AutoScalingGroup). For example, you could create a policy that gives the Managers group permission to use only DescribeAutoScalingGroups, DescribeLaunchConfigurations, DescribeScalingActivites, and DescribeTriggers. They could then use those actions with any AutoScalingGroups and LaunchConfigurations that belong to your AWS Account.

	Important
	Using Auto Scaling with IAM doesn't change how you use Auto Scaling. There are no changes to Auto Scaling actions, and no new Auto Scaling actions related to Users and access control.

For examples of policies that cover Auto Scaling actions and resources, see Example Policies for Auto Scaling.

Auto Scaling ARNs

Auto Scaling has no ARNs for you to use because you can't specify a particular Auto Scaling resource in an Auto Scaling policy. When writing a policy to control access to Auto Scaling actions, you use * as the resource. For more information about ARNs, see ARNS.

Auto Scaling Actions

In an Auto Scaling policy, you can specify any and all actions that Auto Scaling offers. The action name must be prefixed with the lowercase string autoscaling:. For example: autoscaling:CreateAutoScalingGroup, autoscaling:CreateLaunchConfiguration, autoscaling:* (for all Auto Scaling actions). For a list of the actions, refer to the API action names in the Auto Scaling API Reference.

Auto Scaling Keys

Auto Scaling implements the following policy keys, but no others. For more information about policy keys, see Available Keys in the Conditions section of Element Descriptions topic.

AWS-Wide Policy Keys

aws:CurrentTime (for date/time conditions)
aws:EpochTime (the date in epoch or UNIX time, for use with date/time conditions)
aws:SecureTransport (Boolean representing whether the request was sent using SSL)
aws:SourceIp (the requester's IP address, for use with IP address conditions)
aws:UserAgent (information about the requester's client application, for use with string conditions)

If you use aws:SourceIp, and the request comes from an Amazon EC2 instance, we evaluate the instance's public IP address to determine if access is allowed.

For services that use only SSL, such as Amazon RDS and Amazon Route 53, the aws:SecureTransport key has no meaning.

The key names are case insensitive. For example, aws:CurrentTime is equivalent to AWS:currenttime.

Example Policies for Auto Scaling

This section shows several simple policies for controlling User access to Auto Scaling.

	Note
	In the future, Auto Scaling might add new actions that should logically be included in one of the following policies, based on the policy’s stated goals.

Example 1: Allow a group to create and manage AutoScaling LaunchConfigurations

In this example, we create a policy that gives access to all Auto Scaling actions that include the literal string LaunchConfiguration in the name. The resource is stated as "*", because you can't specify a particular Auto Scaling resource in an Auto Scaling policy.

	Note
	The policy uses wildcards to specify all actions for LaunchConfigurations. You could instead list each action explicitly. If you use the wildcards instead of explicitly listing each action, be aware that if new Auto Scaling actions whose names include the string `LaunchConfiguration` become available, the policy would automatically give the group access to those new actions.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":"autoscaling:*LaunchConfiguration*",
      "Resource":"*"
      }
   ]
}

Example 2: Allow system administrators to create and manage AutoScalingGroups and triggers

In this example, we create a group for system administrators, and assign a policy that gives access to any of the Auto Scaling actions that include the literal string Scaling or Trigger in the name.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":["autoscaling:*Scaling*","autoscaling:*Trigger*"],
      "Resource":"*"
      }
   ]
}

Example 3: Allow developers to change the capacity of an AutoScalingGroup

In this example, we create a group for developers and assign a policy that gives access to the SetDesiredCapacity action.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":"autoscaling:SetDesiredCapacity",
      "Resource":"*"
      }
   ]
}

Document Conventions
Terms of Use

Did this page help you? Yes No Tell us about it...