Non-Production Environment Costs: What Bills and What Stops
Development, QA, staging and sandbox environments are paid for by the hour whether anyone is using them or not. Stopping them helps, but only some charges actually stop.
Non-production environments are the cloud resources used to build and test software rather than to serve customers: development, QA, staging, sandbox, demo and per-feature preview environments. They are not optional, but their usage pattern is: people use them during working hours, while the resources behind them are billed for every hour they run. The gap between those two numbers is the cost this page is about.
The hours arithmetic
A month averages about 730 hours. An environment that is genuinely needed 10 hours a day, five days a week, is needed for 50 of the 168 hours in each week, which is roughly 217 hours a month. Everything between 217 and 730 is time the environment runs with nobody using it. Note the unit carefully: 50 is a weekly figure and 730 a monthly one, so comparing them directly overstates the gap.
What stops billing, and what does not
Stopping ends the compute charge. It does not end every charge, and the rules differ by provider:
| Resource | While stopped | Still billed |
|---|---|---|
| Amazon EC2 instance | No usage or data transfer charges for the instance | EBS volumes; public IPv4 addresses, including Elastic IPs |
| Amazon RDS DB instance | No DB instance hours | Provisioned storage (including Provisioned IOPS), backup storage, a public IPv4 address if publicly accessible |
| Azure VM, Stopped (deallocated) | Not billed for the VM | Disks and networking resources |
| Azure VM, Stopped (allocated) | Still billed | Everything, because the VM still holds its host |
| Compute Engine VM | Instance stopped | Any resources that remain attached to it, such as disks |
Three details catch people out. First, on EC2 the data on instance store volumes is lost when the instance stops; only EBS data persists. Second, an Azure VM shut down from inside the guest OS ends up Stopped (allocated), which is still billed; you need a deallocate. Third, an RDS instance left stopped is started again automatically after seven consecutive days, so a long holiday shutdown needs a repeat stop.
Services with nothing to stop
Some services are billed on what you store and how much you use them, not on running hours, so a schedule has no effect:
- Amazon S3 charges for storing objects (by size, duration and storage class) and for requests.
- Amazon DynamoDB charges for reads, writes and stored data, plus optional features such as point-in-time recovery.
- Amazon EBS volumes keep billing for storage whether the instance they belong to is running or not.
- Azure SQL Database has no stop in the provisioned tiers; the serverless compute tier can auto-pause during inactivity, when only storage is billed, and auto-pause is currently supported only in the General Purpose service tier.
For these, the levers are lifecycle rules, retention, right-sized capacity and deletion of what is no longer needed, not schedules.
Temporary environments need an end date
A schedule limits the hours an environment runs; it does not end its life. Preview environments for a branch, load-test stacks and demo environments should also carry an expiry, tied to the branch merge or the test window, so they are deleted rather than parked indefinitely with their disks and addresses still billing.
Where ZopNight helps
ZopNight discovers resources across AWS, GCP and Azure accounts, so non-production resources can be found and grouped before anything is scheduled; read-only connections get discovery and recommendations, while start/stop needs a read + write connection. Start/stop covers resource types including EC2, RDS, Azure VMs (with deallocate handled as a provider-specific operation), Compute Engine, GKE, EKS and AKS. Savings are reported as the 24/7 cost minus the actual cost from time spent running.
For how to organise the work, see development environment management; for keeping scaled-down environments trustworthy, see environment parity vs cost; and for the scheduling rules themselves, cloud scheduling best practices.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Does stopping an EC2 instance delete my data?
Data on attached EBS volumes persists across a stop. Data on instance store volumes and in RAM is lost when the instance stops, and an automatically assigned public IPv4 address is released.
Why is my stopped Azure VM still on the bill?
It is probably in the Stopped (allocated) state, which happens when the VM is shut down from inside the operating system. Only Stopped (deallocated) ends the VM charge; disks and networking still bill in both states.