The Attic Problem: Why Your Cloud Bill Is Still Paying for Things Nobody Remembers Building

Every house has a spare room. You know the one. Boxes from the last move, a router you're keeping "just in case", a treadmill functioning mainly as a shelf. Nobody planned it that way. It simply accumulated, one reasonable-sounding decision at a time.

Cloud estates have exactly the same room, except this one is billed by the hour and nobody has to walk past it.

Founders rarely set out to build a sprawl. It happens by increments: a test environment for a migration that finished in the spring, a snapshot taken before a schema change and never removed, an account created for a contractor who has since moved on. Each one made sense on the day. Together, they form what we'd call decommissioning debt: the accumulated cost of infrastructure you still own but no longer use.

Unlike technical debt, it doesn't announce itself in code reviews. It just appears on the invoice, folded into a line item labelled something like "other" or "compute".

The usual suspects

When UK teams actually go looking, the same handful of items turn up again and again:

• Snapshots of volumes that no longer exist. The disk was deleted, the backup remained. Multiply by years.
• Detached storage. Block volumes sitting unattached in a region nobody's team is based in.
• Zombie staging environments. Full-size copies of production, running 24/7, used for a fortnight two summers ago.
• Accounts and tenants nobody claims. Set up for a pilot, an acquisition, a proof of concept, still holding credentials and still billing.
• Marketplace subscriptions on auto-renew. A monitoring tool procured for one project, still charging for seats the team has never logged into.
• Idle load balancers and floating IPs. Small line items on their own, oddly persistent in aggregate.
• DNS records pointing at services that were switched off. Harmless until they aren't.

Individually, most of these look like rounding errors. Collectively, they are frequently a double-digit percentage of a mid-sized bill.

Why it doesn't get cleared

It's tempting to blame laziness. The real reasons are more reasonable and harder to fix.

Deleting something is riskier than paying for it. A missed snapshot is a monthly charge; a deleted snapshot someone needed is an incident with your name on it. In most organisations, no reward exists for tidying up and considerable downside exists for being wrong. So the rational move is to leave it alone.

Ownership is also genuinely unclear. Cloud resources usually have a technical owner and a budget owner, and when those are different people, neither feels empowered to pull the plug. The person who originally built the thing may have left, taking the context with them.

And your procurement cycle may be actively working against you. If your organisation buys reserved capacity or commits to annual spend, the finance team has already paid for the waste. Deleting it can look, on a spreadsheet, like a loss rather than a saving.

The bill is only half the story

Cost gets the attention, but dormant infrastructure widens your attack surface at the same time. An account nobody monitors doesn't get patched. An old IAM user with an access key from a departed contractor is a credential with no owner watching it. A forgotten environment holding a copy of customer data is inside your compliance scope whether or not anyone remembers it exists.

If you hold ISO 27001 certification, or you're working towards Cyber Essentials Plus, your forgotten estate is still your estate. Auditors don't grade on intent.

The UK paperwork angle

Three bits of British admin make this more than a housekeeping exercise.

Retention. UK GDPR and the Data Protection Act 2018 ask you not to keep personal data longer than necessary. "We forgot it was there" is not a retention policy, and the ICO has been consistently clear that knowing where data lives is part of your obligations. Dormant environments holding customer records are the awkward end of this conversation.

Procurement records. In the public sector, and increasingly in larger private organisations, contract registers and purchase orders show what was bought and when it should have ended. Comparing that list against what's actually running is one of the fastest ways to find waste, because the paperwork remembers what the team has forgotten. Watch for notice periods on auto-renewing contracts, too. Finding a ghost in October is fine; finding it two days after the renewal window closed is expensive.

Carbon reporting. Streamlined Energy and Carbon Reporting has pushed energy data onto the finance agenda, and provider carbon dashboards now give you a per-region estimate. Idle resources score badly here: they consume power and deliver nothing, which is the least defensible emissions profile in any annual report.

Make it a quarter, not a project

Big clean-ups fail because they're treated as a one-off. A six-week audit produces a satisfying list, a few deletions, and then the same problem rebuilds itself within a year.

The teams that keep a lean estate build the habit into something that already happens. A quarterly review, scheduled alongside whatever renewal or budget meeting already exists, with a named owner and a short agenda. Non-production resources get a default time-to-live. Anything without a tag gets flagged rather than ignored. Deletions go through a documented window with a sign-off, so nobody has to gamble their reputation on a judgement call.

A checklist to run before the next renewal

1. Pull a full inventory across every account and subscription, including the ones you think are empty.
2. Tag by owner, environment and project. Anything untagged goes on the suspect list.
3. Check every snapshot older than 90 days for a matching parent volume.
4. List storage volumes and load balancers with zero attachments or traffic in 30 days.
5. Cross-reference active accounts against your HR and contractor records.
6. Compare the procurement register against live subscriptions and note renewal dates.
7. Confirm retention schedules for anything holding personal data, and log your reasoning.
8. Set a deletion date, notify the owner in writing, then actually delete.
9. Record the saving and the carbon estimate. You'll want both at budget time.
10. Book the next review before you close this one.

What good looks like after two rounds

The first pass is always the ugliest. The second is where it starts to feel routine, because the estate stops surprising you. The third is where decommissioning stops being a project and becomes the way your team works.

Nobody joins a cloud team hoping to spend their quarter deleting other people's old test environments. But the alternative is paying for that attic indefinitely, in cash, in risk and in carbon, while the invoice quietly grows a line item that nobody can quite explain.