Infrastructure Idle Costs: What Keeps Billing When Unused
A stopped instance is cheaper, not free. The charges that survive a stop are where idle cost hides.
Infrastructure idle cost is the money a cloud account spends on capacity that is provisioned but not doing work. Some of it is obvious, a VM running at night with nobody using it. Much of it is less obvious: the charges that continue after a resource has been stopped, detached, or forgotten, because cloud providers bill storage, addresses, and managed networking by what exists rather than by what is used.
What a stop actually removes
Stopping a virtual machine ends the compute charge on all three major clouds, with conditions:
- AWS EC2: a stopped instance is not billed for instance usage, but EBS volumes and Elastic IP addresses incur charges regardless of the instance’s state. All Elastic IP addresses, in use or idle, are charged. Data on instance store volumes is erased when an instance stops, which is why instances with instance-store root volumes cannot be stopped at all.
- Google Cloud Compute Engine: a stopped instance keeps its attached disks and IP addresses, and you keep paying for resources that remain attached. A static external IP address still counts as in use, and billed, while its VM is stopped. Local SSD data is discarded on stop unless you choose to preserve it.
- Azure Virtual Machines: the state matters. A VM that is Stopped (allocated), for example after a shutdown from inside the guest OS, is still billed for compute. Only Stopped (deallocated) ends instance billing, and even then disks and networking continue to incur charges.
A schedule that shuts down Azure VMs from the guest OS rather than deallocating them saves nothing on compute.
Charges with no running server behind them
| Item | Why it keeps billing |
|---|---|
| Unattached block volumes | AWS charges EBS volume storage by provisioned GB per month until you release it |
| Snapshots | Charged by data stored; because EBS snapshots are incremental, deleting one may not reduce cost if later snapshots reference the same data |
| Public IPv4 addresses | AWS charges every Elastic IP address, attached or not |
| NAT gateways | Billed for every hour provisioned, partial hours rounded up, plus a per-GB processing charge; the only way to stop the hourly charge is to delete the gateway |
| Load balancers with no targets | AWS bills Application and Network Load Balancers for each hour or partial hour they run, plus capacity units |
The NAT row is worth stressing: stopping the instances behind a NAT gateway removes the per-GB processing charge for their traffic, but the hourly charge continues until the gateway itself is deleted.
Finding it
Idle cost is easiest to see by listing resources whose cost is non-zero while their utilization or attachment says they are unused: volumes with no attachment, IPs with no association, gateways with no processed bytes, stopped instances with large disks. Then sort by cost, not count.
Removing it safely
- Wait before deleting anything that was only recently detached; a volume can be mid-migration.
- Snapshot before deleting a volume only if you will need the data, and set an expiry on that snapshot.
- Delete NAT gateways and load balancers in environments that are torn down, not merely stopped.
Where ZopNight helps
ZopNight’s orphan recommendations cover detached and unused resources such as unattached disks and old snapshots, and its idle category includes unused NAT gateways. Auto-remediation only deletes on authoritative orphan evidence, for example a block volume that is unattached and at least seven days old, and otherwise demotes the recommendation to advisory. Destructive steps pass an admin-approval gate. Schedules handle Azure deallocation rather than a plain stop.
Related: the idle resource problem, data transfer costs, and resource lifecycle.