custom policies for Auto Scaling - Auto Scaling - Alibaba Cloud Documentation Center

When system policies don't give you the level of access control you need, create custom policies to enforce the principle of least privilege. Custom policies let you restrict Auto Scaling permissions by resource tags, regions, or specific actions—reducing the blast radius of any misconfigured or compromised identity.

What is a custom policy?

Resource Access Management (RAM) policies fall into two types: system policies (managed by Alibaba Cloud) and custom policies (managed by you). Custom policies give you fine-grained control that system policies can't provide.

How custom policies work

Create a custom policy with the permissions your use case requires.
Attach the policy to a RAM user, RAM user group, or RAM role (the principal). The policy takes effect immediately.
Update or version the policy using RAM's version management mechanism to track changes without losing previous configurations.
Detach and delete the policy when it's no longer needed. A policy attached to a principal must be detached before you can delete it.

Common scenarios and sample custom policies

The following examples cover the most common access control patterns for Auto Scaling. Each policy uses the ess: action prefix, which maps to Auto Scaling API operations.

Note: Describe-type actions (such as ess:DescribeRegions and ess:DescribeAlarms) do not support resource-level permissions. Include them in a separate statement without Condition or resource-scoped Resource, so you can still list and view resources regardless of the tag or region restrictions applied elsewhere.

Restrict scaling group creation to specific tags

Use this policy to enforce a tagging requirement at creation time. With this policy, you can create a scaling group only if you add the tags environment:test and team:game1 during the request. Without both tags, the creation request is denied.

{
    "Effect": "Allow",
    "Action": "ess:Create*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "acs:RequestTag/environment": "test",
            "acs:RequestTag/team": "game1"
        }
    }
}

The acs:RequestTag condition key matches tags that are being set in the request. This is different from acs:ResourceTag, which matches tags already applied to an existing resource (see the next example).

Restrict operations to scaling groups with specific tags

Use this policy when multiple scaling groups exist in an account and you need to isolate access by team or environment. In this example:

Scaling Group 1 has tags environment:test and team:game1.
Scaling Group 2 has tags environment:dev and team:game2.

With this policy, you can perform any ess:* action on Scaling Group 1, but are explicitly denied access to Scaling Group 2. The third statement allows Describe and Alarm-related actions on all resources without tag conditions, because these actions don't support resource-level permissions.

{
    "Version": "1",
    "Statement": [
        {
            "Action": "ess:*",
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "test",
                    "acs:ResourceTag/Team": "game1"
                }
            }
        },
        {
            "Action": "ess:*",
            "Effect": "Deny",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "dev",
                    "acs:ResourceTag/team": "game2"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ess:DescribeRegions",
                "ess:CreateScheduledTask",
                "ess:ModifyScheduledTask",
                "ess:DescribeScheduledTasks",
                "ess:DeleteScheduledTask",
                "ess:CreateAlarm",
                "ess:DescribeAlarms",
                "ess:ModifyAlarm",
                "ess:EnableAlarm",
                "ess:DeleteAlarm"
            ],
            "Resource": "*"
        }
    ]
}

Note: The acs:ResourceTag/Team key uses a capital T in the Allow statement. This matches the exact tag key casing on Scaling Group 1. Tag key comparisons are case-sensitive—verify that your tag keys match the casing in the policy.

Restrict operations to a specific region

Use this policy to confine Auto Scaling activity to a single region. In this example, the policy allows all ess:* actions in China (Hangzhou) and denies them in China (Beijing). The third statement allows Describe and scheduling-related actions globally, because they don't support resource-level permissions.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ess:*",
            "Resource": "acs:ess:cn-hangzhou:160998252992****:*"
        },
        {
            "Effect": "Deny",
            "Action": "ess:*",
            "Resource": "acs:ess:cn-beijing:160998252992****:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ess:DescribeRegions",
                "ess:CreateScheduledTask",
                "ess:ModifyScheduledTask",
                "ess:DescribeScheduledTasks",
                "ess:DeleteScheduledTask",
                "ess:CreateAlarm",
                "ess:DescribeAlarms",
                "ess:ModifyAlarm",
                "ess:EnableAlarm",
                "ess:DeleteAlarm"
            ],
            "Resource": "*"
        }
    ]
}

The resource ARN format is acs:ess:<region-id>:<account-id>:*. Replace <region-id> with the target region ID (for example, cn-hangzhou) and <account-id> with your Alibaba Cloud account ID.

Authorization

Before writing custom policies, review the Auto Scaling authorization rules to understand which actions support resource-level permissions and which require a wildcard resource. See RAM authorization for the full action-to-permission mapping.

Auto Scaling:Custom policies for Auto Scaling