What an EBS snapshot actually costs (2026)

Two things about EBS snapshot billing are counter-intuitive and both cost money. Deleting a snapshot may free nothing, and moving one to the cheap archive tier can multiply what it costs, because archiving converts an incremental snapshot into a full one.

How much does an EBS snapshot cost?

Three rates, all stated in prose on the AWS snapshot archive billing page:

AWS's own worked examples: "if you archive a 100 GiB snapshot, you are billed $1.25 (100 GiB * $0.0125) per month", and "if you restore a 100 GiB snapshot from the archive tier, you are billed one time for $3 (100 GiB * $0.03)". Once restored, "the snapshot is billed at the standard rate for snapshots of $0.05 per GB-month."

The free tier is one gigabyte. The EBS pricing page gives "30 GB of storage, 2 million I/Os, and 1 GB of snapshot storage". It is not a meaningful allowance for anything real.

Do EBS snapshots cost money if you never restore them?

Yes, every month, for as long as they exist, and the amount is not the volume size. The EBS snapshot documentation defines a snapshot as "an incremental backup, which means that we save only the blocks on the volume that have changed since the most recent snapshot."

So a nightly snapshot of a 500 GB volume where 2 GB changes a day is not 500 GB a night. The first is close to the used size, and each one after is close to the delta. Which is why snapshot spend on an account grows slowly and invisibly, then turns out to be five figures.

Why doesn't deleting a snapshot reduce your bill?

Because the blocks are shared. From the same page: "Because snapshots are incremental, deleting a snapshot might not reduce your data storage costs. Data referenced exclusively by a snapshot is removed when that snapshot is deleted, but data referenced by other snapshots is preserved."

A chain of 30 nightly snapshots shares most of its blocks with the first one. Delete snapshots 2 through 29 and you free only the blocks nothing else points at, which for a slow-changing volume is a small fraction of the total. Delete the oldest and its exclusively-referenced blocks are inherited by the next snapshot rather than released.

The practical consequence is that snapshot cleanup gives unpredictable savings, and any plan that assumes "delete half the snapshots, halve the cost" is wrong before it starts. Reducing retention depth releases less than reducing the number of distinct volumes under backup.

The other reason deletion frees nothing is AMIs. AWS's cost management team names it directly in Optimize and save on "other" services: "when you deregister your AMI, but did not opt to delete the snapshot, that snapshot will persist and cause full storage charge". Deregistering an AMI is not deleting its backing snapshots, and nothing in the console says so at the time.

When does the archive tier cost more than the standard tier?

Whenever the snapshot is part of a chain. This is the trap, and AWS states the mechanism without drawing the conclusion.

From the snapshot archive documentation: "When you archive a snapshot, the incremental snapshot is converted to a full snapshot ... Full snapshots include all of the blocks that were written to the volume at the time when the snapshot was created."

The archive rate is four times cheaper per GB. A conversion from incremental to full multiplies the billed size by however many times larger the volume is than the delta. Below a factor of four, archiving saves money. Above it, the bill goes up.

AWS's own use cases confirm which case is intended: "Archiving the only snapshot of a volume, such as end-of-project snapshots", and "Archiving full, point-in-time incremental snapshots for compliance reasons". Archive is for the last snapshot of something you are finished with, not for thinning a backup rotation. And the documentation states the payback window: archive is "up to 75 percent lower snapshot storage costs for snapshots that you plan to store for 90 days or longer and that you rarely need to access."

The 90-day minimum, and how it bills

"The minimum archive period is 90 days. If you delete or permanently restore an archived snapshot before the minimum archive period of 90 days, you are billed a pro-rated charge equal to the archive tier storage charge for the remaining days, rounded to the nearest hour."

Two carve-outs worth knowing before you plan around it. A temporary restore does not trigger the early-delete charge: "Temporarily restoring an archived snapshot before the minimum archive period of 90 days does not incur this charge." But during a temporary restore you pay twice, because "a copy of the snapshot remains in the archive tier" and "You are billed for both the snapshot in the standard tier and the snapshot copy in the archive tier for the duration of the temporary restore period."

And the minimum survives interruption. Delete a snapshot mid-archive and you still owe 90 days on the part already moved. AWS's example: "if you archive a 100 GiB snapshot, and you delete the snapshot after only 40 GiB has been archived, you are billed $1.50 for the minimum archive period of 90 days for the 40 GiB that has already been archived". Delete one mid-restore and "you are billed for the snapshot restore for the full size of the snapshot".

Recycle Bin does not pause any of it. "Archived snapshots are billed at the rate for archived snapshots while they are in the Recycle Bin", and a retention rule that deletes one before 90 days incurs the same pro-rated charge. This is the same shape of rule as the 30-day minimum on S3 Standard-IA: a cheap tier that is only cheap if you leave things in it.

How do you find snapshot cost in the CUR?

The archive documentation names the usage types, which is unusually helpful and means you do not have to guess at string matches:

A non-zero SnapshotArchiveEarlyDelete line is a lifecycle policy fighting the 90-day minimum, and it will keep billing every month until somebody changes the policy. It is the single most actionable string in this post.

AWS also confirms the join key: "Archived snapshots appear in the AWS Cost and Usage Report with their same resource ID and Amazon Resource Name (ARN)", so snapshot cost attributes to a snapshot ID as long as resource-level granularity is on. That is the INCLUDE_RESOURCES table configuration, and without it every snapshot in the account collapses to one row.

SELECT line_item_usage_type,
       line_item_resource_id,
       SUM(line_item_unblended_cost) AS cost
FROM   cur
WHERE  billing_period = '2026-07'
  AND  line_item_usage_type LIKE '%Snapshot%'
GROUP  BY 1, 2
ORDER  BY cost DESC
LIMIT  50;

If line_item_resource_id comes back empty, that configuration is off. Setting up the table itself is in querying your CUR in Athena with no crawler, and choosing which cost column to sum is in amortized versus unblended cost.

What else bills against a snapshot?

Fast Snapshot Restore is the one that surprises people, because it is billed per Availability Zone and it does not stop on its own. The EBS pricing page: "FSR is charged in Data Services Unit-Hours (DSU-Hours) for each snapshot and each Availability Zone in which it is enabled ... You will continue to incur charges on an FSR-enabled snapshot until you disable it." Enabled across three zones, it bills three times, indefinitely, whether or not you restore anything.

Two quotas also shape what is possible. From the archive documentation, the defaults are 25 archived snapshots per volume, 25 concurrent in-progress archives per account, and 5 concurrent in-progress restores per account. That last one is a disaster-recovery constraint rather than a cost one: a recovery plan that assumes twenty simultaneous restores from archive will queue.

None of this appears in Cost Optimization Hub, which recommends on EBS volumes but not on snapshots. And all of it lands in the EC2 - Other bucket in Cost Explorer, under a service that did not create it.