Every SAA-C03 study guide tells you that EBS snapshots are “incremental, stored in S3, and can be copied across Regions”. That sentence is true and it is worth maybe one question. The exam actually spends its EBS-snapshot questions on the consequences of that model: why deleting a snapshot does not save as much as you expected, why a volume restored from a snapshot is slow for the first hour, which features make it fast and what they cost, how to keep a snapshot from being deleted by a privileged user, when a copy is full instead of incremental, and why an encrypted snapshot cannot be shared with another account. Our EBS, EFS, S3 and FSx storage guide covers volume types and the single-AZ rule; this article is entirely about the snapshot side.
Read it once for understanding, then use the scenario drill near the end to test whether the rules stuck.
How Incremental Snapshots Actually Work
A snapshot is a point-in-time copy of the blocks written to an EBS volume, stored in Amazon S3 in buckets you cannot see or access directly. Snapshot data is replicated across all Availability Zones in the Region, which is why you can restore a snapshot into any AZ even though the source volume lived in one.
The first snapshot of a volume is full: it contains every written block. Every later snapshot of the same volume is incremental: it stores only the blocks that changed or were added since the previous snapshot, and references the unchanged blocks already held by earlier snapshots. Two numbers matter and the exam likes to swap them:
- Snapshot size is driven by written data, not volume size. A 200 GiB volume with 50 GiB of data produces a 50 GiB full snapshot, and you are billed for 50 GiB.
- The next snapshot stores only the delta. Change 20 GiB and add 10 GiB, and the second snapshot is 30 GiB.
The AWS documentation example is worth memorising because it reappears in questions with the numbers changed: a 15 GiB volume holds 10 GiB at Snap A (full, 10 GiB stored), 4 GiB changed by Snap B (4 GiB stored, 6 GiB referenced from A), and 2 GiB added by Snap C (2 GiB stored). Three snapshots, 16 GiB of total storage.
What deletion really removes
This is the rule that trips people up. When you delete a snapshot, only the data referenced exclusively by that snapshot is removed. Blocks still referenced by a later snapshot are kept and their cost moves to that later snapshot. In the example, delete Snap A and the 6 GiB that Snap B references stays (now charged to B) while A’s 4 GiB of unique data goes. Storage drops from 14 GiB to 10 GiB, not to 4 GiB. The practical consequences:
- You only ever need the most recent snapshot to restore a volume; deleting earlier ones never breaks later ones.
- Deleting old snapshots may not reduce cost much, because most of their blocks are shared.
- You cannot delete a snapshot that backs the root device of a registered AMI (even a deprecated or disabled one) until you deregister the AMI, nor a snapshot managed by AWS Backup, nor a snapshot shared with you.
Consistency and multi-volume snapshots
A snapshot captures data at the moment the API call is made; writes after that point are not included, even though the snapshot sits in pending for a while. The volume stays usable throughout. Data cached in memory and not yet flushed is not captured, which is why application-consistent backups need you to pause writes, flush, or use the Data Lifecycle Manager pre and post scripts described later. Multi-volume snapshots (one API call for every volume attached to an instance) are crash-consistent across the set, and are the answer to “back up a database whose data and logs sit on different volumes consistently”.
Restoring Is Lazy: Initialization and How to Fix It
A volume created from a snapshot is available immediately, but its blocks are downloaded from S3 on first access (lazy loading). Until every block has been pulled, I/O to untouched blocks has extra latency and the volume can run well below its provisioned performance. Empty volumes do not have this problem. Three fixes exist, and the exam expects you to pick between them on cost and urgency:
| Approach | What it does | Cost | When it fits |
|---|---|---|---|
| Manual initialization | Read every block once with dd or fio after attaching | Free, but takes minutes to hours and consumes instance throughput | Occasional restores where you can wait before cutover |
| Provisioned Rate for Volume Initialization | Specify 100–300 MiB/s at create-volume; blocks are pushed to the volume at that rate after creation | Per-GiB of snapshot data at the chosen tier, billed once | Predictable completion time for one or many volumes, no pre-planning per snapshot |
| Fast Snapshot Restore (FSR) | Pre-enable on a snapshot per AZ; volumes are created fully initialized | Per-snapshot, per-AZ, per-hour while enabled | Repeated, latency-sensitive restores from the same snapshot (golden images, test environments) |
# Read-only pass that initializes a restored volume (Linux)
sudo fio --filename=/dev/xvdf --rw=read --bs=1M --iodepth=32 \
--ioengine=libaio --direct=1 --name=volume-initialize
# Provisioned initialization rate at creation time
aws ec2 create-volume --availability-zone us-east-1a --volume-type gp3 \
--snapshot-id snap-0abcdef1234567890 --volume-initialization-rate 300With a 300 MiB/s rate, a snapshot holding 10 GiB of data finishes initializing in about 34 seconds, and ten volumes created concurrently from it all finish in the same 34 seconds. The cumulative quota is 5,000 MiB/s of requested rate per Region across concurrent requests. If you specify a rate and the snapshot has FSR enabled, the rate wins and FSR is not used.
Fast Snapshot Restore in detail
FSR is enabled per snapshot and Availability Zone pair; each pair is one FSR. Rules the exam tests:
- You must explicitly enable it on each snapshot. Copies of an FSR-enabled snapshot and new snapshots taken from a volume restored with FSR are not automatically enabled.
- Default quota: 5 snapshots per Region can have FSR enabled, counting snapshots shared with you that you enabled.
- Snapshot size must be 16 TiB or less. Volumes provisioned above 64,000 IOPS or 1,000 MiB/s should still be initialized to get full performance.
- Not supported on Outposts, Local Zones or Wavelength Zones. Automatically disabled when a snapshot is archived.
- Billing is per minute, per snapshot, per AZ, with a one-hour minimum. The documentation example: one snapshot in one AZ for 30 days is 720 hours x $0.75 = $540; two snapshots in three AZs is $3,240. Enabling FSR on a snapshot shared with you bills your account.
The subtle part is volume creation credits. Each snapshot/AZ pair has a credit bucket; creating a fully initialized volume consumes one credit, and if less than one credit is available the volume is still created but without the FSR benefit. The bucket starts at zero when you enable FSR and fills over time:
fill rate (credits per hour) = MIN(10, 1024 / snapshot_size_gib)
bucket size (credits) = MAX(1, MIN(10, 1024 / snapshot_size_gib))For a 128 GiB snapshot that is 8 credits per hour (about 0.133 per minute) and a bucket of 8, so roughly eight minutes after enabling you can restore one initialized volume, and once full you can restore eight at once. Note that the size used is the snapshot’s volume size, not its data size. The fastRestored field in describe-volumes confirms whether a given volume benefited. The exam framing: “a team restores 20 volumes from the same snapshot at 09:00 every day and complains that some are slow” is a credit-bucket exhaustion question, and the answer is a provisioned initialization rate or fewer concurrent restores, not “enable FSR” (it already is).
Snapshots Archive: The Cold Tier
By default snapshots live in the standard tier. Moving a snapshot to the Amazon EBS Snapshots Archive tier converts it to a full snapshot (every block written at the time it was taken) and stores it at up to 75 percent lower cost: $0.0125 per GB-month versus $0.05 standard in the documentation’s pricing example. Rules:
- Minimum archive period is 90 days. Delete or permanently restore earlier and you pay the remaining days, rounded to the hour. A temporary restore before 90 days does not incur that charge.
- Restore takes up to 72 hours, and costs $0.03 per GB restored. You can restore temporarily (a copy comes back to standard tier for a period you choose while the archive copy remains, so you pay both) or permanently (the archive copy is deleted).
- Archived snapshots cannot be used to create volumes, used in a block device mapping, copied, shared, or FSR-enabled. Restore to standard tier first.
- Because archived snapshots are full, archiving daily incrementals of one volume usually costs more than leaving them in standard tier. AWS recommends archiving monthly, quarterly or yearly snapshots, and the Data Lifecycle Manager console only allows archive rules on schedules with a creation frequency of at least 28 days.
- You can archive a snapshot associated with an AMI only if every associated AMI is disabled, and you cannot re-enable the AMI while its snapshots are only temporarily restored.
- Only
completedsnapshots you own can be archived; a shared snapshot must be copied first. The archive and restore operations cannot be cancelled once started. - Quotas: 25 archived snapshots per volume, 25 concurrent archives and 5 concurrent restores per account.
When a snapshot in the middle of a lineage is archived, blocks it shares with later snapshots stay in the standard tier and are charged to the next snapshot, so later incrementals are unaffected.
Recycle Bin: Undo for Deleted Snapshots
Recycle Bin retains deleted EBS snapshots, EBS volumes and EBS-backed AMIs for a period you define, after which they are permanently deleted. You create retention rules per Region:
| Rule type | Scope | Retention period |
|---|---|---|
| Region-level | Every resource of the type in the Region, optionally minus resources carrying exclusion tags | Snapshots and AMIs: 1–365 days; volumes: 1–7 days |
| Tag-level | Only resources that have at least one of the listed tag key/value pairs | Same ranges |
While in the bin a resource can be restored at any time and then used normally. Snapshots in the bin are billed at the normal snapshot rate (archived snapshots at the archive rate, and they still carry the 90-day minimum), so Recycle Bin is a safety net, not free storage. Retention rules can be locked so that they cannot be modified or deleted without first unlocking and waiting out an unlock delay, which protects the protection itself. Quota: 250 retention rules per Region. There is no extra charge for the feature.
Two interactions to know: Data Lifecycle Manager deletions that land in the Recycle Bin are no longer managed by the policy if you restore them after the retention threshold, and a snapshot can be in the archive tier and in the Recycle Bin at the same time, in which case you recover it from the bin first and then restore it from the archive.
Snapshot Lock: WORM for Snapshots
Recycle Bin recovers from accidents. Snapshot lock prevents deletion in the first place, by anyone, regardless of IAM permissions, for a duration or until an expiry date. A locked snapshot remains fully usable. There are two modes:
| Governance mode | Compliance mode | |
|---|---|---|
| Takes effect | Immediately | Immediately, with an optional cooling-off period of 1–72 hours |
| Can be unlocked by a permitted user? | Yes, any time | Only during the cooling-off period; after that, never |
| Lock settings | Mode and duration can be changed | After cooling-off, the duration can only be increased |
| Deletion before expiry | Unlock first, or wait | Wait, or close the AWS account |
| Purpose | Internal governance, testing a lock configuration | WORM retention for SEC 17a-4, CFTC and FINRA style requirements (assessed by Cohasset Associates) |
Lock duration ranges from 1 day to 36,500 days, or an explicit expiry date. Lock states are compliance-cooloff, governance, compliance and expired. A snapshot cannot be deleted even during the cooling-off period. Locking is free; you pay normal snapshot storage. The exam pattern is “ransomware or malicious insider must not be able to delete backups for seven years, and even the root user must be unable to shorten that”: compliance mode without a cooling-off period. If the requirement says “administrators must be able to lift the hold if policy changes”, that is governance mode. Both pair naturally with the vault-lock discussion in our AWS Backup vault lock guide, which solves the same problem at the backup-vault level.
Copying Snapshots: When It Is Full, When It Is Incremental
Copying is how you get a snapshot into another Region, another account, another KMS key, or onto an Outpost or Local Zone. The copy has a new snapshot ID, user-defined tags are not copied, and FSR is not carried over. The question the exam asks most is whether a copy is incremental:
- Within the same account and Region using the same KMS key: always incremental.
- Encrypting the copy with a different KMS key: always a full copy, with extra storage cost.
- Copying to a new Region for the first time: a full copy. Later copies of the same volume’s snapshots to that Region are incremental if the previous copy still exists there, has not been archived, and all copies in the destination use the same key (or are all unencrypted).
- Concurrency quota: 20 concurrent copy requests per destination (
ResourceLimitExceededif exceeded). Cross-Region copies incur data transfer charges, and you pay for data already transferred even if you delete the copy mid-flight.
Encryption outcomes
Encryption state can only move in one direction during a copy. The documentation table reduces to three rules:
- An unencrypted snapshot can be copied as encrypted (optionally, or automatically if encryption by default is on in the destination Region).
- An encrypted snapshot is always copied as encrypted; you may specify a different KMS key.
- There is no way to produce an unencrypted copy of an encrypted snapshot.
To copy an encrypted snapshot your principal needs the KMS permissions (DescribeKey, CreateGrant, GenerateDataKey*, ReEncrypt, Decrypt), and if the snapshot was shared from another account, access to their customer managed key. Without key access the copy fails silently with a “Given key ID is not accessible” status. AWS also recommends that when you use a snapshot shared with you, you re-encrypt it by copying with a key you own, so that the owner revoking key access later cannot strand your volumes.
Time-based copies
For RPO-driven replication you can request a completion duration between 15 minutes and 48 hours, in 15-minute steps, for snapshot and EBS-backed AMI copies within or across Regions. A single copy is capped at 500 MiB/s and concurrent copies between a Region pair share a 2,000 MiB/s cumulative quota (adjustable), so the minimum achievable duration is MAX(15 min, data size / 500 MiB/s). You pay a per-GiB surcharge that falls as the duration lengthens, from $0.020 per GiB at 15 minutes to $0.005 per GiB at 16 hours or more; if AWS misses the target because of its own issues you are not charged the surcharge. “Guarantee the DR Region has a copy within one hour of the nightly snapshot” is this feature.
Sharing Snapshots and Blocking Public Access
Sharing is done through the snapshot’s createVolumePermission attribute: add the all group for public, or specific 12-digit account IDs for private sharing. Constraints the exam loves:
- Snapshots are Region-scoped; to share into another Region, copy first and share the copy.
- Encrypted snapshots cannot be shared publicly, and cannot be shared at all if they use the AWS managed key
aws/ebs. Only snapshots encrypted with a customer managed key can be shared, and you must also grant the recipient account access to that key in the key policy. - Recipients cannot delete a shared snapshot. If you delete or unshare it, their access ends immediately, which is why they should copy it.
- CloudTrail records
SharedSnapshotCopyInitiatedandSharedSnapshotVolumeCreatedwhen a snapshot you shared is used.
Block public access for snapshots is a Region-level, account-level setting with two modes. Block all sharing blocks new public sharing and makes already-public snapshots behave as private (their attributes still say public, and they become public again if you disable the setting). Block new sharing blocks only new requests. It never affects private sharing, it does not block public AMIs (there is a separate block public access for AMIs), and with Organizations declarative policies you can apply it across Regions and accounts at once.
Data Lifecycle Manager: Automating All of the Above
Amazon Data Lifecycle Manager (DLM) automates creation, retention, copying, sharing, archiving and FSR of snapshots and EBS-backed AMIs at no additional cost. It manages only resources it created, and it cannot handle instance store-backed AMIs. Policy anatomy for an EBS snapshot policy:
- Target volumes or instances by tag (case-sensitive). Instance policies create multi-volume snapshot sets and can exclude the root volume or data volumes by tag.
- Up to 4 schedules per policy. Schedule 1 is mandatory and sets the retention type (count-based 1–1000, or age-based 1 day to 100 years) that all schedules inherit. Frequencies are daily, weekly, monthly, yearly or a cron expression; the first run starts within an hour of the start time.
- Per schedule you can enable FSR (choosing AZs and how many snapshots or for how long), cross-Region copy to up to three destinations with their own retention and optional encryption, cross-account sharing with automatic unshare, and archiving (one schedule per policy, volume policies only, creation frequency of at least 28 days, archive retention of at least 90 days).
- Pre and post scripts run through Systems Manager for application-consistent snapshots, including Windows VSS.
- Quotas: 100 custom policies per Region, plus one default EBS snapshot policy and one default EBS-backed AMI policy per Region. Default policies back up everything in the Region that is not already covered.
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": ["VOLUME"],
"TargetTags": [{ "Key": "backup", "Value": "daily" }],
"Schedules": [{
"Name": "daily-7",
"CreateRule": { "Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"] },
"RetainRule": { "Count": 7 },
"CopyTags": true,
"CrossRegionCopyRules": [{
"TargetRegion": "us-west-2",
"Encrypted": true,
"RetainRule": { "Interval": 30, "IntervalUnit": "DAYS" }
}]
}]
}Behaviours worth a scenario each: if you remove the target tag from a volume, DLM stops managing its existing snapshots; if an age-based policy’s retention is shorter than its interval, the last snapshot is kept until the next one exists; and a snapshot you manually lock, archive or restore from Recycle Bin after the policy’s threshold is reached is no longer managed by DLM. When an exam question needs cross-service backup (RDS, DynamoDB, EFS, EC2 together) with vault-level governance, the answer is AWS Backup rather than DLM; when it is purely EBS snapshots and AMIs with tag-driven schedules, DLM is the cheaper, simpler fit.
EBS Direct APIs: Reading and Writing Snapshot Blocks
The EBS direct APIs let software read and write snapshot contents without creating a volume and attaching it to an instance. Blocks are 512 KiB and addressed by a block index; each read returns a SHA256 checksum and each write must supply one. Six actions:
| Read | Write |
|---|---|
ListSnapshotBlocks: block indexes and tokens in a snapshot | StartSnapshot: begin a new or incremental snapshot (stays pending) |
ListChangedBlocks: blocks that differ between two snapshots of the same lineage | PutSnapshotBlock: write a block with its checksum |
GetSnapshotBlock: the data for one block | CompleteSnapshot: finalize to completed |
The two exam framings are a backup vendor that wants efficient incremental change tracking without spinning up EC2 instances (ListChangedBlocks), and on-premises disaster recovery that writes local disk data straight into an EBS snapshot during an outage. Public snapshots and Outposts local snapshots are not supported, and encrypted snapshots have key-access rules.
Scenario Drill
| Scenario | Answer | Key rule |
|---|---|---|
| Deleted 30 old daily snapshots, bill barely changed | Expected: shared blocks are retained and re-attributed to later snapshots | Deletion removes only exclusively referenced data |
| Restored database volume is slow for the first hour | Lazy loading; initialize with fio, a provisioned initialization rate, or FSR | Blocks are pulled from S3 on first access |
| Need 50 fully performant volumes from one snapshot in under two minutes, daily | Provisioned Rate for Volume Initialization (or FSR with attention to credits) | FSR credit bucket caps concurrent initialized restores |
| Keep year-end snapshots 7 years as cheaply as possible, rarely accessed | Snapshots Archive | 75% cheaper, 90-day minimum, up to 72-hour restore |
| Archive daily incrementals to save money | Wrong: archived snapshots are full, so cost rises | Archive monthly or less frequent snapshots |
| Protect against accidental deletion with easy recovery | Recycle Bin Region-level rule | 1–365 days, billed as normal snapshots |
| Backups must be undeletable for 7 years, even by admins | Snapshot lock, compliance mode, no cooling-off | Only account closure can remove it |
| Security team wants to be able to lift a hold if policy changes | Snapshot lock, governance mode | Permitted users can unlock any time |
| First cross-Region copy is as large as the full volume data | Expected: first copy to a Region is full | Later copies are incremental if the previous copy remains |
| Re-encrypting a snapshot with a new CMK doubled storage | Expected: new key forces a full copy | Same account, Region and key is the only always-incremental case |
| Share an encrypted snapshot with a partner account fails | Snapshot uses aws/ebs; copy with a customer managed key, share key policy | AWS managed key snapshots cannot be shared |
| Prevent anyone making snapshots public, org-wide | Block public access for snapshots via declarative policy | Region + account setting; does not cover AMIs |
| DR Region must have a copy within 1 hour of creation | Time-based copy with a 1-hour completion duration | 15 min–48 h, per-GiB surcharge |
| Automate daily snapshots, keep 7, copy encrypted to a second Region for 30 days | DLM policy with cross-Region copy rule | Up to 3 destination Regions per schedule |
| Backup ISV needs only changed blocks between two snapshots, no EC2 | EBS direct APIs ListChangedBlocks | 512 KiB blocks, SHA256 checksums |
| Consistent backup of data and log volumes on one instance | Multi-volume snapshot (DLM instance policy or create-snapshots) | Crash-consistent across the set |
Common Mistakes
- Treating snapshot deletion as linear savings. Only unique blocks go away; the rest are re-attributed.
- Assuming FSR carries over. Copies, new snapshots of restored volumes, and archived snapshots all lose FSR; it must be re-enabled, and only 5 per Region by default.
- Archiving frequent incrementals. Archive converts to full snapshots; it is for monthly-or-rarer snapshots kept 90 days or more.
- Confusing Recycle Bin with snapshot lock. Recycle Bin undoes a deletion that already happened and still bills storage; lock prevents the deletion. Compliance-mode lock survives everyone including root.
- Expecting an unencrypted copy of an encrypted snapshot. Encryption only ever goes from off to on during a copy.
- Sharing a snapshot encrypted with
aws/ebs. It cannot be done; re-encrypt with a customer managed key and share the key. - Thinking block public access for snapshots covers AMIs. It does not; AMIs have their own setting.
- Choosing DLM when the question spans RDS, DynamoDB or EFS. DLM is EBS snapshots and EBS-backed AMIs only; AWS Backup is the cross-service answer. The reverse mistake is paying for AWS Backup complexity when a tag-driven EBS schedule is all that was asked.
How to Lock This In Before Exam Day
If you have a sandbox account, create a 1 GiB gp3 volume, write a few hundred megabytes, snapshot it twice with a change in between, and compare FullSnapshotSizeInBytes in describe-snapshots for each; then delete the first snapshot and confirm the second still restores. Copy a snapshot with --encrypted --kms-key-id and watch the copy size. Create a Region-level Recycle Bin rule, delete a snapshot, and restore it. Those three exercises cover 80 percent of the rules in this article and take under thirty minutes; FSR and Snapshots Archive have minimum charges, so read rather than run those.
Then practise the decision patterns under time pressure. The SAA-C03 mock exam bundle includes EBS snapshot scenarios of exactly this shape, with explanations that tell you which rule eliminated each distractor, which is the fastest way to find out whether you have memorised the words or understood the model. The broader storage objectives sit in the storage services guide, the restore-and-DR framing in the resilient architectures guide, and the one-page recap in the Solutions Architect cheat sheet.
Conclusion
EBS snapshots are simple to describe and subtle to operate. The incremental block model explains both the pricing surprises and the “only the latest snapshot matters” restore rule. Lazy loading explains slow restores, and the three fixes trade money for predictability: manual reads, a provisioned initialization rate, or FSR with its credit buckets and per-AZ hourly billing. Snapshots Archive is the cheap cold tier with a 90-day minimum and full-snapshot conversion; Recycle Bin and snapshot lock are the two layers of deletion protection, one recoverable and one immovable. Copies are incremental only when account, Region and key all match, encryption is one-way, and sharing requires a customer managed key. Data Lifecycle Manager strings every one of those features into a tag-driven policy, and the EBS direct APIs expose the blocks to backup software. Know the rules in that order and the exam’s snapshot questions stop being guesswork.
Frequently Asked Questions
Are EBS snapshots really stored in S3, and can I see them there?
They are stored in Amazon S3, but in AWS-managed buckets you cannot access. You manage snapshots only through the EC2 console and API. Snapshot data is replicated across all Availability Zones in the Region, which is why a snapshot can restore into any AZ.
If snapshots are incremental, why is my cross-Region copy so large?
The first copy of a volume’s snapshot into a new Region is a full copy, because nothing in the destination Region can be referenced. Subsequent copies are incremental as long as the previous copy still exists there, has not been archived, and uses the same KMS key (or all copies are unencrypted).
What is the difference between Fast Snapshot Restore and the volume initialization rate?
FSR is enabled on a snapshot per Availability Zone ahead of time and billed hourly while enabled; volumes are created fully initialized, subject to a per-snapshot credit bucket. The Provisioned Rate for Volume Initialization is chosen per volume at creation (100–300 MiB/s), billed once per GiB of snapshot data, and gives a predictable completion time without pre-enabling anything. If both apply, the rate wins.
Can I shorten or remove a compliance-mode snapshot lock?
Only during the optional cooling-off period of 1 to 72 hours. After that, or immediately if no cooling-off period was set, the lock can only be extended. The only way to delete the snapshot before the lock expires is to close the AWS account. Governance mode, by contrast, can be unlocked by any user with the right IAM permissions.
Why can’t I share my encrypted snapshot with another account?
Snapshots encrypted with the AWS managed key aws/ebs cannot be shared. Copy the snapshot while re-encrypting it with a customer managed key, share that key with the other account through its key policy, and then share the snapshot. Encrypted snapshots can never be shared publicly.
Should I use Data Lifecycle Manager or AWS Backup?
Use DLM when the requirement is limited to EBS snapshots and EBS-backed AMIs with tag-driven schedules, retention, cross-Region copy, archiving or FSR; it is free and purpose-built. Use AWS Backup when backups span multiple services, need central vaults, vault lock, or organization-wide backup policies. Many environments run both: DLM for high-frequency EBS snapshots and AWS Backup for governed, cross-service recovery points, as described in our centralized backup governance guide.
Does Recycle Bin make snapshots free while they are retained?
No. Snapshots in the Recycle Bin are billed at the same rate as any other snapshot, and archived snapshots in the bin at the archive rate. The Recycle Bin feature itself has no charge; the storage behind it does.