Cost Control
Part of Cloud resource optimisation
Scheduling non-production resources around use
Set operating windows for development and test resources, check provider stop behaviour and observe a full start-stop cycle.
Schedule a non-production resource when its users and jobs have a dependable use window and it can be ready again before work starts. Agree the window with its owner, check dependencies and startup time, then choose supported start and stop actions.
Set the operating window
Review development, test, training and demonstration environments separately. Record users and their time zones, scheduled jobs, maintenance, integrations and the time each environment must be usable.
Check access and job history, then ask owners about infrequent work that those records may miss. Australian teams may also serve people in other time zones.
Allow time for boot, service checks and application warm-up. Set the stop time after the final approved job, with an owner-controlled extension and an expiry for each exception.
Shared services may need a different window from the VMs that depend on them.
Key considerations before scheduling
- Time zone alignment
- Australian teams may serve users across multiple time zones.
- Startup delay allowance
- Allow buffer time for boot, service checks and app warm-up.
- Exception handling
- Include owner-controlled extensions and expiry dates for exceptions.
- Shared service timing
- Shared services may require different operating windows than dependent VMs.
Choose the action and tool
Stopping compute does not necessarily remove every charge. On AWS, EC2 instance-usage billing ends when an ordinary stop reaches its stopping state, while retained EBS volumes can still cost money.
Azure distinguishes stopped but allocated VMs, which remain billed for compute, from deallocated VMs, which do not; disks and networking may remain charged.
| Platform example | Supported scheduling route | Check before relying on it |
|---|---|---|
| AWS Instance Scheduler | Configured periods and matching tags for supported instances | Tag match, permissions, EC2 shutdown behaviour and database stop limits |
| Azure VM auto-shutdown | A configured VM shutdown time | Billing state and the required start process |
| Google Compute Engine instance schedule | Start and stop operations for eligible VMs | Zone capacity for restart and applicable restart limitations |
Google notes that restarting an instance requires sufficient resources in its zone; TPU instances cannot be restarted.
AWS warns that a mismatched schedule tag can leave an instance running. The AWS Instance Scheduler also assumes EC2 shutdown behaviour is set to Stop; check this before assigning a schedule.
A configured Azure shutdown time alone does not prove the morning start will work.
Platform-specific VM shutdown and billing behaviour
- AWS EC2Stop: Billing ends when in 'stopped' state. EBS volumes continue to incur charges.
- Azure VMStopped but allocated: billed for compute. Deallocated: no compute charge. Disks and networking may still incur costs.
- Google Cloud Compute EngineStart/stop scheduled only for eligible VMs. Restart requires zone capacity; TPU instances cannot be restarted.
Observe a full cycle
Record the affected resource IDs, local time zone, expected states, operator, alert route and manual override. Arrange a first cycle when an owner can check job completion, the resulting billing state, service readiness and a representative user action.
After a comparable period, compare removed compute hours with remaining resource and scheduler charges. If extensions are frequent or startup is unreliable, revise the window or leave the resource running until the use pattern supports a schedule.
