Finding idle cloud resources with ongoing charges

Match recurring bill items to resource IDs, then check provider state and recent use to find idle resources that still incur charges. A running AWS EC2 instance is billed even when idle, and stopped VMs can leave disks or networking resources that still cost money.

Trace the charge to a resource

Start with a recent billing period that covers normal work. List recurring charges by account, project or subscription, including resource details where available, and keep the billing unit and period beside each amount. Compare the charges with the resource inventory and owner register; this is a resource investigation, not a reconciliation of the whole invoice.

Look for running VMs with little useful work, stopped VMs with retained storage, detached disks, unused addresses and old images. Check the provider’s resource names: AWS EBS volumes and Elastic IP addresses, Azure disks and networking resources, and Google Cloud Persistent Disks, IP addresses and custom disk images.

For AWS, check EC2 instance state. A running instance is billed each second, with a one-minute minimum, even if idle; a stopped instance’s usage is not billed. EBS volumes and Elastic IP addresses can still incur charges regardless of instance state, and a hibernated instance is billed while stopping.

For Azure, use the Virtual Machines - Instance View API or Azure Resources Explorer to check power states. A VM in Stopped (Allocated) is billed for instance usage; Stopped (Deallocated) is not, though disks and networking resources can still incur charges.

In the Google Cloud console, open idle-resource recommendations from Recommender. They cover Persistent Disk volumes, IP addresses and custom disk images; recommendations for idle VM instances are separate.

Google Cloud classifies a resource not attached to a VM or other resource for 15 days as idle. A blank Persistent Disk created at least 15 days ago, never attached to a VM and not bound to GKE Pods can be recommended for deletion, with listed savings of 100% of that disk’s cost. For a disk detached for at least 15 days and not bound to GKE Pods, the recommended action is to create a snapshot and then delete it; listed maintenance-cost savings are 35% to 92%.

Cloud Provider Idle Resource Charging Rules

Potential Savings from Idle Resource Actions

Establish whether it is unneeded

For each candidate, record its resource ID, charge, owner, environment, last known use, dependencies and observation period. Ask what would fail if it became unavailable, including monthly jobs, recovery roles, maintenance access and planned launches. Unknown ownership calls for investigation, not deletion.

A detached disk might hold data needed for recovery, and a quiet VM might run outside the observation period. A provider’s idle recommendation applies its stated conditions; it cannot decide whether the business needs to retain a resource.

Retire and verify

Before deletion, check what the provider will delete and what will remain, including data, snapshots and images. Record the owner, approved action and recovery requirement.

A staged stop or detach may allow observation through a relevant job cycle where the platform and workload support it. Treat this as a step to assess, not proof that deletion is safe.

After the action, confirm the resource state and compare the next suitable charge period on the same basis. Distinguish stopped compute from retained storage or networking charges, and record an actual billing result only when it is available.