Cloud cost optimization for dev and staging environments means matching cloud spending to the work your team actually does. Start by identifying idle virtual machines (VMs) and reducing unused runtime with auto-shutdown. Then review oversized machines and leftover resources.
A VM needed for 50 hours a week can spend the other 118 hours stopped, if its workload allows it. This guide focuses on standalone AWS and Google Cloud VMs.
Why do dev and staging costs grow?
Non-production environments often outlive the work that created them. A demo ends, a branch is merged, or a developer changes projects, but the VM keeps running. Machines copied from production may also have more capacity than development needs.
Development machines often support individual work sessions. Staging may support overnight tests, integrations, or customer demos. Those differences matter: decide availability for each environment before setting a shutdown policy.
How do you reduce dev and staging costs?
Use these five steps to find savings and check that the changes work.
- Give every resource an owner. List VMs by environment, project, and responsible person. Record VM costs alongside attached disks, databases, and networking. An environment label helps identify candidates; its owner confirms what can change.
- Find safe off-hours shutdown windows. Compare usage with development sessions, test schedules, and dependencies. Low CPU alone does not prove that a VM is safe to stop. A quiet machine may still receive webhooks or support another team's tests.
- Rightsize the machines you keep. Rightsizing means matching VM capacity to workload needs. Review CPU, memory, disk activity, and network traffic during representative work. AWS rightsizing recommendations use several utilization metrics, including memory when available. Test a smaller machine with a realistic workload.
- Review leftover resources. Check unattached disks, old snapshots, unused addresses, and abandoned databases. Confirm ownership, dependencies, and retention requirements before deletion. Keep backups that serve a purpose; remove resources only after their owner confirms they are unnecessary.
- Measure the result. Compare actual spend over similar periods, allowing for workload changes. Track startup delays, interrupted jobs, and developer complaints alongside savings. Lower infrastructure costs should still leave the team able to work effectively.
How much can auto-shutdown save on idle VMs?
Consider one VM at an illustrative compute rate of $0.20 per hour:
That is about 70% less runtime and modeled compute cost.
Annualized over 52 weeks, that is approximately $102 per month or $1,227 per year per VM. For 10 VMs, modeled annual savings reach about $12,270. Monthly savings are the annual estimate divided by 12.
The example assumes the same VM and rate, no spending commitments, and no extra runtime. It excludes storage, networking, licenses, and automation fees. The rate is an example, not a provider quote. Total cloud savings will differ.
Should you use a start/stop schedule or on-demand access?
Use a fixed start/stop schedule for predictable working hours and off-hours shutdown. For irregular sessions, let engineers start VMs on demand with a time-limited lease.
For AWS, Instance Scheduler on AWS is a deployable solution that automates starts and stops. Google Cloud instance schedules use resource policies attached to VMs. Both support scheduled operation.
Idlefy, a cloud cost automation tool for AWS and GCP, keeps selected VMs stopped by default. Engineers request runtime through the web or, on paid plans, Slack and Telegram. Auto-shutdown follows lease expiry, with a conditional 30-minute grace period on Pro.
How do you avoid interrupting work?
Pilot shutdown automation on one low-risk VM. Ask its owner to confirm overnight jobs, shared dependencies, and required availability.
Check that persistent storage holds everything needed after restart. Test the full application startup, including database connections and background services. Measure how long the environment takes to become usable.
Provide advance warnings, a clear way to extend runtime, and a documented exception process. Include time for startup before scheduled tests. Review the pilot with the engineers who use the machine before expanding it.
Frequently asked questions
Do stopped VMs still cost money?
Yes. Retained disks and some other resources continue to incur charges on AWS and Google Cloud. Existing spending commitments can also limit the reduction in your bill.
Does stopping a VM delete its data?
On EBS-backed EC2 instances, stopping preserves EBS volumes but erases RAM and instance-store data. Persistent storage differs from temporary storage; check your VM's configuration before automating shutdown.
Should staging run 24/7?
Keep staging continuously available when tests, integrations, demos, or team access require it. Otherwise, agree on availability windows and check which components can safely stop.
Where should you start?
Audit a small group of dev and staging VMs with known owners. Identify unused runtime, then validate which hours can safely disappear.
Find your starting point with a free Idle Audit.
Idlefy's read-only audit uses 30 days of usage data and on-demand rates. Its estimates exclude discounts and spending commitments, so actual savings may be lower. The audit does not start, stop, or change resources.
Top comments (0)