Decommissioning, and the cost of what you forgot

Why this matters

Lifecycle management has a last stage, and it is the one nobody is assigned. Creating resources is somebody's project; removing them is nobody's.

The result is a predictable accumulation: every estate of any age contains volumes attached to nothing, snapshots of instances that no longer exist, addresses reserved for systems long retired, and whole environments built for projects that ended. They cost money every hour, they enlarge the attack surface, and they make every inventory and every audit harder.

This is also a security and compliance topic, not only a cost one. An orphaned resource is unpatched, unmonitored and unowned, which is an excellent description of a way in.

The lesson

Finding orphaned resources: unattached disks, idle addresses, old snapshots, empty clusters

The recurring list, worth knowing by name because these are what the questions describe:

• Unattached block volumes. Left when an instance is terminated without its additional disks. Billed at full price, forever, holding data nobody has reviewed.
• Snapshots of deleted resources. Created automatically, never expired. Individually small, collectively large, and they may contain data the organisation believes it deleted years ago.
• Unassociated static addresses. Often billed specifically when idle.
• Load balancers with no healthy targets, billed hourly regardless.
• Old machine images and container image tags, each holding its underlying storage.
• Empty or idle clusters, and node groups scaled to zero that still carry a control-plane charge.
• Orphaned network interfaces, which also block the deletion of the subnets and security groups that reference them — a genuinely confusing failure where a delete fails with a dependency error pointing at something invisible.
• Unused databases in a non-production account, which are frequently the single largest line item nobody has looked at.
• Log groups and retention set to "never expire", which grow without limit.

How to find them, in order of how well it works:

1. Filter by tag. Resources missing the required tags are almost always the orphans — which is the argument from objective 1.8 that the untagged report is the waste report.
2. Use the provider's own recommendations. Every provider surfaces idle and unattached resources; it costs nothing to read.
3. Query the estate directly for the states above — volume status available, addresses with no association, load balancers with zero healthy targets.
4. Reconcile against infrastructure as code. Anything real that no template owns is either unmanaged or orphaned, and the nightly drift plan from objective 2.2 surfaces it.
5. Check every region. Resources created in a region nobody uses are invisible to anyone looking only at the usual one, and this is a common hiding place.

Make it a routine, monthly, with an owner. A one-off cleanup is a successful project that recurs in eighteen months.

The dependency check before deletion, and the thing still quietly using it

Deleting something still in use is worse than leaving it, so a check comes first. The uncomfortable truth is that the absence of evidence is weak evidence: a resource with no traffic today may be used monthly.

Practical checks before removing anything:

• Observe traffic for a full business cycle. Flow logs, load balancer metrics, database connections. A month, not a day — the same reasoning as the dependency mapping in objective 2.1.
• Search the estate for references: DNS records, configuration files, templates, firewall rules, allow-lists, scripts, dashboards and alerts.
• Check for inbound dependencies from outside, including partners. These are the ones that break loudly and are not visible in your own configuration.
• Ask the owner — and if nobody can be found, that is itself the finding. Resources with no owner are the ones to remove, carefully.

Then use the safe sequence, which is the single most valuable habit in this lesson:

1. Isolate rather than delete. Stop the instance, remove it from the load balancer, or tighten its security group to deny. The resource still exists and can be restored in seconds.
2. Wait. Long enough to span the business cycle — often a month.
3. Watch for complaints and errors, which is the real test.
4. Snapshot or export whatever must be retained.
5. Then delete, properly, and record it.

This turns an irreversible action into a reversible one for the period when mistakes surface. It costs a little storage and it prevents the incident where a quarterly process fails because its database was cleaned up in month two.

Data retention obligations that outlive the system holding the data

Decommissioning is where technical tidiness meets legal obligation, and they frequently disagree.

Two failure directions, both real:

• Deleting data you were required to keep. Financial records, medical records, employment records and audit logs commonly carry multi-year statutory retention. The obligation attaches to the data, not to the system, so retiring an application does not retire its retention requirement.
• Keeping data you were required to delete. Privacy regimes give individuals deletion rights and require that personal data not be kept longer than necessary. An orphaned snapshot containing customer records is a violation that nobody intended, and "we forgot it existed" is not a defence.

So the decommissioning process must include a data step:

• Classify what the system holds before removing it.
• Check retention requirements with whoever owns them — legal, compliance, the data owner.
• Export what must be kept into a durable, retrievable, documented archive. An archive nobody can read in five years satisfies nothing, so record the format and verify a retrieval.
• Check for a legal hold, which suspends normal deletion entirely and overrides the schedule.
• Then delete the rest, including backups and snapshots — which people forget, leaving the data present in exactly the copies nobody inventories.

Secure deletion in a shared-tenancy world, and what the provider will attest to

Traditional secure disposal means overwriting or physically destroying a disk. In a cloud you cannot do either: you do not own the media, you cannot identify which device held your data, and it is shared with other tenants.

What is true instead:

• Providers guarantee that storage is zeroed or otherwise sanitised before reallocation to another customer. This is stated in their documentation and covered by their third-party audit reports.
• The customer's mechanism is deletion plus encryption. Delete the resource, and rely on the provider's sanitisation for the media.
• Crypto-shredding is the strong control. If data was encrypted with a customer-managed key, destroying the key renders the data unrecoverable regardless of where copies physically live. This is the cloud answer to secure erasure and it is the examinable one, because it is the only mechanism that works on storage you do not control — including backups and replicas you may not be able to enumerate.
• For evidence, use the provider's attestations, not your own testing. You cannot verify media sanitisation yourself; the audit reports from objective 4.4 are what you give an auditor.

The practical sequence for sensitive data: encrypt it with a customer-managed key from the start, delete the resources normally, then destroy the key once retention allows — and record that destruction, because the record is the evidence.

Recording the decommission so the resource does not reappear in next month's bill

The last step is documentation, and it is what stops the same work recurring.

Record, per decommissioned system:

• What was removed, by identifier, and when.
• Who authorised it.
• What was retained, where, in what format, and until when.
• Whether a key was destroyed, and when.
• What was updated as a consequence: DNS records removed, monitoring and alerting deleted, backup jobs cancelled, licences released, runbooks retired, documentation corrected, and the infrastructure code that defined it deleted from the repository.

That last list is where decommissioning is usually incomplete. Systems are shut down and their monitoring keeps alerting, their backup jobs keep running and billing, their licences keep being paid for, and their code stays in the repository ready to be re-applied by someone who does not know it was retired. Deleting the template is part of deleting the system, or the next apply brings it back — which is the drift lesson in reverse and a neat exam scenario.

Then close the loop on cost: check the following month's bill for the charges that should have stopped. If they have not, something was missed, and finding out now is much easier than a year later.

What to take into the exam

• The orphan list: unattached volumes, snapshots of deleted resources, idle addresses, empty load balancers, old images, orphaned network interfaces. Check every region.
• Untagged is the best proxy for orphaned.
• Isolate, wait a business cycle, snapshot, then delete. Absence of traffic today is weak evidence.
• Retention attaches to the data, not the system — and privacy rules can require deletion that an orphaned snapshot silently violates.
• You cannot wipe media you do not own. Crypto-shredding — destroying the key — is the cloud's secure-erasure control, and provider attestations are the evidence.
• Decommissioning includes deleting the infrastructure code, the monitoring, the backup jobs and the licences — and checking next month's bill.