You spin up a server in the cloud to test a new app or run a project. When you're done, you shut it down. The compute instance disappears from your console, but the storage volume stays behind, still attached to your account and still billing you every month. AWS calls this problem orphaned volumes, and their own cost-management documentation walks through an automated process to find and delete them. For businesses running cloud infrastructure in Azure, AWS, or Google Cloud, the principle is the same: storage costs add up fast when nobody is watching.
Why storage volumes survive the server
When you launch a cloud server, it comes with storage attached. That storage is billed separately from the compute instance. If you terminate the server but don't check a box marked Delete on Termination, the storage stays live.
Development and testing cycles are the biggest culprit. Your team spins up a test environment, runs some builds, then shuts it down. If there's no workflow to clean up the storage automatically, the volumes sit there. You don't see them in your list of running instances, but they appear on your invoice every month.
CloudTrail logs are stored for 90 days, which gives you a window to review what happened to each volume. After that, you're relying on your own records or the metadata the cloud platform keeps.
What this looks like on your monthly bill
Storage is cheap per gigabyte, so a single orphaned volume might cost a few dollars. The problem is volume. If your team runs frequent tests or deploys experimental infrastructure, you can easily accumulate dozens of forgotten volumes. Ten volumes at five dollars each is fifty dollars a month, six hundred dollars a year, for storage nobody uses.
Most Ontario businesses we've talked to discover this problem when someone finally asks why the cloud bill keeps rising even though server usage is stable. The answer is often a long list of detached volumes that nobody remembered to delete.
You can check your own environment right now. Log into your cloud console, navigate to the storage section, and filter for volumes with a status of available. If the list is longer than you expected, you've found the issue.
How AWS suggests you handle it
AWS published a detailed walkthrough for automating the cleanup process. The approach uses CloudWatch Events to run a Lambda function on a schedule. The function checks CloudTrail for volumes that have been detached and unused for a defined period, then creates an operational work item in Systems Manager OpsCenter. From there, you can choose to snapshot the volume before deleting it, or simply remove it.
The walkthrough includes environment variables to control behaviour. IGNORE_WINDOW sets how many days a volume can sit unused before being flagged. BATCH_SIZE groups up to 100 volumes into a single work item. SNS_ARN sends a notification when orphaned volumes are found.
The full process involves creating an SNS topic, setting up a Lambda execution role with the right permissions, writing environment variables, packaging the function with specific versions of boto3 and botocore, and scheduling it to run daily. It's a multi-step setup, and it assumes you're comfortable working in the console and writing JSON policies.
What makes sense for a smaller business
If you have one or two people managing your cloud environment and they're not developers, automating this process is probably more work than it's worth. A simpler approach is to schedule a monthly review. Set a calendar reminder, log into the console, check for detached volumes, and delete anything that's been sitting for more than a month. It takes ten minutes.
If you're running a larger environment with multiple projects and frequent deployments, automation starts to make sense. The Lambda function does the hunting for you, and the work items in OpsCenter give you a clear list of what to clean up. You still make the final decision on each volume, but the system brings the problem to your attention instead of waiting for you to remember.
The other option is to set a policy that every cloud resource must be tagged with a project name and an owner. When you review detached volumes, you can see who created them and ask whether they're still needed. Tags don't prevent orphaned volumes, but they make cleanup much faster.
What to do this week
Log into your cloud console and check how many detached volumes you have. If the list is empty, you don't have a problem. If you see a handful, delete the ones you know are obsolete and make a note to check again in a month. If you see dozens, you need a process.
Talk to whoever manages your cloud environment and ask them to add detached volume cleanup to their monthly checklist. If nobody on your team has time to do this consistently, it's worth bringing in outside help to set up automation or run the review for you.
Don't panic if you find orphaned volumes. They're not a security risk, just a cost leak. Snapshot anything you might need later, delete the rest, and move on. The bigger question is how to stop it happening again.
