Deleting compute does not retire everything

Retirement closes dependencies, not just a compute icon.

Define closure per resource

A retirement disposition records whether a dependency will be removed, transferred, or deliberately retained, with an owner and acceptance evidence. Compute, storage, identities, and backups can have different lifecycles.

For EC2, attached EBS volume deletion depends on its termination setting. Terminating an instance is therefore not sufficient evidence that every associated storage resource disappeared.

The Atlas project handover

D1: The instance is terminated. Volume V7 had deletion on termination disabled and remains available.

D2: The owner approves retaining snapshot S7 for 30 days and deleting V7 after a successful recovery check. S7 exists, but no recovery result is supplied.

D3: The publishing role is also used by an active project. Whether the retired Atlas job can still obtain that role is unknown.

Assume these are current records and no other retention requirement changes D2. Compute can be marked closed. V7 remains pending because the owner’s recovery condition has not been demonstrated. S7 should have a retention owner, protected access, and a dated disposition review.

Keep the shared role for its approved active consumer. Separately assign review of Atlas’s remaining eligibility and any issued sessions to the identity owner. The absence of an instance does not answer those questions for other execution environments.

Write four closure rows with evidence identifiers. A useful model says “instance closed: D1,” “volume pending: recovery result missing,” “snapshot retained: owner and day-30 review,” and “role retained: active use; Atlas eligibility unresolved.”

Acceptance must protect both sides: the retired job loses unneeded authority while the active project still works. State the inventory boundary; these four rows do not prove that no external exports, billing resources, or undiscovered copies remain.