Cloud Scheduling Best Practices for Start/Stop Automation
Cloud scheduling means starting and stopping resources at fixed times so they only run, and only bill, when someone needs them. These are the practices that keep a schedule saving money without breaking anyone's day.
Cloud scheduling (also called resource scheduling or instance scheduling) is the automated start, stop, or scale-down of cloud resources on a timetable. A development VM that runs 10 hours a day on weekdays is on for 50 of the 168 hours in a week. Over a 730-hour month that is roughly 217 running hours instead of 730, because a month holds about 4.35 weeks. The arithmetic is simple; the practices below are what make the schedule survive contact with real teams.
1. Choose the window from usage, not from a guess
A schedule is a claim about when a resource is idle. Base it on observed activity (CPU, connections, requests) over several weeks, including at least one full weekend. A single week can mislead you if it contained a release crunch or a holiday.
ZopNight’s schedule recommendations follow this rule: they are generated only from the latest 21 days of metrics and require history reaching back at least 18 days, at least 7 distinct observed days and no interior data gap longer than 3 days, so a resource needs a full three-week picture before a schedule is proposed. When a saving cannot be verified, the recommendation stays visible as an advisory without a dollar figure.
2. Write schedules in the team’s time zone
Define start and stop times in the IANA time zone of the people who use the resource, for example America/New_York or Asia/Kolkata, not in UTC. A UTC schedule silently shifts by an hour for a team whose region observes daylight saving time.
Daylight saving transitions still need a decision. AWS documents how EventBridge Scheduler handles them: when clocks move forward, an invocation that falls on a non-existent local time is skipped; when clocks move back, the schedule runs once rather than twice. Avoid placing a start or stop inside your region’s transition hour, or check how your scheduler treats it. For teams spread across regions, schedule to the union of working hours; even a near-24-hour weekday window still recovers the weekend.
3. Schedule the group, not the member, when autoscaling is involved
If an instance belongs to an EC2 Auto Scaling group, stopping the instance directly does not work: Amazon EC2 Auto Scaling treats an instance in the stopping or stopped state as unhealthy and replaces it to maintain desired capacity. Scale the group’s capacity instead. The same logic applies to Kubernetes, where you scale node pools or workloads rather than individual nodes. ZopNight’s start/stop coverage includes ASG capacity scaling and EKS node pool scaling alongside plain VM stop/start.
4. Know what keeps billing after the stop
Stopping ends the compute charge, not every charge. On EC2, attached EBS volumes and Elastic IP addresses keep billing, and data on instance store volumes is lost at stop. An Azure VM stops billing for compute only when it is Stopped (deallocated); a VM shut down from inside the guest OS stays allocated and billed. Services billed by storage and requests, such as Amazon S3 and DynamoDB, have no running hours to remove. The non-production environment costs guide walks through these per provider.
5. Treat overrides as a normal part of the design
People will need a resource outside its window: an incident, a late deploy, a demo in another time zone. Make the exception self-service, time-boxed and explained. In ZopNight an override forces a resource or group ON or OFF, carries a reason, takes effect as soon as it is set, and expires automatically at the end time you choose (there is no maximum duration, so keep windows short); only one active override is allowed per resource or group.
6. Bundle environments and sequence them
Attach whole environments rather than individual machines, so a “staging” group follows one cadence. See resource groups for grouping rules and start and stop ordering for how to space starts so a database is up before the services that call it.
7. Review coverage and history
Track which eligible resources have no schedule, and read the state history when something looks wrong. ZopNight records every start and stop with what triggered it (a named schedule, a user, or an override), and read-only accounts can still have schedules attached, although starting and stopping requires a read + write connection. Syntax details live in the cron scheduling guide.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
How is scheduling different from autoscaling?
Autoscaling changes capacity in response to live metrics such as CPU or request count. A schedule changes state at fixed times. They complement each other: autoscaling handles variation during working hours, and a schedule takes capacity to zero or to a floor when nobody is using the environment. When both act on the same group, schedule the group's capacity so the two do not fight.
Does a 10-hour weekday schedule really cut running hours by about 70 percent?
In running hours, yes: 50 of 168 weekly hours is about 217 of 730 monthly hours. The bill drops by less than that, because storage, static IP addresses and other always-on charges continue while the compute is stopped.