Skip to main content

CloudStack AutoScale — practical considerations

CloudStack supports horizontal auto-scaling: instead of increasing CPU/RAM on an existing VM (vertical scale), it provisions additional VM instances when defined thresholds are met (CPU, network traffic, custom metrics, and similar).

Auto-scaling is not only an infrastructure feature. The application must be designed to support horizontal scaling.

Official reference: AutoScale with Virtual Router.

What CloudStack AutoScale does​

DoesDoes not
Launch new VMs from a predefined template when scale-up policies fireMake a non-scalable app suddenly work across multiple VMs
Attach new VMs to a load balancer ruleSynchronize local sessions, local files, or local databases for you
Remove excess VMs when scale-down policies fireReplace the need for shared DB, cache, and shared storage
Important limitation

CloudStack AutoScale only provisions and removes VMs. It does not automatically make an application horizontally scalable.

Application architecture, shared services, startup automation, and data synchronization must already be designed and tested before enabling auto-scaling.

Key requirements​

1. Application architecture​

The application should:

  • Run on multiple VMs at the same time
  • Receive user traffic through a load balancer
  • Use shared or synchronized databases, caches, file storage, and session data across instances
Local state breaks scaling

Applications that store sessions or data only on a single VM’s local disk may fail or lose user state when AutoScale adds or removes instances.

2. Golden VM template​

  1. Create and configure a VM with all required software, application code, agents, and startup scripts
  2. Verify the application starts automatically and joins the existing environment without manual intervention
  3. Create a template from this VM — power off the VM, then use Create from VM root volume in CMP (or create from snapshot where that flow is used)

That template becomes the image CloudStack uses for every scale-up instance.

3. AutoScale deployment (CloudStack model)​

Typical building blocks:

Building blockRole
Load balancer ruleDistributes traffic; new VMs are added to / removed from this rule
AutoScale policies and conditionsScale-up / scale-down triggers (counters, thresholds, duration)
AutoScale VM profileService offering + template (+ related deploy params) used when launching VMs
AutoScale VM groupTies min/max members, profile, and policies to the LB rule

When a scale-up policy is triggered, CloudStack launches new VMs from the template and adds them behind the load balancer. When load decreases, scale-down policies can remove excess instances.

Practical example — e-commerce sale​

Suppose an e-commerce application normally runs on 2 web servers behind a load balancer.

  1. During a sale, CPU utilization exceeds 80% for 10 minutes
  2. CloudStack AutoScale creates 2 additional web servers from the predefined template
  3. The load balancer sends traffic to all 4 servers
  4. Because all servers use the same database and Redis cache, users experience seamless scaling
  5. After traffic returns to normal, CloudStack removes the extra instances according to the scale-down policy
Prepare horizontally scalable app
        │
        ▼
Golden VM → Template
        │
        ▼
Load Balancer + AutoScale policies + VM profile
        │
        ▼
Scale-up → new VMs from template → join LB
Scale-down → remove excess VMs

Checklist before enabling AutoScale​

  • Application runs correctly on more than one VM behind a load balancer
  • Sessions / uploads / caches use shared services (not VM-local only)
  • Golden image boots and serves traffic without login or manual steps
  • Template is tested (launch a VM from it and verify)
  • Load balancer and AutoScale policies are configured and validated in a non-production window first