Schedules and auto-scaling are the two ways to make billed compute capacity follow demand instead of the peak: a schedule stops instances at fixed times when nobody needs them and starts them again; auto-scaling adds instances to a group of identical ones and removes them as load changes, driven by a metric, a schedule or a prediction. Both lower usage, not the price per hour. What they actually save depends on what keeps billing while stopped, how high the minimum size sits, and whether a commitment pays for the switched-off hours anyway.
How it works
Which mechanism fits follows from the shape of the load and from whether the instance carries state of its own:
| Situation | Mechanism | Why |
|---|---|---|
| Single VMs with state, used only in working hours (development, test, internal tools) | Schedule: stop and start | Disks and configuration persist, the compute hours go |
| Stateless service behind a load balancer, load varies through the day | Metric-based auto-scaling | The number of instances follows measured load |
| Recurring daily or weekly peaks, long start-up | Scheduled or predictive scaling | Capacity is ready before the load arrives |
Schedules
AWS offers Instance Scheduler on AWS, a solution deployed with CloudFormation into your own account: it stops and starts EC2 and RDS instances by tag through Lambda, across several accounts and Regions too. The customer pays for the AWS services it runs on; in AWS's cost examples these are mainly Lambda, CloudWatch, KMS and DynamoDB. Microsoft offers auto-shutdown for single VMs, a daily shutdown time with optional notice by email or webhook. Start/Stop VMs v2 starts and stops VMs across subscriptions on schedules and is billed by the services it deploys; Microsoft now files its documentation under previous versions and has announced no further development beyond keeping its components on supported versions. Google Cloud has instance schedules: they apply only to VMs in the same region, each VM follows at most one schedule, VMs with Local SSD cannot be stopped this way, and an operation can start up to 15 minutes after the scheduled time.
Stopped does not mean free. For a stopped EC2 instance AWS charges no usage, but it does charge for the EBS volumes and associated Elastic IP addresses, and every start bills at least one minute. Azure stops billing the VM only once it is deallocated, shown as "Stopped (deallocated)"; in "Stopped", for example after a shutdown from inside the guest OS, billing continues, and disks and networking keep costing money even when deallocated. Google Cloud bills CPU in the RUNNING and PENDING_STOP states, memory also in SUSPENDING and SUSPENDED (once suspended, at a rate for storing the preserved state), and disks and external IP addresses for as long as they exist. The full list per service is in the article non-production cloud costs.
Auto-scaling
Three settings decide how closely the bill follows the load: the minimum size, which runs around the clock; the metric that triggers scaling; and the wait after a scaling action, which holds capacity beyond the peak.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Group | Auto Scaling group with minimum, maximum and desired capacity | Virtual Machine Scale Set with an autoscale setting, minimum, maximum and default per profile, up to 20 profiles | managed instance group with an autoscaler, minimum and maximum |
| Wait | cooldown of 300 seconds by default, binding for simple policies; target tracking and step scaling use a warm-up per instance | cooldown per rule | initialization period of 60 seconds by default; stabilization period of 10 minutes before scaling in |
| Schedule | scheduled actions, recurring, with a time zone | time-based profiles with recurrence | up to 128 scaling schedules per group |
| Prediction | from 24 hours of history, analyses up to 14 days, forecasts 48 hours, scale-out only | from 7 days of history, CPU only, scale-out only | from history, for daily or weekly cycles |
AWS charges no fee for EC2 Auto Scaling itself; you pay for the instances, volumes and CloudWatch alarms. Instances in a warm pool in the Stopped state cost only their volumes and Elastic IP addresses; AWS warns that a warm pool nobody needs creates unnecessary cost. Google deletes VMs only once the remaining capacity can carry the peak of the stabilization period, and scale-in controls limit the reduction further.
What it means for your cost
A schedule changes the number of hours: billing data shows the same instance with fewer hours, while disks and addresses run on unchanged. Auto-scaling turns a fixed size into a floor: the minimum costs every hour, everything above it follows the load, delayed by the wait. A high minimum or a long stabilization period is a deliberate choice for availability, and its price can be read as hours above demand.
Commitments are counted by the hour. A Savings Plans commitment applies only within its hour, an Azure reservation loses every hour without a matching resource, and committed use discounts are paid regardless of usage. A schedule that switches off reserved instances therefore lowers utilisation, not the bill, as long as the discount finds no other matching usage. The split follows: the commitment covers the minimum size and the hours that always run; whatever scales or is switched off on a schedule stays on demand or runs on spot capacity. On AWS one Auto Scaling group can combine On-Demand and Spot Instances, and Reserved Instances or Savings Plans discount its On-Demand part. How the portfolio is matched to it is covered in commitment strategy.
Where it goes wrong
- Stopped, not deallocated. Symptom: an Azure VM is off but still bills compute hours. Cause: it was shut down from inside the guest OS and sits in "Stopped" rather than "Stopped (deallocated)".
- A schedule on reserved instances. Symptom: compute hours fall, the bill does not. Cause: the commitment is charged by the hour, and the freed hours find no other matching usage.
- A stopped instance in an Auto Scaling group. Symptom: after the scheduled stop a new instance is running. Cause: EC2 Auto Scaling treats any instance outside
runningas unhealthy and replaces it. - Minimum equals peak. Symptom: auto-scaling is set up, yet instance hours stay flat. Cause: minimum and maximum sit close together, or the minimum was chosen for the peak.
- Scale-in never happens. Symptom: after a peak the group stays large for a long time. Cause: cooldown, stabilization period or scale-in controls hold the capacity, or the metric does not fall below its target.
- A late start. Symptom: services are unreachable early on Monday. Cause: Google instance schedules can start up to 15 minutes late; Google advises scheduling 15 minutes earlier.
Example
An instance with hourly price P runs H hours a week instead of 168; S is the weekly cost of its volumes and addresses. Without a commitment the weekly cost falls from P × 168 + S to P × H + S, a saving of P × (168 − H). In its description of Instance Scheduler, AWS works with H = 50 and states savings of up to 70% for instances needed only during business hours; 50 of 168 hours is about 30% of the running time. If a reservation at hourly rate R covers the instance, the week costs R × 168 + S whether the instance runs or not: the saving is zero until the discount finds other usage. The running cost of the scheduler itself comes off the saving.
Sources
Read on 2026-10-16. AWS Instance Scheduler on AWS overview and cost, stop and start Amazon EC2 instances, how EC2 instance stop and start works, what is Amazon EC2 Auto Scaling?, health checks for Auto Scaling instances, Auto Scaling groups with multiple instance types and purchase options, scaling cooldowns, scheduled scaling, how predictive scaling works, warm pools and how Savings Plans apply to your usage; Microsoft states and billing status of Azure virtual machines, auto-shutdown a virtual machine, az vm auto-shutdown in the Azure CLI reference, Start/Stop VMs v2 overview, autoscale in Azure Monitor, understand autoscale settings, predictive autoscale and how a reservation discount is applied; Google Cloud instance schedules, compute instance lifecycle, suspend, stop or reset compute instances, autoscaling groups of instances and committed use discounts.