EBS Snapshot Archive Changes the Quantity Behind the Storage Rate

Identify the quantity each offer prices

An AI storage proposal might describe a recent snapshot as a small increment and offer to archive it at a lower unit rate. That leaves two questions open: how much data enters archive, and how much standard storage disappears?

AWS's EBS documentation, checked October 20, 2026, distinguishes a first snapshot containing written data from later snapshots that capture changed or new blocks and reference unchanged data. The full captured state follows the written blocks at capture, rather than the source volume's provisioned capacity.

Keep four quantities separate: source-volume capacity; the full written-block state represented by a snapshot; the incremental changes captured since the preceding snapshot; and the union of block versions needed by the retained standard snapshots. Counting a shared version once in that union avoids treating every logical state as another complete standard copy.

References: [ESA1]

ESA-01: three 80 GiB states retain 81 GiB of versions

Consider a fictional same-volume, same-owner, same-key incremental history. S0 captures exactly 80 GiB of written data. Before S1, exactly 1 GiB is replaced with different data and the other 79 GiB is unchanged. S2 is identical to S1. The retention requirement explicitly keeps all three captured states.

The retained standard data consists of 79 GiB shared across the states, 1 GiB of the old version needed by S0, and 1 GiB of the replacement version needed by S1 and S2. Its union is 79 + 1 + 1 = 81 GiB. Summing three 80 GiB logical states would instead give 240 GiB and count their shared data repeatedly.

S1 captured a 1 GiB increment, while its complete state still represents 80 GiB. S2 adds no new version in this stipulated history. These are invented GiB-sized accounting ranges, not an assertion about actual EBS block size, filesystem usage or measured billing. The example uses the stated sharing relationships rather than assuming account-wide deduplication.

References: [ESA1]

Archiving S1 adds 80 GiB and releases no standard data

Now consider a proposal that places the middle snapshot, S1, in archive while keeping S0 and S2 in standard. AWS describes archiving as conversion to a full snapshot containing the written blocks represented at capture. S1 therefore becomes an 80 GiB archive snapshot in this model.

The surviving standard snapshots still need all 81 GiB: S0 needs the unchanged 79 GiB and its old 1 GiB; S2 needs the unchanged 79 GiB and the replacement 1 GiB. Their union has not shrunk. The replacement version remains needed even though the snapshot that first introduced it has changed tier.

AWS's archive guidelines explain that data referenced by a later snapshot can remain in standard, with its storage costs allocated to that later snapshot. Moving a snapshot's attributed charge does not establish a reduction in the family's stored data. Here the standard reduction is zero, and the new archive quantity is 80 GiB. Pricing only S1's recent 1 GiB increment would miss the full archive quantity.

References: [ESA2][ESA3]

Over the same 90 days, the cheaper rate costs 48 CU more

Assume the quantities above remain stable for 90 days, with the archive placement complete at the comparison's start. Model that interval as three invented 30-day accounting periods. The standard rate is 1 accounting unit, or CU, per GiB per period; the archive rate is 0.2 CU per GiB per period. These rates and periods are fictional, not current AWS prices or its invoice calendar.

Keeping all three states in standard costs 81 x 1 x 3 = 243 CU. The alternative retains 81 GiB in standard and adds 80 GiB in archive, so it costs (81 x 1 + 80 x 0.2) x 3 = 291 CU. The difference is 291 - 243 = 48 CU more.

The archive rate is lower in the invented model, yet the added quantity reverses the apparent benefit. Both alternatives preserve the stipulated three states, so the result has not been manufactured by silently removing a retention requirement.

This is a storage-only comparison. It excludes transitions, requests, retrieval, temporary restored storage, taxes and other charges, and it establishes neither an actual bill nor equivalent access readiness. Those omissions must be resolved in a complete real offer.

References: [ESA2][ESA3]

A different retained population can reverse the comparison

For a stable storage-only comparison over a common period, call the full archive quantity A GiB and the standard quantity genuinely released R GiB. The change per period is A x archive rate - R x standard rate. Storage cost falls only when the removed standard charge exceeds the added archive charge.

With A = 80 GiB and the invented rates above, more than 16 GiB would have to leave standard for the storage-only result to become cheaper. Exactly 16 GiB would tie before other charges. ESA-01 releases zero, so it does not meet that condition. A snapshot's incremental attribution cannot substitute for evidence of R.

Now stipulate a separate requirement from the start: only one 80 GiB captured state is needed. Its alternatives contain 80 GiB in standard or a full 80 GiB in archive, with no surviving standard snapshot population. Using the same three invented periods and rates gives 80 x 1 x 3 = 240 CU versus 80 x 0.2 x 3 = 48 CU.

That second comparison concerns a different retention population. It does not revise the 291 CU result or justify removing any of the three required states in ESA-01. It shows why the retained-state requirement must be agreed before evaluating a tier offer.

References: [ESA3]

Add the actual duration and restore conditions

AWS specifies a 90-day minimum archive period. Deletion or permanent restoration before it ends incurs a prorated archive charge for the remaining days, rounded to the nearest hour. Temporary restoration before day 90 does not trigger that remainder charge.

Restoration has a separate retrieval charge. During a temporary restore, both the standard snapshot and its archive copy accrue storage charges. A permanent restore removes the archive copy and leaves standard storage billing, with any applicable minimum-period remainder still relevant. These conditions are separate from the fictional stable-storage arithmetic.

An archived EBS snapshot must return to standard before it can be used like a standard snapshot. Ask how the offer's access purpose and expected restores affect both its storage intervals and other charges. The related S3 minimum-duration and archive-access guides develop the duration and read-window questions for object storage; their storage-class terms remain separate from these EBS conditions.

References: [ESA2][ESA4]

Ask for the retained states and both resulting tier quantities

A comparable offer identifies the captured states that must remain, their retention and access purposes, the candidate's full archive quantity, and the standard quantity that survives the proposed placement. Its quantity evidence needs a date and the same retained population as the proposal. A recent increment or a per-snapshot cost label alone leaves the family comparison unresolved.

Apply the actual applicable rates and billing periods to those quantities, then include minimum-duration exposure, retrieval and any simultaneous restored-standard/archive intervals. If a quantity or expected access interval is unknown, leave the cost conclusion open rather than treating it as zero. The related stopped-compute guide covers the environment's other retained-resource billing clocks.

The storage comparison also leaves application contents and recovery evidence to their own review. The Training Checkpoint or Storage Snapshot guide explains why a stored copy alone does not establish the required training state. The EBS volume initialization guide addresses block readiness after volume creation. Neither a lower modeled charge nor a full archive copy proves application consistency, recovery or compliance.

References: [ESA3][ESA4]

Scope any physical storage connections separately

If the wider AI infrastructure project also involves physical connections between compute and storage equipment, Leviathan's Structured Cabling & Fiber Installation service and its project inquiry can address separately agreed cabling work. Share a nonconfidential equipment summary, approved endpoints, supplied assemblies, site constraints and required connection records. Cloud account administration, storage-tier selection and application recovery remain with the appointed platform, storage and application owners.

References: [L1]