EBS Volume IDs and NVMe Device Names Across Instance Starts

Why the same EBS volume can acquire a different node name

A GPU-instance handoff may identify dataset storage only as /dev/nvme0n1. That reference can describe the current view accurately while failing to identify the intended resource at the next observation. The GPU workload does not make the Linux node number a durable storage identity.

AWS's EBS User Guide, checked October 20, 2026, describes Nitro EBS attachments using NVMe drivers. During boot, those drivers typically create nodes in device-response order. That order can differ from the block-device mapping and can change on a later instance start.

In the Linux naming pattern AWS documents, the number immediately after nvme is the enumeration order. For EBS device nodes in that pattern, the name ends in n1. That shared suffix is not a volume ID or a naming rule for every NVMe drive or storage system.

This explains a possible renaming without requiring a different storage resource. It does not say that every start changes the names.

References: [A1][A2]

Keep the attachment name, node, volume ID and filesystem UUID separate

The EC2 attachment name belongs to the requested block-device mapping. AWS's EC2 naming guide distinguishes that name from the name assigned inside the instance by its driver. Matching position in a supplied attachment list therefore cannot establish matching position in a Linux device list.

The Linux node is the device entry inside the instance being observed. The EBS volume ID identifies the cloud storage resource. AWS documents that volume ID as stable across instance state changes and supplied as the NVMe device-identification serial number. Those statements provide the link between the resource and an observed node; they do not make the node number persistent.

A filesystem UUID belongs to another layer. AWS describes it as generated when a device is formatted and persisting for the filesystem's life. It identifies the filesystem, rather than serving as another spelling of the EBS volume ID. Where a handoff includes filesystem information, its relationship to the identified volume needs to be explicit.

References: [A1][A2]

VI-334: two node assignments reverse, but two volumes remain

Consider two fictional EBS volumes, A and B, on one Nitro-based Linux instance. A and B stand for two distinct volume IDs, not AWS ID strings or dataset names. Stipulate that the supplied observations already establish each node-to-volume association. This is an explanatory mapping, not a real enumeration trace or a result from a customer system.

At start 1, /dev/nvme0n1 reaches A and /dev/nvme1n1 reaches B. At start 2, /dev/nvme0n1 reaches B and /dev/nvme1n1 reaches A.

Read across the observations by volume identity. A appears first at node 0 and later at node 1. B appears first at node 1 and later at node 0. Each observation contains two illustrated nodes referring to the same two volumes. Combining the observations does not create four volumes; each resource has been observed twice under different node assignments.

Now read a handoff note that says only dataset volume: /dev/nvme0n1. At start 1 that reference points to A; at start 2 it points to B. The note contains no stable resource identity with which to resolve its intended meaning. Retaining the same text has changed which resource it denotes.

The reverse problem is equally useful. A note that identifies A and records its current node can remain about A even when its node field changes. The changed field then describes a changed observation of the same object.

Distinguish a changed name from a changed resource

A different hypothetical observation could retain the names /dev/nvme0n1 and /dev/nvme1n1 while associating node 0 with A and node 1 with a new volume C. The node-name list would look unchanged, but the observed resource set would be A and C. Unchanged names cannot establish unchanged objects, just as changed names cannot establish replacement objects.

A count also cannot settle the difference. Both the A/B observation and the A/C observation contain two volumes. The missing information is their identity and association, not another count or a capacity total.

A partial observation has a narrower meaning again. In a separate incomplete handoff, suppose the only later association supplied is node 0 to B. That identifies B at that node. It leaves A's current node unresolved; it does not establish that A was deleted or replaced. Missing an association in the supplied note and observing a different volume are different findings.

For a supplied handoff, the useful comparison connects the identified instance and observation time to the reported volume IDs and node associations. An earlier mapping remains a description of the earlier observation. A list containing only node names, or only volume IDs without their associations, cannot resolve which volume a particular node denotes at the later observation. The appointed cloud or storage owner can supply that missing relationship.

An identified volume is not a validated dataset

Suppose both VI-334 observations correctly identify volume A. That answers which EBS resource is being discussed. The example contains no observation of A's stored bytes, so it cannot establish whether a dataset changed, which checkpoint it contains or whether an application can use it.

Adding a filesystem UUID would answer a filesystem-identity question within its stated scope. It would not convert the mapping into a content comparison. Likewise, calling a volume the training-data volume expresses an intended role; it is not evidence that the required data is present and usable.

Keep a resource-identity match separate from the outcome the buyer actually needs. The related EBS initialization guide addresses block-readiness questions; the checkpoint-versus-snapshot guide addresses retained application state. Those are useful next questions once the intended resource has been identified.

Keep any physical equipment package separate

If the wider project also includes physical servers or storage equipment, Leviathan's rack-and-stack service addresses agreed equipment mounting, IT cabling, labels and physical installation records. The related service and project inquiry are for that separate equipment package. Cloud volume mapping and application data validation remain with their appointed owners.

References: [L1]