How to Optimize Cloud Resource Scheduling After Migration

Background

With enterprise digitalization and full cloud adoption, cloud cluster management and scheduling support all cloud workloads. Engineers should understand cloud scheduling as they once understood operating systems.

Why Manage Resources After Migration?

Enterprises need to assess resource scale, cost pressure, and staffing before deciding to develop their own scheduler. For small scales (less than about 1,000 ECS instances) existing services such as ROS, OOS, or Auto Scaling are sufficient; larger scales may require custom resource orchestration.

Key Cloud Services

ICR (Immediately Capacity Reservation) : Purchase capacity that becomes effective immediately, locking resources in a private pool and charging at pay‑as‑you‑go rates.

ROS (Resource Orchestration Service) : Use JSON/YAML templates to describe multiple cloud resources (ECS, RDS, SLB) and automatically deploy them across regions and accounts, enabling Infrastructure as Code.

OOS (Operation Orchestration Service) : Provides automated operation tasks such as event‑driven, batch, scheduled, and cross‑region operations, with approval and notification features.

Auto Scaling : Dynamically adjusts the number of ECS instances based on business policies, scaling out during demand spikes and scaling in to save costs.

DDH (Dedicated Host) : Offers exclusive physical resources for enterprises, allowing flexible deployment of ECS instances, VPC connectivity, and high performance.

Feasibility of Cloud‑Based Scheduling

A simple on‑premise scheduler consists of a resource request API, a central scheduler, a database, and physical node agents. After migration, these modules can still operate but must adapt to cloud‑provided OpenAPI data, additional dimensions such as region, zone, VPC, and security groups, and command interfaces that use cloud APIs.

Practical Cloud Scheduling Solutions

1. ECS‑Based Scheduling

Resources are represented by ECS instances; the scheduler allocates containers on these instances. Advantages include fine‑grained control over instance types, regions, and workload placement, and the ability to use container services like ACK. Disadvantages are the need to pre‑purchase instances and limited to capacity‑only operations.

Suitable for large enterprises with containerized workloads and dedicated scheduling teams seeking cost optimization.

2. Dedicated Host (DDH)‑Based Scheduling

DDH instances replace physical nodes, and operations use OpenAPI. Advantages are exclusive physical resources, high security, better performance, and support for high‑density container deployment. Disadvantages include higher per‑instance cost and potential lower deployment density.

Suitable for workloads with strict security, licensing, or performance requirements and large‑scale resource demands.

3. Private Pool‑Based Scheduling

Uses capacity reservation pools as the resource source. Advantages are fine‑grained capacity control, competitive pricing, and guaranteed 100% delivery of reserved capacity. Disadvantages are the need for real‑time capacity planning and slight provisioning latency.

Suitable for enterprises with strong cost‑flexibility demands and mature technical capabilities for rapid scaling.

Summary

After moving to the cloud, enterprises can still perform fine‑grained resource scheduling. Based on their situation, they should choose a suitable management mode; we recommend capacity‑reservation‑based scheduling for its precise control, 100% resource delivery, and long‑term discount benefits.