# GPU EC2 terminated: check the EBS volumes left behind

Find EBS resources left after GPU EC2 termination by checking DeleteOnTermination, volume IDs, snapshots, regions and a verified restoration route.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/aws-gpu-ebs-after-termination/
Language: en

After a GPU EC2 instance is terminated, an EBS volume may remain and continue incurring charges. Its fate depends on that volume's `DeleteOnTermination` attribute. Terminating compute is therefore not proof that all project data or all related expenses have disappeared.

## Record each volume before deletion

The documented attribute preserves a volume when false and deletes it on termination when true. Defaults vary with volume and attachment circumstances, so inspect the actual setting rather than relying on a remembered rule.

Save volume IDs and purpose: boot system, inputs, edited data or temporary cache. Linux device names alone are not a sufficient audit trail. Keep the inventory and project tags outside the instance that will be removed.

## Separate EBS from instance store

EBS can exist independently of running EC2 compute. Instance store has a different temporary lifecycle and required data must be copied before termination. A familiar Linux directory does not identify the cloud device behind it.

| Object | Check before termination |
| --- | --- |
| Root EBS volume | Actual DeleteOnTermination setting |
| Additional EBS volume | Attribute and deliberate retention decision |
| Instance store | Required files exported beforehand |
| Snapshot | Purpose and independent retention period |

A retained volume and a snapshot are separate objects. Preserving one does not prove that the other exists or contains the latest useful state.

## Close a two-day pilot deliberately

Suppose a team uses a boot disk and a separate EBS volume for edited annotations. It exports the launch recipe, verifies the annotation-retention setting and opens a copy of a key result before terminating EC2.

Afterward, the owner finds the retained volume by ID in the correct region. If needed for the next stage, it receives an owner and review date. Otherwise verify an independent copy before removing it. Confirm the data really belongs to the finished test; a similar name is not enough to delete someone else's resource.

## Audit snapshots and restoration

Snapshots can outlive both instance and volume. Record date, source and reason for retaining each copy. Search every used region: an empty current-region view does not establish an empty account.

If keeping a disk for continuation, document the supported attachment or restoration path in an appropriate location. EBS and its target instance have placement constraints. A visible object in the console is useful only if the next operator can recover the intended files and understand why its expense remains.

## Turn the check into a practical next step

Terminating EC2 and deleting EBS are linked by each volume’s settings. Audit disks and snapshots independently before declaring the experiment finished.

For the documented details, consult the [primary documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/preserving-volumes-on-termination.html); [configuration reference](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html). Continue with [cloud gpu resource cleanup audit](/journal/cloud-gpu-resource-cleanup-audit/) and [cloud gpu ephemeral vs persistent checklist](/journal/cloud-gpu-ephemeral-vs-persistent-checklist/).