Cloud Waste Calculator

Price the resources nobody is using, at rates you take from your own bill. There is no bundled price list: a category with a count and no rate is excluded from the total rather than estimated.

Compute
Storage

Priced by provisioned size, not by object count, so both the count and the total gigabytes are needed.

Network

cloud-waste.txt

updates as you type

    Common mistakes

    These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

    1. Running a one-off cleanup and calling it done

      Nothing changed about how resources are created, so the same categories are back within a quarter. Snapshots in particular grow by a constant amount every week forever.

      Instead:Lifecycle policies with expiries, and an owner tag required at creation so the next audit is a list of people to ask.

    2. Deleting unattached storage without finding an owner

      The instance it belonged to is gone, so there is nothing to trace it back to, and a volume with no attachment may be next week's restore. This is why nobody deletes them: the blocker is attribution, not effort.

      Instead:Tag at creation. Treat the counts here as a question for an owner, not a delete list.

    3. Looking at instances and ignoring the network

      NAT gateways charge per hour and per gigabyte processed, and one left in an emptied subnet is often the single largest line in a torn-down environment. Load balancers with no healthy targets bill the same way.

      Instead:Audit gateways and balancers alongside compute. A VPC endpoint frequently replaces a NAT gateway outright.

    The expensive waste is the kind nobody owns

    An idle instance is on somebody's dashboard and somebody's conscience. An unattached volume is on neither, which is why it bills for three years.

    Deletion is not the hard part

    Nobody deletes an unattached volume because nobody knows whose it was. The instance it belonged to is gone, so there is nothing to trace it back to, and deleting storage you cannot identify is a risk no engineer takes on a Friday. The blocker is attribution, not effort.

    Snapshots grow by accretion

    Every backup job adds one. Almost no backup job removes any. The line on the bill goes up by a constant amount every week forever, which is exactly the shape nobody notices, because there is never a day it jumps. A one-off cleanup is undone within a quarter; a lifecycle policy with an expiry is not.

    NAT gateways are the expensive surprise

    They charge per hour and per gigabyte processed. A gateway left in an emptied subnet is pure hourly cost with nothing to show, and it is often the single largest line in a torn-down environment. A VPC endpoint frequently replaces one outright and removes the data charge as well.

    Idle load balancers outlive their targets

    Environments are usually torn down from the top: the application goes, then the instances, and the load balancer stays because nothing depended on it. It bills its hourly charge with no healthy targets and no traffic.

    Enter your own rates, because a bundled price list would rot

    There is no built-in table here on purpose. Per-hour rates differ by provider, region, instance family, commitment and negotiated discount, and a table baked into a static page goes stale the week after it is written with nothing to notice. Any category you give a count and no rate is excluded from the total rather than guessed at, so the number is an undercount you can trust rather than an estimate you cannot.

    What this cannot see

    Your account. It does nothing but arithmetic on numbers you type, in your browser, with no credentials and no API call, which is also why it is safe to use on infrastructure you would not describe to a stranger. It cannot tell you whether a resource is genuinely unused: an instance at two percent CPU may be a warm standby, and a volume with no attachment may be next week's restore. The counts are a question to ask an owner, not a delete list.