EBS Snapshot

EBS provides the ability to create snapshots (backups) of any EBS volume and write a copy of the data in the volume to S3, where it is stored redundantly in multiple Availability Zones

Snapshots are incremental backups and store only the data that was changed from the time the last snapshot was taken.
Snapshots can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones.

Snapshot size can probably be smaller than the volume size as the data is compressed before being saved to S3.
Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.
EBS Snapshots can be used to migrate or create EBS volumes in different AZs or regions.

Snapshot data is automatically replicated across all Availability Zones in the Region.

Multi-Volume Snapshots

Snapshots can be used to create a backup of critical workloads, such as a large database or a file system that spans across multiple EBS volumes.
Multi-volume snapshots help take exact point-in-time, data-coordinated, and crash-consistent snapshots across multiple EBS volumes attached to an EC2 instance.

It is no longer required to stop the instance or to coordinate between volumes to ensure crash consistency because snapshots are automatically taken across multiple EBS volumes.

EBS Snapshot creation

Snapshots can be created from EBS volumes periodically and are point-in-time snapshots.
Snapshots are incremental and only store the blocks on the device that changed since the last snapshot was taken

Snapshots occur asynchronously; the point-in-time snapshot is created immediately while it takes time to upload the modified blocks to S3. While it is completing, an in-progress snapshot is not affected by ongoing reads and writes to the volume.
Snapshots can be taken from in-use volumes. However, snapshots will only capture the data that was written to the EBS volumes at the time the snapshot command is issued excluding the data which is cached by any applications of OS.
Recommended ways to create a Snapshot from an EBS volume are
- Pause all file writes to the volume
- Unmount the Volume -> Take Snapshot -> Remount the Volume
- Stop the instance – Take Snapshot (for root EBS volumes)
EBS volume created based on a snapshot
- begins as an exact replica of the original volume that was used to create the snapshot.
- replicated volume loads data in the background so that it can be used immediately.
- If data that hasn’t been loaded yet is accessed, the volume immediately downloads the requested data from S3 and then continues loading the rest of the volume’s data in the background.

EBS Snapshot Deletion

When a snapshot is deleted only the data exclusive to that snapshot is removed.
Deleting previous snapshots of a volume does not affect the ability to restore volumes from later snapshots of that volume.
Active snapshots contain all of the information needed to restore your data (from the time the snapshot was taken) to a new EBS volume.

Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.
Snapshot of the root device of an EBS volume used by a registered AMI can’t be deleted. AMI needs to be deregistered to be able to delete the snapshot.

EBS Snapshot Copy

Snapshots are constrained to the region in which they are created and can be used to launch EBS volumes within the same region only

Snapshots can be copied across regions to make it easier to leverage multiple regions for geographical expansion, data center migration, and disaster recovery
Snapshots are copied with S3 server-side encryption (256-bit Advanced Encryption Standard) to encrypt the data and the snapshot copy receives a snapshot ID that’s different from the original snapshot’s ID.
User-defined tags are not copied from the source to the new snapshot.

First Snapshot copy to another region is always a full copy, while the rest are always incremental.
When a snapshot is copied,
- it can be encrypted if currently unencrypted or
- can be encrypted using a different encryption key. Changing the encryption status of a snapshot or using a non-default EBS KMS key during a copy operation always results in a full copy (not incremental)

Time-based Snapshot Copy

Time-based Copy (launched Nov 2024) allows specifying a desired completion duration (15 minutes to 48 hours) when copying a snapshot within or between AWS Regions and/or accounts.
Helps meet time-based compliance and business requirements such as Recovery Point Objectives (RPOs) for disaster recovery.
Duration can range from 15 minutes to 48 hours in 15-minute increments, specified on a per-copy basis.

Maximum per-snapshot throughput is 500 MiB/second; default per-account limit is 2000 MiB/second between each source and destination pair.
If the copy cannot be completed within the specified duration, an EventBridge copyMissedCompletionDuration event is sent.
Available in all AWS Regions.

EBS Snapshot Sharing

Snapshots can be shared by making them public or with specific AWS accounts by modifying the access permissions of the snapshots

Encrypted snapshots cannot be made available publicly.
Encrypted snapshots can be shared with specific AWS accounts by sharing the customer managed KMS key used to encrypt it.
Cross-account permissions may be applied to a KMS key either when it is created or at a later time.
Users, with access to snapshots, can copy the snapshot and create their own EBS volumes based on the snapshot while the original snapshot remains unaffected

AWS prevents you from sharing snapshots that were encrypted with the default AWS managed key (aws/ebs). Only snapshots encrypted with customer managed KMS keys can be shared.
To share an encrypted snapshot cross-region, copy the snapshot to the destination region first and then share the copy.

EBS Snapshot Encryption

EBS snapshots fully support EBS encryption.
Snapshots of encrypted volumes are automatically encrypted
Volumes created from encrypted snapshots are automatically encrypted
All data in flight between the instance and the volume is encrypted

Volumes created from an unencrypted snapshot owned or have access to can be encrypted on the fly.
Unencrypted snapshots can be encrypted during the copy process.
Encrypted snapshots that you own or have access to, can be encrypted with a different key during the copy process.
First snapshot of an encrypted volume that has been created from an unencrypted snapshot is always a full snapshot.

First snapshot of a re-encrypted volume, which has a different KMS key compared to the source snapshot, is always a full snapshot.

EBS Fast Snapshot Restore (FSR)

Fast Snapshot Restore (FSR) eliminates the need for the traditional initialization process when creating a volume from a snapshot.
Volumes created from FSR-enabled snapshots instantly deliver all of their provisioned performance without the latency penalty of lazy loading blocks from S3.

FSR is enabled on selected snapshots in specific Availability Zones.
FSR is disabled for a snapshot by default. When enabled or disabled, the changes apply to your account only.
FSR is useful for workloads requiring rapid provisioning such as VDI (Virtual Desktop Infrastructure), backup & restore, test/dev volume copies, and booting from custom AMIs.

FSR supports io2 Block Express volumes.
FSR is not supported with AWS Outposts, Local Zones, and Wavelength Zones.
FSR-enabled snapshots shared with your account can be used with FSR enabled in your account independently.
Additional charges apply for each minute that FSR is enabled on a snapshot in a particular AZ.

EBS Snapshot Archive

EBS Snapshots Archive is a low-cost storage tier for rarely accessed snapshots that provides up to 75% lower storage costs.
Designed for snapshots retained for 90 days or longer that do not require frequent or fast retrieval.
When a snapshot is archived, the incremental snapshot is converted to a full snapshot and moved to the archive tier.

Archived snapshots have a minimum retention period of 90 days.
To use an archived snapshot, it must first be restored to the standard tier, after which it can be used like any other snapshot.
Restoring from archive takes 24-72 hours depending on the snapshot size.

EBS Direct APIs cannot be used with archived snapshots.
Snapshot locks can be applied to snapshots that have already been archived.
Amazon Data Lifecycle Manager can automatically archive snapshots based on policies.
AWS Backup supports EBS Snapshots Archive in backup policies.

EBS Snapshot Lock

EBS Snapshot Lock (launched Nov 2023) protects snapshots from inadvertent or malicious deletions, including ransomware attacks.

Locked snapshots cannot be deleted until the lock expires or is released.
Lock duration can range from one day to approximately 100 years.
Two lock modes are available:
- Governance mode – Protects from deletion by all users. With proper IAM permissions, the lock duration can be extended/shortened, the lock deleted, or mode changed to Compliance.
- Compliance mode – Protects from deletion by all users including the root user. After a cooling-off period (up to 72 hours), neither the snapshot nor the lock can be deleted until the lock expires. Lock duration can only be extended, not shortened.
Snapshots in either mode can still be shared, copied, or archived.

Supports WORM (Write Once Read Many) compliance requirements.
No additional charges for using Snapshot Lock; standard snapshot storage rates apply.
Available in all commercial AWS Regions.
If using customer managed KMS keys for encryption, ensure the key remains valid for the lifetime of the locked snapshot.

Recycle Bin for EBS Snapshots

Recycle Bin enables recovery of accidentally deleted EBS snapshots and EBS-backed AMIs.

Retention rules specify a retention period (1 day to 1 year) during which deleted snapshots are retained before permanent deletion.
A recovered snapshot retains all its attributes including tags, permissions, and encryption status.
Recovered snapshots can be used immediately for creating volumes.
Rule Lock can be applied to Recycle Bin retention rules to prevent them from being modified or deleted, providing additional protection.

Recycle Bin also supports EBS-backed AMIs and EBS Volumes (added 2025).

EBS Direct APIs

EBS Direct APIs allow creating EBS snapshots, writing data directly to snapshots, reading snapshot data, and identifying differences between two snapshots.
Key operations include:
- ListSnapshotBlocks – Returns block indexes and block tokens of blocks in a snapshot.
- ListChangedBlocks – Returns blocks that are different between two snapshots of the same volume.
- GetSnapshotBlock – Returns data in a block for a given snapshot.
- StartSnapshot – Creates a new snapshot (can be used to create snapshots from on-premises data).
- PutSnapshotBlock – Adds data to a started snapshot in the form of individual blocks.
- CompleteSnapshot – Completes a snapshot after all blocks have been written.

Enables backup of on-premises data directly into EBS snapshots without needing an EC2 instance.
Useful for incremental backup solutions and disaster recovery from on-premises to AWS.
Does not support public snapshots or archived snapshots.

Local Snapshots

Local Snapshots allow creating and storing snapshots in AWS Local Zones and Dedicated Local Zones.

By default, snapshots of EBS volumes in a Local Zone are stored in S3 in the parent Region.
With Local Snapshots, backups can be stored within the same geographical boundary as the EBS volumes, helping meet data residency and data isolation requirements.
Snapshot copy is supported for Local Zones, allowing copies to be sent to the Region or another Local Zone.

EBS Direct APIs do not support local snapshots on Outposts.

EBS Snapshot Lifecycle Automation

Amazon Data Lifecycle Manager (DLM) can be used to automate the creation, retention, and deletion of snapshots taken to back up the EBS volumes.
Automating snapshot management helps you to:
- Protect valuable data by enforcing a regular backup schedule.
- Retain backups as required by auditors or internal compliance.
- Reduce storage costs by deleting outdated backups.
- Automatically archive snapshots to the Archive tier based on policies.
AWS Backup provides a centralized, policy-based approach to manage EBS snapshot backups across AWS accounts and regions.
AWS Backup supports EBS Snapshots Archive in backup policies for cost-optimized long-term retention.

EBS Snapshot Resource-Level Permissions

Enhanced resource-level permissions (2025) allow specifying additional resource-level authorization in IAM policies for source snapshots when creating volumes (CreateVolume) or copying snapshots (CopySnapshot).
Enables fine-grained access control over which snapshots can be used as sources for volume creation or copy operations.

AWS Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

An existing application stores sensitive information on a non-boot Amazon EBS data volume attached to an Amazon Elastic Compute Cloud instance. Which of the following approaches would protect the sensitive data on an Amazon EBS volume?
1. Upload your customer keys to AWS CloudHSM. Associate the Amazon EBS volume with AWS CloudHSM. Remount the Amazon EBS volume.
2. Create and mount a new, encrypted Amazon EBS volume. Move the data to the new volume. Delete the old Amazon EBS volume.
3. Unmount the EBS volume. Toggle the encryption attribute to True. Re-mount the Amazon EBS volume.
4. Snapshot the current Amazon EBS volume. Restore the snapshot to a new, encrypted Amazon EBS volume. Mount the Amazon EBS volume (Need to create a snapshot, create an encrypted copy of snapshot and then create an EBS volume and mount it)
Is it possible to access your EBS snapshots?
1. Yes, through the Amazon S3 APIs.
2. Yes, through the Amazon EC2 APIs
3. No, EBS snapshots cannot be accessed; they can only be used to create a new EBS volume.
4. EBS doesn’t provide snapshots.

Which of the following approaches provides the lowest cost for Amazon Elastic Block Store snapshots while giving you the ability to fully restore data?
1. Maintain two snapshots: the original snapshot and the latest incremental snapshot
2. Maintain a volume snapshot; subsequent snapshots will overwrite one another
3. Maintain a single snapshot the latest snapshot is both Incremental and complete
4. Maintain the most current snapshot, archive the original and incremental to Amazon Glacier.
Which procedure for backing up a relational database on EC2 that is using a set of RAIDed EBS volumes for storage minimizes the time during which the database cannot be written to and results in a consistent backup?
1. Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
2. Stop the EC2 Instance. 2. Snapshot the EBS volumes
3. Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
4. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
5. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
How can an EBS volume that is currently attached to an EC2 instance be migrated from one Availability Zone to another?
1. Detach the volume and attach it to another EC2 instance in the other AZ.
2. Simply create a new volume in the other AZ and specify the original volume as the source.
3. Create a snapshot of the volume, and create a new volume from the snapshot in the other AZ
4. Detach the volume, then use the ec2-migrate-volume command to move it to another AZ.

How are the EBS snapshots saved on Amazon S3?
1. Exponentially
2. Incrementally
3. EBS snapshots are not stored in the Amazon S3
4. Decrementally
EBS Snapshots occur _____
1. Asynchronously
2. Synchronously
3. Weekly
What will be the status of the snapshot until the snapshot is complete?
1. Running
2. Working
3. Progressing
4. Pending
Before I delete an EBS volume, what can I do if I want to recreate the volume later?
1. Create a copy of the EBS volume (not a snapshot)
2. Create and Store a snapshot of the volume
3. Download the content to an EC2 instance
4. Back up the data in to a physical disk
Which of the following are true regarding encrypted Amazon Elastic Block Store (EBS) volumes? Choose 2 answers
1. Supported on all Amazon EBS volume types
2. Snapshots are automatically encrypted
3. Available to all instance types
4. Existing volumes can be encrypted
5. Shared volumes can be encrypted
Amazon EBS snapshots have which of the following two characteristics? (Choose 2.) Choose 2 answers
1. EBS snapshots only save incremental changes from snapshot to snapshot
2. EBS snapshots can be created in real-time without stopping an EC2 instance (the snapshot can be taken real time however it will not be consistent and the recommended way is to stop or freeze the IO)
3. EBS snapshots can only be restored to an EBS volume of the same size or smaller (EBS volume restored from snapshots need to be of the same size of larger size)
4. EBS snapshots can only be restored and mounted to an instance in the same Availability Zone as the original EBS volume (Snapshots are specific to Region and can be used to create a volume in any AZ and does not depend on the original EBS volume AZ)
A user is planning to schedule a backup for an EBS volume. The user wants security of the snapshot data. How can the user achieve data encryption with a snapshot?
1. Use encrypted EBS volumes so that the snapshot will be encrypted by AWS (Refer link)
2. While creating a snapshot select the snapshot with encryption
3. By default the snapshot is encrypted by AWS
4. Enable server side encryption for the snapshot using S3

A sys admin is trying to understand EBS snapshots. Which of the below mentioned statements will not be useful to the admin to understand the concepts about a snapshot?
1. Snapshot is synchronous
2. It is recommended to stop the instance before taking a snapshot for consistent data
3. Snapshot is incremental
4. Snapshot captures the data that has been written to the hard disk when the snapshot command was executed

When creation of an EBS snapshot is initiated but not completed, the EBS volume
1. Cannot be detached or attached to an EC2 instance until me snapshot completes
2. Can be used in read-only mode while me snapshot is in progress
3. Can be used while the snapshot is in progress
4. Cannot be used until the snapshot completes

You have a server with a 5O0GB Amazon EBS data volume. The volume is 80% full. You need to back up the volume at regular intervals and be able to re-create the volume in a new Availability Zone in the shortest time possible. All applications using the volume can be paused for a period of a few minutes with no discernible user impact. Which of the following backup methods will best fulfill your requirements?
1. Take periodic snapshots of the EBS volume
2. Use a third-party Incremental backup application to back up to Amazon Glacier
3. Periodically back up all data to a single compressed archive and archive to Amazon S3 using a parallelized multi-part upload
4. Create another EBS volume in the second Availability Zone attach it to the Amazon EC2 instance, and use a disk manager to mirror me two disks
A user is creating a snapshot of an EBS volume. Which of the below statements is incorrect in relation to the creation of an EBS snapshot?
1. Its incremental
2. It can be used to launch a new instance
3. It is stored in the same AZ as the volume (stored in the same region)
4. It is a point in time backup of the EBS volume
A user has created a snapshot of an EBS volume. Which of the below mentioned usage cases is not possible with respect to a snapshot?
1. Mirroring the volume from one AZ to another AZ
2. Launch an instance
3. Decrease the volume size
4. Increase the size of the volume
What is true of the way that encryption works with EBS?
1. Snapshotting an encrypted volume makes an encrypted snapshot; restoring an encrypted snapshot creates an encrypted volume when specified / requested.
2. Snapshotting an encrypted volume makes an encrypted snapshot when specified / requested; restoring an encrypted snapshot creates an encrypted volume when specified / requested.
3. Snapshotting an encrypted volume makes an encrypted snapshot; restoring an encrypted snapshot always creates an encrypted volume.
4. Snapshotting an encrypted volume makes an encrypted snapshot when specified / requested; restoring an encrypted snapshot always creates an encrypted volume.
Why are more frequent snapshots of EBS Volumes faster?
1. Blocks in EBS Volumes are allocated lazily, since while logically separated from other EBS Volumes, Volumes often share the same physical hardware. Snapshotting the first time forces full block range allocation, so the second snapshot doesn’t need to perform the allocation phase and is faster.
2. The snapshots are incremental so that only the blocks on the device that have changed after your last snapshot are saved in the new snapshot.
3. AWS provisions more disk throughput for burst capacity during snapshots if the drive has been pre-warmed by snapshotting and reading all blocks.
4. The drive is pre-warmed, so block access is more rapid for volumes when every block on the device has already been read at least one time.
Which is not a restriction on AWS EBS Snapshots?
1. Snapshots which are shared cannot be used as a basis for other snapshots (Snapshots shared with other users are usable in full by the recipient, including but limited to the ability to base modified volumes and snapshots)
2. You cannot share a snapshot containing an AWS Access Key ID or AWS Secret Access Key
3. You cannot share snapshots encrypted with the default AWS managed key (NOTE: Encrypted snapshots CAN be shared with specific accounts if encrypted with a customer managed KMS key. Only snapshots encrypted with the default aws/ebs key cannot be shared.)
4. Snapshot restorations are restricted to the region in which the snapshots are created
There is a very serious outage at AWS. EC2 is not affected, but your EC2 instance deployment scripts stopped working in the region with the outage. What might be the issue?
1. The AWS Console is down, so your CLI commands do not work.
2. S3 is unavailable, so you can’t create EBS volumes from a snapshot you use to deploy new volumes. (EBS volume snapshots are stored in S3. If S3 is unavailable, snapshots are unavailable)
3. AWS turns off the DeployCode API call when there are major outages, to protect from system floods.
4. None of the other answers make sense. If EC2 is not affected, it must be some other issue.

New Practice Questions – EBS Snapshot Features (2021-2025)

A company needs to ensure that critical EBS snapshots cannot be deleted by any user, including the root user, for a period of 5 years to meet regulatory compliance. Which feature should be used?
1. AWS Backup Vault Lock
2. Recycle Bin with 5-year retention
3. EBS Snapshot Lock in Compliance mode
4. EBS Snapshot Lock in Governance mode
A company wants to reduce storage costs for EBS snapshots that are retained for compliance but rarely accessed. The snapshots need to be kept for at least 2 years. Which approach provides the lowest cost?
1. Keep snapshots in standard tier and use lifecycle policies to delete after 2 years
2. Move snapshots to EBS Snapshots Archive tier
3. Copy snapshots to S3 Glacier
4. Use Recycle Bin with a 2-year retention period
An organization accidentally deleted an EBS snapshot that was needed for disaster recovery. Which AWS feature could have prevented permanent data loss?
1. EBS Snapshot Lock
2. Multi-volume snapshots
3. Recycle Bin for EBS Snapshots
4. Fast Snapshot Restore
A company needs to copy an EBS snapshot to another region and must ensure the copy completes within 2 hours to meet their RPO requirements. Which feature should they use?
1. Fast Snapshot Restore
2. Time-based Snapshot Copy with a 2-hour completion duration
3. EBS Direct APIs
4. Standard cross-region copy with CloudWatch monitoring
A company runs a VDI environment and needs volumes created from snapshots to deliver full provisioned performance immediately without any initialization penalty. Which feature should be enabled?
1. EBS Snapshot Archive
2. Time-based Snapshot Copy
3. EBS Direct APIs
4. Fast Snapshot Restore (FSR)
A backup solution needs to create EBS snapshots directly from on-premises block storage data without using an EC2 instance as an intermediary. Which approach enables this?
1. AWS Storage Gateway
2. AWS DataSync
3. EBS Direct APIs (StartSnapshot, PutSnapshotBlock, CompleteSnapshot)
4. S3 Transfer Acceleration with snapshot import
What happens when an EBS snapshot is archived? (Choose 2)
1. The incremental snapshot is converted to a full snapshot
2. The snapshot remains incremental in the archive tier
3. The snapshot is moved from the standard tier to the archive tier
4. The snapshot is automatically deleted after 90 days
5. The snapshot can still be used directly to create volumes without restoration