Function Compute:Instance scaling limits and elastic policies

On-demand instance scaling

When scaling speed or instance count exceeds the regional limit, Function Compute returns HTTP 429 to indicate throttling. The following figure shows the three phases during a traffic surge.

• Phase 1 — Instances spin up immediately to absorb the surge. Cold starts occur, but no throttling — the burstable limit has not been reached yet.

• Phase 2 — The burstable limit is reached. New instances are now constrained by the growth rate. Some requests are throttled.

• Phase 3 — The total instance count hits the regional ceiling. Throttling continues for requests that cannot be served.

Provisioned instance scaling

Provisioned instances are pre-initialized and held in reserve before any invocation arrives. This eliminates cold starts for the reserved capacity and reduces the likelihood of throttling during traffic surges.

The following figure shows the same surge scenario with provisioned instances in place.

• Phase 1 — All incoming requests are routed to provisioned instances. No cold starts, no throttling — until provisioned capacity is full.

• Phase 2 — Provisioned instances are saturated. Function Compute starts creating on-demand instances to handle the overflow. Cold starts occur, but throttling is still avoided until the burstable limit is reached.

Scheduled scaling

Use scheduled scaling when traffic follows a predictable pattern — for example, peak hours during business hours or traffic spikes tied to specific events. When concurrent invocations exceed the scheduled capacity, the overflow is routed to on-demand instances.

"scheduledActions": [
    {
      "name": "scale_up_action",
      "startTime": "2024-08-01T10:00:00",
      "endTime": "2024-08-30T10:00:00",
      "target": 50,
      "scheduleExpression": "cron(0 0 20 * * *)",
      "timeZone": "Asia/Shanghai"
    },
    {
      "name": "scale_down_action",
      "startTime": "2024-08-01T10:00:00",
      "endTime": "2024-08-30T10:00:00",
      "target": 10,
      "scheduleExpression": "cron(0 0 22 * * *)",
      "timeZone": "Asia/Shanghai"
    }
  ]

Threshold-based scaling

Use threshold-based scaling when traffic is harder to predict. Function Compute periodically collects concurrency or resource utilization metrics from provisioned instances and adjusts the instance count to stay within the minCapacity–maxCapacity range you define.

Threshold-based scaling requires instance-level metrics collection to be enabled first. Without it, you will get a 400 InstanceMetricsRequired error. See Enable collection of instance-level metrics.

The ProvisionedConcurrencyUtilization metric tracks only provisioned instances — on-demand instance concurrency is excluded.

Concurrency utilization is the ratio of the number of concurrent requests currently handled by the Minimum Instances to the maximum number of concurrent requests that the Minimum Instances can support. The value ranges from 0 to 1.

"targetTrackingPolicies": [
    {
      "name": "action_1",
      "startTime": "2024-08-01T10:00:00",
      "endTime": "2024-08-30T10:00:00",
      "metricType": "ProvisionedConcurrencyUtilization",
      "metricTarget": 0.6,
      "minCapacity": 10,
      "maxCapacity": 100,
      "timeZone": "Asia/Shanghai"
    }
  ]

How is the current minimum number of instances calculated?

The following example shows how the current minimum number of instances is determined jointly by the initially configured minimum number of instances and the target values set in scheduled scaling policies.

Configuration:

• defaultTarget: 5

• Two scheduled policies, time zone Asia/Shanghai (UTC+8), active from January 9 to January 11, 2025

  • Scale out to 20 at 10:00 each day

  • Scale in to 10 at 22:00 each day

{
    "defaultTarget": 5,
    "scheduledActions": [
        {
            "name": "scale_up_action",
            "startTime": "2025-01-09T10:00:00",
            "endTime": "2025-01-11T00:00:00",
            "target": 20,
            "scheduleExpression": "cron(0 0 10 * * *)",
            "timeZone": "Asia/Shanghai"
        },
        {
            "name": "scale_down_action",
            "startTime": "2025-01-09T10:00:00",
            "endTime": "2025-01-11T00:00:00",
            "target": 10,
            "scheduleExpression": "cron(0 0 22 * * *)",
            "timeZone": "Asia/Shanghai"
        }
    ]
}

The following figure shows how the provisioned instance count changes over time under this configuration.