Dev and test environment costs: turn off what sits idle
Short answer: a server used for about 50 hours a week runs for 168 hours if nobody turns it off. For test and development systems, most of the bill pays for idle time. Schedules, auto-shutdown and temporary environments cut that without slowing the team.
Key points
- A working week is about 50 hours. A calendar week is 168.
- Stopping compute does not stop disks, addresses or load balancers.
- Temporary environments defined as code can be deleted completely.
- Tags with an owner and expiry date prevent forgotten machines.
- Test machines rarely need production size.
What is the arithmetic?
A week has 168 hours. A team working ten hours a day, five days a week, uses 50 of them. Shutting a machine down outside those hours stops compute charges for about two thirds of the week. The exact saving depends on your hours and on which charges continue.
What stops billing and what does not?
| Resource | When stopped |
|---|---|
| Virtual machine compute | Hourly charge stops (check the vendor’s wording for stopped versus deallocated) |
| Disks | Still billed |
| Public IP addresses | Often still billed |
| Load balancers | Still billed by the hour |
| Managed databases | Some can be stopped for a limited time, others cannot |
A stopped system still carries a smaller bill. Delete what you can rebuild. See hidden cloud costs.
What does a worked example look like?
Made-up round numbers to show the method, not real prices. Five test servers at 0.20 per hour, with 100 GB disks at 0.10 per GB-month, a load balancer at 0.03 per hour.
| Line | Always on (730 h) | Weekday office hours only (about 220 h) |
|---|---|---|
| Servers | 5 x 730 x 0.20 = 730.00 | 5 x 220 x 0.20 = 220.00 |
| Disks | 5 x 100 x 0.10 = 50.00 | 50.00 |
| Load balancer | 730 x 0.03 = 21.90 | 21.90 |
| Total | 801.90 | 291.90 |
The saving is 510, or 64 percent. Deleting the load balancer and recreating it with the environment would save another 21.90. The disks stay unless you snapshot and delete them. Servers are the part that moves; the rest is small but permanent.
How do I do it?
- Schedules. Start at morning, stop at evening, with a tag that marks which machines are covered. Each cloud has a scheduler for this.
- Auto-shutdown on idle. Stop machines with no activity for a set time.
- Temporary environments. Create a full environment for each branch or test run, and delete it when finished. Define it as code so it is repeatable.
- Smaller sizes. Test systems rarely need production size. See choosing a VM size.
- Cheaper capacity for batch work. Test runs that can restart fit spot instances.
How do I make it stick?
Tag every environment with an owner and an expiry date. See tags and labels. Set a budget with an alert for the non-production account. See budgets and cost alerts. Review idle resources monthly with the optimization checklist.
Which mistakes are common?
- Scheduling the servers but leaving the database on.
- Shutting down the environment during a nightly test run.
- Keeping production-size databases in staging.
- No owner tag, so nobody dares delete anything.
Decision checklist
- Does every non-production resource have an owner and expiry?
- Is there a schedule for compute outside office hours?
- Can the environment be rebuilt from code?
- Is there an alert on the non-production account?
Next steps
Use the web app estimator to price a full environment, then multiply by the hours you actually need. Windows VM costs matter here too, since licences bill by the hour.
Frequently asked questions
How much can I save by shutting down dev environments at night?
A team working ten hours a day, five days a week uses about 50 of the 168 hours in a week. Stopping compute outside those hours removes charges for about two thirds of the week, though disks and addresses keep billing.
Do stopped virtual machines still cost money?
The compute charge usually stops, but disks, snapshots, public IP addresses and load balancers keep billing. Check the vendor wording for stopped versus deallocated.
What is an ephemeral environment?
A full environment created for a branch or a test run and deleted when it finishes, defined as code so it is repeatable.
Can managed databases be stopped?
Some can be stopped for a limited time and others cannot. Check each service. For those that cannot, use a smaller size in non-production.
How do I stop people forgetting test machines?
Tag every environment with an owner and an expiry date, schedule automatic shutdown, and set a budget alert on the non-production account.