Automated cloud resource cleanup: configuring AWS and Kubernetes

Automatic cleanup of cloud resources: where the leak begins

Cloud resource leakage begins where a resource is created for a specific task and continues to exist after that task is completed. In Amazon Web Services, a volume is not deleted with the instance by default—and after the environment is torn down, it continues to be billed.

One such volume is invisible, but over a dozen environment iterations a layer accumulates that no one has ever checked.

In Kubernetes, the leak follows its own channels: persistent volume claims remain after namespace deletion, LoadBalancer services hang without workloads, and old snapshots and images pile up in the registry.

Infrastructure sprawl is accelerated by the fact that resources are created automatically when new versions are delivered, but deleted manually and from memory.

Unused load balancers and orphaned volumes are dangerous not only because of rising costs: they distort the picture during incident investigation and create false dependencies in capacity planning.

A manual quarterly audit becomes outdated the moment it is completed—several releases and experiments manage to occur between checks.

We explain how this is addressed: automatic cloud resource cleanup rules tied to an owner tag and lifetime, regular orphan audits across all resource types, and deletion with a quarantine window so rollback remains possible.

What a managed resource lifecycle provides

Lifecycle rules turn cleanup from a set of manual actions into a declaration: each resource gets a lifetime, a renewal condition, and an owner. The effect then breaks down into four measurable values that are visible in monitoring rather than described in words.

Deployment speed and recovery time

Build and deployment speed grows not from the rules themselves, but because the environment stops accumulating garbage.

Build cache, temporary volumes, and test namespaces are removed on schedule, so a new environment comes up from a clean declaration, without manually searching for conflicting objects.

Recovery time after a failure depends on how quickly occupied names, volumes, and quotas are freed—in a cluster these are the scarcest entities. When a rule removes stuck objects upon expiry, recovery takes minutes instead of waiting for someone to free the resource manually.

Idle nodes and manual operations

The share of idle nodes is calculated as the ratio of requested capacity to actual consumption. Autoscaling reduces it but does not eliminate it: night windows, environments after demos, and nodes for one-off tasks remain. Rules remove exactly this remainder and return it to the shared pool.

Reduction of manual operations is the share of resources freed without engineer involvement. We bring it to values where manual cleanup remains only for exceptions, and every exception is logged.

This makes the environment predictable: identical conditions produce identical results and do not depend on who is on call today.

Cleanup modes: by lifetime, by event, by metric

The cleanup mode determines by which attribute the rule considers a resource used up. In AWS and in a cluster, such attributes live at different levels: image version lifetime, an event in the environment lifecycle, actual disk utilization. Mixing levels in one rule leads cleanup to delete what a neighboring rule relies on.

Lifetime and event: predictability vs accuracy

Lifetime works without external dependencies—a date label and a periodic registry sweep are enough. It breaks on exceptions: the retention policy must keep several latest objects per version, otherwise rollback to the previous release becomes impossible.

Event-based cleanup is more precise, but relies on delivery of notification about job completion or branch merge.

Metric-based cleanup: labels and owners required

Metric-based cleanup relies on actual utilization: an idle disk, a node without load, a load balancer without requests.

Here labels and resource owners are indispensable—the rule must know whose resource it is and what lifetime it belongs to, otherwise it will trigger on a live environment during an idle period.

The working scheme is to combine: lifetime as insurance against forever-live objects, metric as grounds for early deletion.

Implementation stages: from inventory to handover

The order of stages here is not a formality. If you start directly with deletion rules, automation will tear down what the team has not yet labeled: orphaned volumes, snapshots without an owner, test environments everyone has forgotten. Therefore first accounting and labels, then observation mode, and only then enabling deletion.

1. Inventory of resources and owners. Collect a complete list: volumes, snapshots, load balancers, clusters, old environments. Separately identify what was created manually and is not described in configuration—this is where the main risk lies.
2. Ownership scheme. Each unit gets a team, environment, and class label: production, test, disposable. Anything that could not be matched to an owner goes to a separate list for review, not for deletion.
3. Observation mode. Rules run idle and only write a report about what would have been deleted. For two to four weeks we compare the report with actual consumption and adjust thresholds.
4. Configuring deletion rules. Lifetime is set by resource classes, exceptions by labels, deletion itself is delayed and has a cancellation window. Snapshots and backups are placed outside the rule.
5. Testing rules in a test environment. Create resources with expired lifetime and verify that only the targeted ones are removed and the recovery point remains functional.
6. Handover of regulations. Document lifetimes by class, required labels, the procedure for renewal and exception requests, and rollback points.

What we record in the regulation

The regulation describes not only lifetimes but also how to extend a resource: label, owner request, automatic exception for a given period. Without this, engineers bypass automation manually, and cleanup quietly stops working.

Retention policies, schemes, and regulations as deliverables

A project is closed not when the rules start working, but when the team can change them without the author.

Therefore the package includes not only configurations but also retention policies, a resource labeling scheme, an access rights matrix, and a response regulation—all next to the code, not in chat.

Policies, labeling, and roles

• Retention policies: lifetime for each resource class—unused disks, snapshots, old images, test clusters, “orphaned” load balancers and addresses.
• Resource labeling scheme: required owner, environment, and lifetime labels; without them a resource goes into the report, not for deletion.
• Access rights and roles matrix: who changes policy, who only labels resources, who confirms irreversible deletion.
• List of protected labels and exceptions: showcase environments, long-lived data, resources for audit and incident investigation.

Documentation and regulation

• Operations manual: where the rules are stored, how to check a trigger, and how to roll back the last deletion.
• Event logs and reports: what was deleted, what initiated it, what went into quarantine before deletion.
• On-call shift response regulation: procedure for false positives, missed resources, and stopped cleanup jobs.

Such a package survives both team turnover and contractor changes: rules are read from labels rather than reconstructed from an engineer's memory.

Case study: how infrastructure sprawl was reduced threefold

The client came with growing cloud resource consumption and no answer to what exactly was consuming it.

Inventory revealed a familiar picture: disk snapshots accumulated after every build, volumes remained after test environments were deleted, and images from all builds, including canceled ones, settled in the local registry.

The orchestration cluster had lived with this for several years—the number of objects grew by about 8% per month, and a third of them were not tied to any working service.

For each class of objects, a lifecycle rule was described, and they were assembled into two independent perimeters—cloud and cluster.

Snapshots older than a specified period are deleted, unattached volumes go into quarantine for a week, the last ten images remain per tag in the registry, and the rest is cleaned up. Separately, we verified that the rule does not affect resources marked as permanent.

What did not go according to plan

The first version of the rules deleted volumes that engineers manually brought up for incident investigation: overnight, part of the diagnostic environments was removed along with logs.

Exception handling was reworked—anything marked as protected is ignored by the rule, any deletion passes through a quarantine window, and new rules run for a week in dry-run mode with a report of what would have been deleted. After that, cases of data loss did not recur.

Metrics were taken from the same inventory before and after:

• share of freed resources—about a third of the environment's objects;
• objects without an owner: from a third to a few percent;
• image registry volume decreased threefold;
• pre-migration inventory—one day instead of a week.

Environment sprawl was stopped: the growth in the number of objects was replaced by a smooth decline, and the rules continue to work without manual intervention.

What to do if the cluster has already sprawled?

An overgrown environment cannot be cleaned with one button: deleting a resource that someone keeps “just in case” breaks the environment. Therefore the first question is not “which rules to enable” but “what has already accumulated and who is responsible for it”.

This gives two workable paths: a one-time audit of what has accumulated and gradual implementation of rules that then clean resources themselves.

A one-time audit—inventory by tags, consumption metrics, and owners. We separate orphans—unattached volumes in Kubernetes, old snapshots, unoccupied addresses, idle node groups—from live workloads and submit lists to the owner for confirmation. Deletion proceeds in batches, with a log and rollback where recovery is possible at all.

Gradual implementation starts with observation mode: rules run but do not delete, only write what they would have deleted.

After a couple of weeks, the log itself shows cleanup priorities, and the rules are switched to deletion with a delayed period by label—starting with non-critical environments.

The order of work is usually the same: first, what does not affect production—orphaned volumes and snapshots, outdated images, free addresses; then idle capacity; and only then rules for live workloads.

Deletion risks and protection against false positives

A false positive costs more than the storage saved: a rule built on resource age will one day remove an environment to which a client is already tied.

Therefore cleanup proceeds in two loops—first the object is marked as a deletion candidate and the owner receives a notification; deletion itself is performed as the second step, after a confirmation window. For environments with a long lifecycle, we make the window longer; for temporary ones, shorter.

Resources outside templates and everything created by hand are not touched by automation by default: without an owner and environment label, an object goes only into the report for manual review.

Exceptions to the rules are set by the same labels—this way a new environment does not accidentally fall under cleanup.

What protects against deletion in a false positive?

Deletion protection on critical objects, a two-phase scheme, and a dry-run mode: the rule first shows exactly what will be deleted and only then triggers. Rollback is from a volume snapshot taken before deletion.

Are copies made, and what happens to logs?

Before a volume is deleted, a snapshot is taken, and logs are exported to object storage with their own retention period—separate from the resource's lifetime. Data remains available for review even after the object is deleted.

Let's discuss the task: what we need from you and how we'll start

“Automatic cleanup of cloud resources” begins not with deletion rules but with inventory: so that a policy does not tear down a working volume or cluster, you need to know exactly what you have and who is responsible for it.

Therefore the starting order is always the same—review of source data, assessment and work plan, approval of a pilot on one environment.

What will be useful from you at the start:

• list of cloud accounts, projects, and clusters covered by the task;
• inventory export or read-only access to billing—it shows what actually accumulates;
• current tagging and labeling rules: without them the rule “delete everything without an owner tag” is dangerous;
• list of resources that must never be touched—production data, long-term backups, regulatory archives;
• maintenance windows and the person responsible on your side who confirms deletions;
• notification channel—where to send the report on triggered rules.

On our side, we will clarify retention boundaries by resource class, separate environments where the rule only logs triggers and where it already deletes, and define the rollback procedure: how many versions we keep and how we restore mistakenly deleted items.

After that, we will return with an assessment and plan: work stages, what we cover, what remains on your side, and the support scope for the pilot. Describe the task—we will provide a plan with stages and responsibility areas.