What is snapshot in AWS - and how incremental saves you money

A snapshot is a point-in-time copy of your data — but on Amazon EBS, only the very first one is a full copy. Every snapshot after that is incremental: it only stores the blocks that changed since your last snapshot, and Amazon Web Services (AWS, the cloud provider that rents out the servers and storage behind a huge chunk of the internet) only bills you for the size of what got saved, not the size of the whole disk. That's the whole trick behind the "saves you money" part of the title, and it's also the part almost nobody explains correctly — including some of AWS's own support engineers, going by how many billing tickets get opened over it.

Jake found out the hard way that "incremental" doesn't mean "cheap no matter what." He runs a small phone repair and resale shop, and last year he set up nightly snapshots on the EC2 instance that runs his inventory and repair-ticket system. Six months later the AWS bill for snapshot storage was bigger than the bill for the EC2 instance itself. Nothing was broken. He just didn't understand what he was actually paying for — and once Ethan walked him through it, the fix took about ten minutes.

What an EBS snapshot actually is

An Amazon EBS (Elastic Block Store — the virtual hard drive AWS attaches to your EC2 servers) snapshot is a backup of the data on that virtual hard drive at one specific moment. AWS's own documentation is blunt about the responsibility split here: AWS does not automatically back up your EBS volumes. If you want a copy of your data that survives a deleted volume, a bad `rm -rf`, or a corrupted filesystem, you have to take a snapshot yourself, or set up something that takes them for you.

The snapshot itself lives in Amazon S3 (Simple Storage Service — Amazon's object storage system, the same tech that hosts a huge share of the web's images and files), but you'll never see it in your S3 console. AWS keeps it in a bucket you can't browse, and you can only create, view, or delete it through the EC2 console or the EC2 API. That's a common point of confusion: people go looking for their snapshots in S3 and come away thinking something's wrong, when actually it's just walled off by design.

Once you have a snapshot, you can create a brand-new volume from it at any time — in the same Availability Zone or a different one, in the same AWS Region or a different one (after copying it there), even on a different AWS account if it's shared with you. The new volume comes out as an exact replica of the source volume at the moment the snapshot was taken. That's the "point-in-time copy" part of the definition, and it's also what makes snapshots the backbone of Amazon Machine Images (AMIs) — the templates EC2 uses to launch new servers — since an AMI is really just a snapshot with launch instructions attached.

Full snapshots vs. incremental snapshots

This is the part of the title that does the heavy lifting, so it's worth being precise about it. AWS's own EBS documentation draws the line this way:

• The first snapshot you ever take of a volume is always a full snapshot. It copies every block that has data written to it — not the whole provisioned size of the volume, just the parts that actually hold data.
• Every snapshot after that is an incremental snapshot. It only includes the blocks that changed or were newly written since the previous snapshot completed.

Here's the sentence that trips people up the most, because it's genuinely counterintuitive: the size — and the storage cost — of a full snapshot is set by how much data is actually on the volume, not by how big you provisioned the volume to be. If you provision a 200 GB volume but only 50 GB of it has ever had data written to it, your first snapshot is 50 GB, and that's what you're billed for. AWS calls out this exact example in its own documentation, because it's the single most common source of "wait, why is my snapshot smaller than my disk?" support questions.

AWS's how-it-works page walks through a second example that makes the incremental behavior concrete. Say you have a 200 GB volume holding 50 GB of data. Your first snapshot is a full snapshot, 50 GB, billed as 50 GB. Now you change 20 GB of existing data and add another 10 GB of new data before your next snapshot. That second snapshot — the incremental one — is only 30 GB, and that's the only additional amount you're billed for. The unchanged 20 GB from the first snapshot isn't copied again; it's referenced.

Snapshot	What it captures	Billed size
Snap A (full)	All 50 GB of data on the volume at that moment	50 GB
Snap B (incremental)	20 GB changed + 10 GB newly added since Snap A	30 GB

Ethan puts it this way when Jake asks why this matters: "Every snapshot after the first one is basically a diff, not a copy. You're not paying to store your whole disk over and over — you're paying to store what actually moved." That's also why a nightly snapshot schedule on a mostly-static disk (say, a read-heavy database that gets updated once a week) can end up almost free after the first one, while the same schedule on a disk with constant writes — logs, a busy database, a build server — adds up fast, because there's more "diff" every single night.

The real cost math, worked out in dollars

AWS bills snapshot storage by the amount of space your data actually consumes in S3, per gigabyte, per month — the same "GB-month" logic used for EBS volumes themselves. AWS's own pricing page runs an example using a rate of $0.05 per GB-month for standard-tier snapshot storage in one of its worked calculations. Rates vary by AWS Region, so treat that $0.05 figure as an illustration of the math, not a universal price — always check the current rate for your own Region on the official EBS pricing page before budgeting.

Let's use it anyway, because the arithmetic is the whole point. Say Jake's shop server has a 100 GB volume with 40 GB of data on it.

1. Night 1 (full snapshot): 40 GB is copied and billed. At $0.05/GB-month, that's $2.00/month if it's the only snapshot kept.
2. Night 2 (incremental): Suppose 1.5 GB of repair-ticket records and inventory data changed that day. Only that 1.5 GB is newly billed — an extra $0.075/month, not another $2.00.
3. After 30 nights of keeping every snapshot, with roughly 1.5 GB of daily churn, total billed snapshot storage is approximately 40 GB (full) + 30 × 1.5 GB (increments) = 85 GB — about $4.25/month, not 30 × $2.00 = $60/month.

That gap — $4.25 versus $60 — is the entire "incremental saves you money" story in one example. A full snapshot every night would mean paying for the same 40 GB of unchanged data thirty separate times. An incremental snapshot means you only ever pay once for data that isn't moving.

The size of that gap depends entirely on how much churn your volume actually has, so it's worth seeing the same 100 GB / 40 GB starting point at a few different churn rates side by side, still using that $0.05/GB-month illustration rate over a 30-day month:

Daily churn	Total billed after 30 nights (incremental)	What a full snapshot every night would cost
Light (1.5 GB/day — Jake's shop server)	~$4.25/month	~$60/month
Moderate (8 GB/day — an active application server)	~$14/month	~$60/month
Heavy (35 GB/day — a busy transactional database)	~$54.50/month	~$60/month

Notice how the advantage of incremental snapshots shrinks as churn rises — at light churn you're paying roughly 7% of what full-every-night would cost, but at heavy churn you're paying more than 90% of it. Incremental snapshots aren't magic; they're just billing you for what actually changed, and on a volume where almost everything changes daily, that's most of the volume every single time.

Why deleting an old snapshot might not lower your bill

Here's the counterintuitive part that trips up people who think they understand incremental snapshots. Because every snapshot after the first one is really a chain of references back to earlier snapshots, deleting one snapshot in the middle of that chain doesn't necessarily free up the storage you'd expect.

AWS's own documentation is explicit about this: when you delete a snapshot, only the data that's referenced exclusively by that snapshot is actually removed. Any block that's still referenced by a later snapshot gets kept — and reassigned, in terms of billing, to whichever snapshot still needs it. AWS walks through a three-step example that makes this concrete:

• State 1: Volume has 10 GiB of data. Snap A is the first (full) snapshot — 10 GiB billed.
• State 2: 4 GiB changed. Snap B (incremental) stores that 4 GiB and references the unchanged 6 GiB already in Snap A. Total billed across both snapshots: 14 GiB.
• State 3: Snap A is deleted. The 4 GiB of data that was unique to Snap A disappears. But the 6 GiB that Snap B still references gets reassigned to Snap B and stays billed. Total billed storage after deleting Snap A: still 10 GiB, not zero.

Deleting your very oldest snapshot, thinking it'll free up "all of it," typically frees up only the sliver of data nothing newer needs anymore. If you're trying to actually reduce your bill, deleting snapshots one at a time from the oldest isn't the lever people assume it is — you usually need to delete the whole chain, or lean on a retention policy instead of manual cleanup. More on that shortly.

Snapshot vs. backup vs. AMI — the terms people mix up

"Snapshot" gets used loosely enough in everyday conversation that it's worth pinning down where it actually sits next to the words people confuse it with.

Snapshot vs. backup

On AWS, a snapshot is a form of backup — specifically, an incremental, block-level backup of an EBS volume. Where people get confused is with on-premises IT vocabulary, where "snapshot" sometimes refers to a lightweight, storage-array-native copy that's tied to the same physical hardware as the source, while "backup" means something copied off to different media entirely. On AWS, that distinction mostly collapses: an EBS snapshot is stored in S3, replicated across every Availability Zone in the Region automatically, and can be copied to another Region or account — which covers most of what people mean when they say "real backup," not just a local copy.

Snapshot vs. AMI

An AMI (Amazon Machine Image) is what EC2 uses as a template to launch a new server. Under the hood, an EBS-backed AMI is built on top of one or more snapshots, plus metadata about the instance's launch configuration (architecture, root device, block device mappings). You can't delete a snapshot that's the root device for a registered AMI — AWS blocks it outright, even if the AMI is deprecated or disabled — until you deregister the AMI first.

Snapshot vs. differential backup

This one's a general backup-industry term, not an AWS-specific one, but it's worth explaining because people bring the vocabulary with them. A differential backup captures everything that's changed since the last full backup — so each differential grows larger over time until the next full backup resets it. An incremental backup (which is what EBS snapshots are) only captures what changed since the immediately preceding backup, whatever that was. EBS snapshots follow the incremental model, not the differential one — which is exactly why the chain-deletion behavior above works the way it does.

Term	What it measures against	How EBS snapshots fit
Full backup	Nothing — copies everything	Only the very first EBS snapshot of a volume
Differential backup	The last full backup	Not how EBS snapshots work
Incremental backup	The immediately preceding backup	Every EBS snapshot after the first one

The edge case: incremental snapshots across different volumes

Most people picture incremental snapshots as something that only happens on one volume, over time. AWS documentation covers a less obvious case: a snapshot can be incremental relative to a snapshot of a different volume, as long as that second volume was originally created from the first snapshot.

Say Vol 1 has 10 GiB of data, and Snap A is its first (full) snapshot. If you then create Vol 2 from Snap A, Vol 2 starts out as an exact copy of Vol 1. Add 4 GiB of new data to Vol 2, then take Snap B of Vol 2 — Snap B is incremental relative to Snap A, even though it came from an entirely different volume, and only the 4 GiB of new data gets billed. This matters for anyone spinning up multiple environments (staging copied from production, say) and taking their own snapshot schedule on each: you're not necessarily starting from a full-price snapshot just because it's a "new" volume.

There's a catch, and it's an important one for cross-account and cross-key setups: this only works cleanly if you own both the source volume and the source snapshot, and if the new volume is encrypted with the same KMS (Key Management Service — AWS's encryption key management system) key as the original. If the snapshot was shared to you from another account, or the new volume uses a different encryption key, the next snapshot you take is a full snapshot again — full price, no partial credit for the unchanged data.

Actually cutting your snapshot bill

Understanding incremental billing is half the picture. The other half is not letting snapshots pile up indefinitely, which is the actual reason most people's snapshot bills grow — not the incremental math failing them, but nobody ever deleting anything.

The tool AWS provides for this is Amazon Data Lifecycle Manager (DLM) — a free capability of EBS that automates the creation, retention, and deletion of both EBS snapshots and EBS-backed AMIs on a schedule you define. It exists specifically so you don't have to remember to prune old backups by hand.

1. Open the Amazon EC2 console and find Data Lifecycle Manager under Elastic Block Store in the left navigation.
2. Create a lifecycle policy targeting the volumes or instances you want covered — by resource ID or by tag, so new servers can be picked up automatically if you tag consistently.
3. Set a schedule (for example, once daily) and a retention count or retention period (for example, keep the last 14 daily snapshots).
4. Let DLM run. It creates each new snapshot on schedule and automatically deletes the ones that fall outside your retention window — no manual cleanup, no forgotten snapshots quietly racking up storage charges for months.

Ethan set Jake's policy to run at 2 a.m. instead of right at midnight, for a reason that has nothing to do with AWS and everything to do with Jake's actual workload: his point-of-sale system runs its nightly inventory reconciliation job right at midnight, and taking a snapshot mid-reconciliation meant occasionally capturing a half-finished write. Waiting two hours dodges that window entirely, and it's the kind of thing no AWS documentation is going to tell you, because it depends on what's actually running on your server, not on how EBS works.

Amazon Data Lifecycle Manager can't manage snapshots or AMIs that were created by anything other than itself — so if you've been taking snapshots manually or through a third-party tool, DLM won't retroactively clean those up. You'll need to handle that first batch yourself, then let DLM take over going forward. It also can't automate instance-store-backed AMIs, only EBS-backed ones.

Fast Snapshot Restore: a feature that adds cost, not saves it

By default, a volume created from a snapshot may need to "warm up" a bit — the first time each block is read, it has to be fetched from S3 in the background. Fast Snapshot Restore (FSR) removes that lag, giving you full performance from the moment the volume is created. It's genuinely useful for anything time-sensitive, like disaster recovery drills or scaling up new instances quickly.

It is not free, and it's billed completely differently from snapshot storage. FSR is charged in DSU-hours (Data Services Unit-hours) — for every snapshot, in every Availability Zone where you enable it, billed per minute with a one-hour minimum. AWS's own pricing example uses $0.75 per DSU-hour: enable FSR on one snapshot across three Availability Zones for 90 minutes, and you're billed as 1 snapshot × 3 AZs × 1.5 DSU-hours, or $3.375 — and that clock keeps running until you explicitly disable it, not until you stop using the volume.

Archiving old snapshots instead of deleting them

Sometimes you don't want to delete an old snapshot — compliance rules or audit requirements might mean you have to keep something for years — but you also don't want to pay standard-tier rates for something you'll probably never touch. That's what the EBS Snapshots Archive tier is for.

There's a wrinkle worth knowing about before you archive anything: when you archive an incremental snapshot, AWS converts it to a full snapshot first — meaning it now includes every block that was written to the volume at the time it was originally taken, not just the diff it stored before. That converted, full-sized snapshot is what actually moves into the archive tier, and it's billed at $0.0125 per GB-month there, versus roughly $0.05 per GB-month for standard-tier storage in AWS's own pricing example. Archiving a 100 GiB snapshot, for instance, runs about $1.25/month in the archive tier under that example rate.

The catch: there's a 90-day minimum retention period once something's archived. Delete it, or permanently restore it, before those 90 days are up, and you're billed a pro-rated charge for the remaining days at the archive rate — so archiving something you might need back next week isn't the move; archiving something you're required to keep for a year and genuinely won't touch is exactly the intended use case. Restoring a snapshot from archive back to standard tier also costs a one-time $0.03 per GB, on top of whatever it costs to store it in standard tier again while it's restored.

Recycle Bin: protection against your own delete button

If someone on your team fat-fingers a delete-snapshot command, or a lifecycle policy is configured too aggressively and prunes something you actually needed, Recycle Bin is the safety net. You set up a retention rule — by resource type and tag — and any matching EBS volume, snapshot, or EBS-backed AMI that gets deleted is held in the Recycle Bin for a period you choose, instead of being wiped immediately.

There's no extra charge for using Recycle Bin or retention rules themselves. Snapshots sitting in the Recycle Bin are billed at the exact same rate as snapshots anywhere else in your account — you're just paying to keep the data around a little longer as insurance, the same as you would if you hadn't deleted it. If the snapshot happens to be an archived one, Recycle Bin billing follows the archive rate, and the 90-day minimum archive period still applies even while it's sitting in the bin.

"I can't delete this snapshot" — the common blockers

A handful of situations will stop a snapshot deletion cold, and each has a different fix, per AWS's own documentation:

• It's the root device snapshot of a registered AMI. This applies even if the AMI is deprecated or disabled. Deregister the AMI first, then delete the snapshot.
• It's managed by AWS Backup. You can't delete a snapshot AWS Backup created directly through EC2 — you have to delete the corresponding recovery point from within AWS Backup itself.
• It's associated with a disabled AMI. In the console, you need to select the "Disabled images" filter on the AMIs screen just to see it before you can act on it.
• It's shared with you, not owned by you. You can't delete snapshots someone else shared with your account. If you own a shared snapshot and delete it, everyone it was shared with immediately loses access.
• It's still in progress. You can request deletion of a snapshot that's still being created, but the snapshot has to finish first — which, on a large volume, might take a while.

Before you share a snapshot: the privacy angle

Snapshots can be shared publicly, which sounds like a niche feature until you remember that a snapshot is a complete copy of whatever was on that disk — customer records, credentials left in config files, anything. AWS gives you an account-level and Region-level safety switch called block public access for snapshots, which comes in two modes: "block all sharing," which also retroactively hides anything already shared publicly, and "block new sharing," which stops new public shares but leaves existing ones alone. It costs nothing to enable.

One limit worth flagging: this setting does not stop public sharing of EBS-backed AMIs. If someone publicly shares an AMI, anyone with access to it can create volumes from the snapshots underneath it, block public access for snapshots or not. If AMIs are part of your workflow, you need the separate block public access setting for AMIs too — they don't cover each other.

The next task: copying a snapshot to another Region

Once someone understands incremental snapshots, the next question that comes up thirty seconds later is almost always about disaster recovery: what happens if the whole AWS Region goes down, not just one server? Snapshot data is automatically replicated across every Availability Zone within its own Region, but it doesn't automatically leave that Region. If you want protection against a Region-wide event, you copy the snapshot to a different Region yourself.

Copying a snapshot across Regions is billed for the data transferred, based on the amount of data in the snapshot — and once the copy lands in the destination Region, it's billed there at the standard snapshot storage rate for that Region going forward, as its own independent snapshot. That's worth knowing before you set up an automated cross-Region copy schedule for every nightly snapshot: you're not just paying once, you're paying transfer costs on every copy, plus ongoing storage in two Regions instead of one.

AWS also offers a Time-based Copy option for snapshots, which lets you specify how long a cross-Region (or cross-account) copy job should take to complete, rather than leaving it to run at whatever speed it happens to get. That predictability comes at its own per-GB rate, separate from ordinary snapshot storage, and it scales with how tight a completion window you ask for — a faster guaranteed copy costs more per gigabyte than a looser one. It's aimed at people who need copies to land somewhere by a specific deadline (say, a compliance window, or a database that needs its DR copy ready before a specific cutover time) rather than people just want an eventual backup somewhere else.

Third-party backup tools — when they're worth it, and when they're not

A whole category of backup vendors — the kind of tools independent software vendors build specifically on top of the EBS direct APIs mentioned earlier — sell dashboards, cross-account policy management, application-consistent snapshots for databases, and unified reporting across dozens or hundreds of accounts. None of them change the underlying incremental billing model described above; they're all still paying AWS the same per-GB snapshot storage rate underneath whatever they charge on top.

Where they genuinely earn their subscription fee: managing snapshot policy across many AWS accounts at once (DLM and AWS Backup are both single-account-first tools, even though AWS Backup can be extended across an organization with more setup), coordinating snapshots with application-level consistency — quiescing a database before the snapshot fires so you don't restore into a half-written transaction — and giving non-technical stakeholders a reporting view without console access.

Where they're not worth bothering with: a single EC2 instance, or a small handful of them, with one team managing all the AWS accounts involved. That's Jake's situation exactly — DLM already does everything he needs, at no cost beyond the snapshot storage itself, and a third-party tool would just be another subscription and another login for a problem that's already solved.

Data Lifecycle Manager vs. AWS Backup vs. doing it by hand

People land on three different approaches to keeping snapshots current, and each fits a different situation.

Approach	Best for	Watch out for
Manual snapshots	One-off backups before a risky change	Nobody remembers to delete them later
Data Lifecycle Manager	Recurring EBS-only schedules with automatic pruning, at no extra cost	Only manages what it created; EBS-backed AMIs only, not instance-store
AWS Backup	Centralized backup policy across multiple AWS services, not just EBS	Deletion has to happen inside AWS Backup, not through the EC2 console

Ethan's take: "If all you're protecting is EBS volumes, DLM is free and does the job — there's no reason to reach for anything heavier. AWS Backup earns its place once you're also protecting RDS databases, DynamoDB tables, or anything outside of just EC2 and EBS, and you want one policy that covers all of it instead of juggling several tools." Jake, whose whole setup is one EC2 instance and its attached volume, went with DLM. A business running a mixed fleet of databases and file systems would likely find AWS Backup worth the extra layer.

Multi-volume snapshots and instances with several disks

An EC2 instance with more than one attached volume — a root volume plus a separate data volume, say — can have all of its volumes snapshotted together as a set, tagged so you can find and manage them as a group. It's worth knowing that multi-volume snapshots don't behave as one atomic unit when it comes to deletion: nothing stops you from deleting an individual snapshot out of that set. If you delete one while it's still in the "pending" state, only that one snapshot is removed — the rest of the set keeps completing normally. If you're relying on a multi-volume set being complete for a restore, double-check that every snapshot in the set actually finished before you rely on it.

Each incremental snapshot in that scenario is still calculated per-volume — a busy root volume and a mostly-static data volume attached to the same instance will produce very different incremental sizes from the same nightly schedule, even though they're snapshotted together.

For the power user: reading snapshot data directly

If you've read this far and you're building tooling rather than just backing up one server, AWS exposes the EBS direct APIs specifically for this. They let you list which blocks changed between two snapshots (ListChangedBlocks), list all the blocks in a single snapshot (ListSnapshotBlocks), and read or write individual 512 KiB blocks directly (GetSnapshotBlock, PutSnapshotBlock) — all without spinning up an EC2 instance just to diff two volumes. AWS built these specifically for software vendors offering their own backup products on top of EBS, so third-party backup tools can efficiently track incremental changes.

These are billed separately from snapshot storage — small per-request or per-unit charges (AWS's pricing page uses example rates like $0.0006 per thousand ListSnapshotBlocks requests and $0.003–$0.006 per thousand SnapshotAPIUnits for reads and writes) — so they're worth knowing about if you're evaluating a third-party backup tool and want to understand where its own bill comes from, even if you never call these APIs yourself.

There's also a related feature worth flagging for anyone standing up a lot of volumes from the same snapshot at once: Provisioned Rate for Volume Initialization. Normally, a new volume created from a snapshot fetches each block from S3 lazily, the first time something actually reads it — which is fine for one volume, but can mean a noticeable warm-up period if you're launching a hundred instances from the same AMI at once and every one of them wants full performance immediately. This feature lets you pay to guarantee a specific initialization rate instead of waiting on the lazy-fetch default, billed against the snapshot's full size and the rate you request — independent of, and on top of, whatever the resulting volumes themselves cost.

Does the OS on the volume change any of this?

No — the incremental billing model described above is a property of the EBS volume, not of what's installed on it. It works identically whether the attached instance is running Windows Server, a Linux distribution, or something like Kali. What does change is how much data churns day to day, which is really what drives your snapshot cost. A Windows Server instance running Windows Update and antivirus definition refreshes will typically show more daily block churn than an idle Linux box doing nothing but serving static files — and that churn, not the OS itself, is what shows up as extra billed gigabytes in your next incremental snapshot.

The same logic applies to swap files, temp directories, and log rotation — none of it is EBS-specific, but all of it adds up to blocks that look "changed" to a snapshot even when nothing meaningful actually happened. If your incremental snapshots seem larger than you'd expect for how little the application itself changed, it's worth checking whether verbose logging, a chatty swap file, or a build pipeline's temp directory is sitting on the same volume as your actual data. Moving that kind of churn-heavy, disposable data to its own separate volume — one you don't bother snapshotting at all — is a small architectural change that can meaningfully shrink what you pay for backing up the volume that actually matters.

Frequently asked questions

Is the first snapshot always the most expensive one?

Usually, yes, since it's the only one that copies every block of existing data rather than just the changes. The exception is a volume created from an existing snapshot with the same owner and encryption key — its first snapshot can be incremental relative to that source snapshot instead of starting over as a full copy.

Does a bigger provisioned volume mean a bigger snapshot bill?

No. Snapshot size and cost track how much data is actually written to the volume, not the provisioned size. A 1 TB volume with 20 GB of data on it produces a roughly 20 GB first snapshot, not a 1 TB one.

If I delete a volume, do its snapshots disappear too?

No. Snapshots and the volumes they came from are independent resources once the snapshot completes. Deleting a volume has no effect on any snapshots taken from it, and deleting a snapshot has no effect on the volume.

Why didn't my bill drop after I deleted a bunch of old snapshots?

Because incremental snapshots reference each other, deleting an older snapshot only frees the data that no newer snapshot still needs. Data still referenced by a later snapshot stays billed, just reassigned to that later snapshot.

Can I access a snapshot's files directly in S3?

No. Snapshots are stored in S3 buckets you can't access through the S3 console or S3 API. You can only work with them through the EC2 console, the EC2 API, or the EBS direct APIs.

What's the difference between an incremental snapshot and a differential backup?

An incremental backup only stores what changed since the immediately preceding backup. A differential backup stores everything that's changed since the last full backup, growing larger with each one until the next full backup resets it. EBS snapshots follow the incremental model.

Do I need to manually clean up old snapshots?

Not if you set up Amazon Data Lifecycle Manager, which automates creation and deletion on a schedule and retention count you define, at no additional cost. Without it — or an equivalent tool like AWS Backup — old snapshots just accumulate until someone remembers to remove them.

Can Amazon Data Lifecycle Manager clean up snapshots I created manually?

No. DLM can only manage snapshots and AMIs that it created itself. Anything you or another tool created has to be cleaned up separately before DLM takes over going forward.

Why can't I delete this snapshot?

The most common reasons: it's the root-device snapshot of a registered AMI (deregister the AMI first), it's managed by AWS Backup (delete the recovery point there instead), it's associated with a disabled AMI, or it's a snapshot shared with you rather than owned by you.

What happens if I delete a shared snapshot I own?

Every account it was shared with immediately loses access to it. There's no separate "unshare" step required — deletion removes access for everyone at once.

Is archiving a snapshot the same as deleting it?

No. Archiving moves a full copy of the snapshot into the EBS Snapshots Archive storage tier at a lower rate, but it still exists and can be restored later. It's meant for snapshots you're required to retain but rarely need, not ones you're done with entirely.

What's the minimum time I have to keep an archived snapshot?

90 days. Deleting or permanently restoring it earlier means you're billed a pro-rated charge for the remaining days at the archive storage rate.

Does Fast Snapshot Restore save me money on restores?

No — it's a performance feature, not a cost-saving one. It removes the initial read latency when creating a volume from a snapshot, but it's billed separately, per snapshot and per Availability Zone, with a one-hour minimum each time you enable it.

Can someone else see my snapshot if I don't share it?

No, snapshots are private by default. Block public access for snapshots is an extra safety switch on top of that default, useful mainly for preventing accidental public sharing by anyone with permissions in your account — it doesn't change anything about snapshots nobody has tried to share.

Does Recycle Bin cost extra to use?

No, there's no additional charge for Recycle Bin or its retention rules. Snapshots sitting in the Recycle Bin are billed at the same rate as any other snapshot in your account — you're only paying to keep the data around for the retention window, same as if it hadn't been deleted.

Does copying a snapshot to another Region cost extra?

Yes. Copying a snapshot across Regions is charged for the data transferred, and once it lands in the destination Region it's billed there as its own snapshot at that Region's standard storage rate — on top of what you're already paying to keep the original in the source Region.

Revision note. Written September 2026. AWS pricing varies by Region and changes over time, so treat the dollar figures here as worked examples rather than a quote for your account — check the current EBS pricing page before budgeting. If you've been staring at a snapshot bill that doesn't match what you expected, you're not missing something obvious; the incremental model has a few genuinely non-intuitive corners, and now you know where they are. Happy learning.!