All Products
Search
Document Center

Auto Scaling:Automatically manage ECS instances in a MongoDB IP whitelist

Last Updated:Aug 25, 2026

This topic describes how to combine the lifecycle hook feature of Auto Scaling and a CloudOps Orchestration Service (OOS) template to first put Elastic Compute Service (ECS) instances into a Pending state and then automate the task for adding or removing the instance IP addresses to or from the IP address whitelists of ApsaraDB for MongoDB (MongoDB) instances.

Prerequisites

  • A scaling group is created and enabled.

  • A MongoDB instance is created.

  • A RAM role is created for the OOS service. For this role, the trusted entity is set to Alibaba Cloud Service and the trusted service is set to CloudOps Orchestration Service. The role must have the permissions to execute OOS templates. For more information, see Set and grant a RAM role for OOS.

    Note

    This topic uses OOSServiceRole as an example RAM role. You can also use a different custom RAM role.

Background information

Auto Scaling currently supports only the integration with Server Load Balancer (SLB) and ApsaraDB RDS. If you store your application data on a MongoDB instance, manually updating the IP address whitelist for the MongoDB instance with the private IP addresses of your ECS instances leads to inefficient operation. To enhance operational efficiency, consider automating updates of the IP address whitelist for your MongoDB instance by combing the lifecycle hook feature of Auto Scaling and an OOS template. Take note of the following usage notes:

  • If your scaling group contains existing ECS instances, you must manually add the private IP addresses of the ECS instances to the IP address whitelist of the MongoDB instance. Otherwise, an error occurs when you remove an instance IP address from the IP address whitelist of the MongoDB instance.

  • You must use NotificationMetadata (metadata for short) to specify parameters required to create OOS executions.

    • metadata must be in the JSON string format.

    • The keys in metadata must match the parameters in the OOS template.

    • For parameters that have no default settings in the OOS template, you must specify values for these parameters. For parameters that have default settings in the OOS template, you can specify whether to overwrite their default settings.

Procedure

In this example, a public OOS template named LifeCycleModifyMongoDBIPWhitelist is used to show how to automate the addition of instance IP addresses to the IP address whitelist of a MongoDB instance during a scale-out event. Perform the following steps:

Note

If you want to automate the removal of instance IP addresses from the IP address whitelist of your MongoDB instance, you can create a lifecycle hook for scale-in purposes and apply the lifecycle hook during a scale-in event.

Step 1: Grant a RAM role the permissions on OOS

You must have the permissions to execute OOS templates. The ACS-ESS-LifeCycleModifyMongoDBIPWhitelist template includes ECS, Auto Scaling, and MongoDB resources that are required to perform O&M tasks.

  1. Log on to the Resource Access Management (RAM) console.

  2. Create a policy.

    1. In the navigation pane on the left, click Permission Management > Access Policies.

    2. Click Create Access Policy.

    3. On the Create Policy page, click the JSON Editor tab, set the parameters, and then click OK.

      The following table describes the settings that are used in this example. Any parameters not covered in the following table default to their predefined settings.

      Parameter

      Description

      Policy name

      Enter ESSHookPolicyForMongoDBWhitelist.

      Policy Document

      Enter the following content:

      {
          "Version": "1",
          "Statement": [
              {
                  "Action": [
                      "ecs:DescribeInstances"
                  ],
                  "Resource": "*",
                  "Effect": "Allow"
              },
              {
                  "Action": [
                      "dds:ModifySecurityIps"
                  ],
                  "Resource": "*",
                  "Effect": "Allow"
              },
              {
                  "Action": [
                      "ess:CompleteLifecycleAction"
                  ],
                  "Resource": "*",
                  "Effect": "Allow"
              }
          ]
      }
  3. Attach the policy to the OOSServiceRole RAM role.

    1. In the navigation pane on the left, click Identity Management > Roles.

    2. Find OOSServiceRole and click Add Permissions in the Actions column.

      Grant the required permissions to the OOSServiceRole RAM role.

    3. On the Grant Permission page, specify the resource scope and policy, and then click OK.

      The following table describes the settings that are used in this example. Any parameters not covered in the following table default to their predefined settings.

      Parameter

      Description

      Authorized scope

      Select Account.

      Policy

      Select the following custom policy: ESSHookPolicyForMongoDBWhitelist.

Step 2: Create a lifecycle hook for scale-out purposes and trigger a scale-out event

  1. Log on to the Auto Scaling console.

  2. In the navigation pane on the left, click Scaling Groups.

  3. In the top navigation bar, select a region.

  4. Find the scaling group that you want to manage and open its details page in one of the following ways:

    • In the Scaling Group Name/ID column, click the ID of the scaling group.

    • In the Actions column, click Details.

  5. Create a lifecycle hook.

    1. At the top of the page, click the Event and adhesive hook tab.

    2. Click Create Lifecycle Hook.

    3. Configure the lifecycle hook and click OK.

      The following table describes the settings that are used in this example. Any parameters not covered in the following table default to their predefined settings.

      Parameter

      Description

      Name

      Enter ESSHookForAddMongoDBWhitelist.

      Scaling Activity Type

      Select Scale-Out.

      Timeout Period

      Configure Timeout Period based on your business requirements. In this example, set the value to 300. Unit: seconds.

      Note

      The timeout period is the period of time during which you can perform custom operations on instances. If the timeout period is shorter than the period of time that is required to perform custom operations, the operations may fail. We recommend that you estimate the period of time that is required to perform custom operations on instances and configure Timeout Period based on your estimates.

      Default Execution Policy

      Select Continue.

      Send Notification When Lifecycle Hook Takes Effect

      Configure the following parameters for the template:

      • Notification Method: Select OOS Template.

      • OOS Template Type: Select Public Templates.

      • Select LifeCycleModifyMongoDBIPWhitelist.

      In the ACS-ESS-LifeCycleModifyMongoDBIPWhitelist public template, you must also configure the following parameters:

      • MongoDB instance ID: Enter the ID of your ApsaraDB for MongoDB instance. This tutorial uses a replica set instance as an example.

      • Whitelist modification method: Select Append. This corresponds to a scale-out event and adds the ECS instance to the IP address whitelist of the ApsaraDB for MongoDB instance.

      • The RAM role assumed by OOS. : Select OOSServiceRole. In the Procedure section, you granted the OOSServiceRole RAM role the required permissions to manage ECS, Auto Scaling, and ApsaraDB for MongoDB resources. OOS can assume this RAM role to obtain the required permissions.

  6. Trigger a scale-out event.

    In this example, a scale-out event is manually triggered by executing a scaling rule. You can also trigger scale-out events by using scheduled or event-triggered tasks.

    Note

    If scaling events are triggered when you manually execute scaling rules, lifecycle hooks take effect. However, lifecycle hooks do not take effect when you manually add or remove ECS instances to or from a scaling group.

    1. At the top of the page, click the Scaling Rules and Event-triggered Tasks tab.

    2. On the Scaling Rules tab, click Create Scaling Rule.

    3. Set the properties of the scaling rule and click OK.

      The following table describes the settings that are used in this example. Any parameters not covered in the following table default to their predefined settings.

      Parameter

      Description

      Rule Name

      Enter Add1.

      Rule Type

      Select Simple Scaling Rule.

      Operation

      Set the value to Add 1 Instances.

    4. In the list of scaling rules, find the newly created Add1 rule and click Recurrently in the Actions column.

    5. Click OK.

    After the scaling rule is executed, Auto Scaling adds one ECS instance to the scaling group. However, the ECS instance enters the Pending Add state because of the ESSHookForAddMongoDBWhitelist lifecycle hook that is in effect. During the timeout period of the lifecycle hook, Auto Scaling notifies OOS to execute the O&M tasks that are defined in the ACS-ESS-LifeCycleModifyMongoDBIPWhitelist public template.

Step 3: Check the IP address whitelist of the MongoDB instance

  1. Log on to the MongoDB console.

  2. In the navigation pane on the left, click Replica Set Instances.

  3. Find the ApsaraDB for MongoDB instance and click its ID in the Instance ID/Name column.

  4. In the navigation pane on the left, choose Data Security > Whitelist Settings.

    • If the private IP address of the ECS instance is added to the IP address whitelist of the MongoDB instance, the ACS-ESS-LifeCycleModifyMongoDBIPWhitelist public template takes effect as expected.

    • If the ECS instance is created but its private IP address is not added to the IP address whitelist of the MongoDB instance, go to the OOS console to view the execution of the O&M tasks. For more information, see (Optional) Step 4: View the OOS execution.

(Optional) Step 4: View the OOS execution

  1. Log on to the OOS console.

  2. In the navigation pane on the left, choose Automated Tasks > Task Execution Management.

  3. Find the execution based on the start time and click Details in the Actions column.

  4. On the execution details page that appears, view the related information.

    For example, you can view the execution ID and status in the Basic Information section. You can also click a task node in the Execution Steps and Results section to view its details. For more information, see View execution details.

    Note

    If the execution fails, an error message is displayed on the execution details page.

FAQ

If an Operation and Maintenance (O&M) task fails, find the cause based on the error message in the execution result. For more information, see FAQ.

Common error messages are as follows:

Error message

Cause

Solution

Forbidden.Unauthorized message: A required authorization for the specified action is not supplied.

Auto Scaling is not authorized to perform the specified action.

Verify that the required permissions are granted to the OOSServiceRole RAM role.

Forbidden.RAM message: User not authorized to operate on the specified resource, or this API doesn't support RAM.

The RAM user or RAM role does not have the permissions to operate on the corresponding resource.

Verify that the OOSServiceRole RAM role has the required permissions. For example, you can grant the sample permissions for the OOS service to the RAM role. You must add operation permissions to the RAM role to ensure that the OOS service can manage the resources specified in the OOS template.

LifecycleHookIdAndLifecycleActionToken.Invalid message: The specified lifecycleActionToken and lifecycleActionId you provided does not match any in process lifecycle action.

The ongoing lifecycle action has expired or has been aborted.

Evaluate the timeout period of the lifecycle hook to ensure that the O&M tasks defined in the OOS template can be completed within the timeout period.