Snapshot

AWS EBS Snapshots – Backup, Copy & Encryption

~ Last updated on : ~ jayendrapatil ~ 38 Comments

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.

📖 Related: AWS S3 vs EBS vs EFS – Complete Storage Comparison Guide

📖 Related: AWS EBS Volume Types – gp3, io2, st1, sc1 Comparison

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.
  1. 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)
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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
  7. EBS Snapshots occur _____
    1. Asynchronously
    2. Synchronously
    3. Weekly
  8. What will be the status of the snapshot until the snapshot is complete?
    1. Running
    2. Working
    3. Progressing
    4. Pending
  9. 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
  10. 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
  11. 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)
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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.
  19. 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.
  20. 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
  21. 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)

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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)
  6. 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
  7. 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

Google Cloud Compute Engine Snapshots & Backups

~ Last updated on : ~ jayendrapatil

Compute Engine Snapshots

  • Snapshots provide periodic backup of Persistent Disk and Google Cloud Hyperdisk volumes.
  • Snapshots incrementally back up data from the disks.
  • Snapshots are global resources by default, so any snapshot is accessible by any resource within the same project. Regionally scoped snapshots (Preview) are also available for data residency requirements.
  • Snapshots can be shared across projects.
  • Storage costs for disk snapshots charge only for the total size of the snapshot.
  • Snapshots once created with the current state of the disk, can be restored as a new disk.
  • Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of the data.
  • Snapshots can be created from disks even while they are attached to running virtual machine (VM) instances.
  • Lifecycle of a snapshot created from a disk attached to a running VM instance is independent of the lifecycle of the VM instance.
  • Standard and archive snapshots can be stored in either one Cloud Storage multi-regional location, such as asia, or one Cloud Storage regional location, such as asia-south1.
  • A multi-regional storage location provides higher availability and might reduce network costs when creating or restoring a snapshot.
  • A snapshot can be used to create a new disk in any region and zone, regardless of the storage location of the snapshot.

Snapshot Types

  • Compute Engine provides three types of snapshots: Standard, Archive, and Instant.
  • All three types capture the contents of a disk at a specific point in time but differ in retention behavior, recovery time, and storage location.

Standard Snapshots

  • Provide geo-redundant data backup stored in one or more regions, separate from the source disk.
  • Best for disaster recovery and regular backups.
  • Support both Persistent Disk and Hyperdisk volumes.
  • Can be created with snapshot schedules for automated backups.
  • Are NOT deleted when the source disk is deleted.
  • Offer faster data recovery times than archive snapshots.

Archive Snapshots

  • Same benefits as standard snapshots (incremental chains, compression, encryption) but at lower cost.
  • Best suited for compliance, audit, and long-term cold storage use cases.
  • Have a 90-day minimum billing period and charges for retrievals.
  • Have the longest data recovery times but offer the most cost-efficient storage.
  • Cannot be created with snapshot schedules.
  • Are NOT deleted when the source disk is deleted.
  • Stored in separate incremental snapshot chains from standard snapshots.

Instant Snapshots

  • Introduced in August 2024, instant snapshots provide near-instantaneous, high-frequency, point-in-time checkpoints of a disk.
  • Provide in-place data backup stored in the same zone or region as the source disk.
  • Offer the lowest and best recovery times — RPO of seconds and RTO in tens of seconds.
  • Created in seconds with no performance impact to the underlying disk.
  • Are incremental — only store changed data blocks since the previous instant snapshot.
  • Are deleted when the source disk is deleted (lifecycle tied to source disk).
  • Not redundant — stored only in the same zone/region as the source disk.
  • Cannot be created with snapshot schedules.
  • Can be converted to standard or archive snapshots for geo-redundant, long-term storage.
  • Support Persistent Disk and most Hyperdisk types (except Hyperdisk ML and Hyperdisk Throughput).
  • Use cases include:
    • Rapid recovery from user error, application failures, and file system corruption.
    • Backup verification workflows (create snapshot, restore, verify consistency).
    • Taking restore points before application upgrades for rapid rollback.
    • Improving developer productivity with fast restores during development cycles.

Snapshot Type Comparison

Feature Standard Archive Instant
Best for Geo-redundant DR backup Long-term cold storage, compliance In-place backup, rapid restore
Storage Location Multi-region or regional (separate from source) Multi-region or regional (separate from source) Same zone/region as source disk
Recovery Time Minutes Longest (minutes to hours) Seconds
Redundancy Geo-redundant Geo-redundant Not redundant (same zone only)
Hyperdisk Support Yes Yes Yes (except ML & Throughput)
Snapshot Schedules Yes No No
Deleted on Source Disk Deletion No No Yes

Snapshot Scopes (Preview)

  • Snapshots can be created as globally scoped (default) or regionally scoped.
  • Globally scoped snapshots can be created and restored in any region without restriction.
  • Regionally scoped snapshots ensure all snapshot data and metadata are co-located within the scoped region.
    • Restrict allowed snapshot creation and restore locations.
    • Help control network costs.
    • Enhance resiliency to global outages.
    • Provide additional data security by limiting locations where data can be created/restored.
  • Regionally scoped snapshots can only be stored in Cloud Storage regional locations (not multi-regional).
  • Cannot convert a globally scoped snapshot to a regionally scoped snapshot — must create a new one.

Snapshot Creation

  • Snapshots are incremental and automatically compressed, so that they can be regularly created on a Persistent Disk or Hyperdisk faster and at a lower cost than regularly creating a full image of the disk.
  • Incremental snapshots work as follows:
    • The first successful snapshot of a disk is a full snapshot that contains all the data on the disk.
    • The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn’t changed since the first snapshot isn’t included. Instead, it contains references to the first snapshot for any unchanged data.
    • Snapshot 3 contains any new or changed data since snapshot 2 but won’t contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.
  • To ensure the reliability of snapshot history, a snapshot might occasionally capture a full image of the disk automatically.

Snapshot Chains

  • Standard snapshots can be created in distinct snapshot chains by specifying a chain name at creation time.
  • Each new snapshot with the same chain name is based incrementally on the last successful snapshot created with that chain name.
  • Useful for advanced use cases like chargeback tracking across separate incremental chains.
  • Standard and archive snapshots are stored in separate incremental chains.

Snapshot Deletion

  • Compute Engine uses incremental snapshots so that each snapshot contains only the data that has changed since the previous snapshot.
  • For unchanged data, snapshots reference the data in previous snapshots.
  • Warning: Deleting a snapshot is irreversible. You can’t recover a deleted snapshot.
  • When a snapshot is deleted:
    • If the snapshot has no dependent snapshots, it is deleted outright.
    • If the snapshot does have dependent snapshots:
      • Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
      • Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
      • The next snapshot no longer references the snapshot marked for deletion, and instead references the snapshot before it.
  • Deleting a snapshot does not necessarily delete all the data on the snapshot because subsequent snapshots might require that information.
  • To definitively delete data from the snapshots, you should delete all snapshots.
  • If a disk has a snapshot schedule, you must detach the schedule from the disk before deleting it.

Snapshot Schedules

  • Snapshot schedules create standard snapshots at specified intervals to provide automated, geo-redundant disk backups.
  • Support both Persistent Disk and Hyperdisk volumes (zonal and regional).
  • Snapshot schedules are a best practice for backing up Compute Engine workloads — available at no additional charge.
  • Configure schedules with:
    • Frequency: Hourly (1-23 hour intervals), daily, or weekly.
    • Retention policy: Maximum number of days to retain snapshots with auto-deletion of older ones.
    • Source disk deletion behavior: What happens to automatic snapshots when the source disk is deleted.
    • Storage location: Region or multi-region for snapshot storage.
  • Application consistent snapshots can be configured for:
    • Windows: VSS (Volume Shadow Copy Service) snapshots.
    • Linux: Guest-flush option with pre/post snapshot scripts (Persistent Disk only).
  • Snapshot schedules have separate frequency considerations and don’t contribute to the manual snapshot frequency limit.

Backup and DR Service

  • Google Cloud Backup and DR Service provides enhanced protection with immutable and indelible backups of Compute Engine instances.
  • Offers an out-of-the-box backup solution with seamless backup management across projects.
  • Supports backup plans that can be applied to instances during or after creation.
  • Provides features beyond snapshot schedules:
    • Immutable backups protected against deletion for a specified retention period.
    • Centralized backup management console.
    • Cross-region backup storage for disaster recovery.
    • Scheduled backups (daily, weekly, monthly, yearly).
  • Uses Persistent Disk snapshots under the hood to incrementally back up data at the instance level.

Snapshot Best Practices

  • Security: Only grant snapshot-related IAM permissions (compute.snapshots.useReadOnly, compute.instantSnapshots.useReadOnly) to trusted principals to prevent unintended privilege escalation.
  • Crash Consistent vs Application Consistent:
    • Crash consistent: Default behavior — captures disk state as if the machine crashed (may have pending writes in transit).
    • Application consistent: Pause applications and flush writes before snapshot to capture complete application state.
  • If creating a snapshot while an application is running, prepare disk for consistency:
    • Pause application/processes that write data, flush disk buffers.
    • Unmount disk completely.
    • For Windows, use VSS snapshots.
    • For Linux on Persistent Disk, use guest-flush with pre/post scripts.
    • For Linux on Hyperdisk, manually pause the application before creating the snapshot.
  • Use snapshot schedules as a best practice to back up your Compute Engine workloads.
  • Use instant snapshots or disk clones instead of standard snapshots when you need an immediate copy in the same zone.
  • Schedule snapshots during off-peak hours (avoid midnight peaks).
  • Snapshot frequency limit: You can snapshot a specific disk at most 6 times every 60 minutes. Avoid taking snapshots more often than once per hour.
  • Use multiple disks for large data volumes. Larger amounts of data create larger snapshots, which cost more and take longer.
  • Run fstrim before snapshot (Linux) or enable the discard mount option to clean up space, reducing snapshot size and creation time.
  • Create an image from an infrequently used snapshot, instead of using the snapshot itself repeatedly (saves networking costs).
  • Use journaling file systems like ext4 to reduce the risk that data is cached without being written to disk.
  • Wait for new snapshots to finish before taking subsequent snapshots from the same disk to avoid duplicate effort.

Snapshot Storage Locations

  • Standard and archive snapshots can be stored in:
    • Cloud Storage multi-regional locations (e.g., asia, us) — highest availability and resilience.
    • Cloud Storage regional locations (e.g., asia-south1, us-central1) — more control over data placement.
  • Regionally scoped snapshots can only be stored in regional locations.
  • You cannot change the storage location of an existing snapshot.
  • Snapshot settings define a default storage location for all project snapshots (configurable).
  • Network charges apply for cross-region snapshot creation or restoration.
  • To minimize costs, store snapshots in the same region as the source disk.

GCP 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).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have a workload running on Compute Engine that is critical to your business. You want to ensure that the data on the boot disk of this workload is backed up regularly. You need to be able to restore a backup as quickly as possible in case of disaster. You also want older backups to be cleaned automatically to save on cost. You want to follow Google-recommended practices. What should you do?
    1. Create a Cloud Function to create an instance template.
    2. Create a snapshot schedule for the disk using the desired interval.
    3. Create a cron job to create a new disk from the disk using gcloud.
    4. Create a Cloud Task to create an image and export it to Cloud Storage.
  2. Your application is running on Compute Engine and you need to take point-in-time backups of your Persistent Disk that allow restoration within seconds. The backup must be stored locally for fastest recovery. Which solution should you use?
    1. Create a standard snapshot and store it in the same region.
    2. Create an archive snapshot for long-term storage.
    3. Create an instant snapshot of the disk.
    4. Create a machine image of the entire VM.
  3. You need to retain disk backups for compliance purposes for 2 years, and you rarely need to access them. You want the lowest cost option. What should you do?
    1. Create standard snapshots on a schedule.
    2. Create archive snapshots of the disk.
    3. Create instant snapshots and convert them to standard snapshots.
    4. Export disk images to Cloud Storage Coldline.
  4. You are performing a software upgrade on a Compute Engine VM and want a rapid rollback option if the upgrade fails. You need to restore the disk state in seconds. What is the recommended approach?
    1. Create a standard snapshot before the upgrade.
    2. Create a machine image before the upgrade.
    3. Create an instant snapshot before the upgrade.
    4. Clone the disk before the upgrade.
  5. You delete a snapshot from an incremental chain. What happens to the data that is needed by subsequent snapshots?
    1. The data is permanently lost.
    2. The data is moved to the next snapshot in the chain.
    3. All dependent snapshots are also deleted.
    4. The source disk is updated with the snapshot data.
  6. You need to ensure your Compute Engine disk snapshots comply with data residency requirements and are restricted to a specific region. What should you do?
    1. Store globally scoped snapshots in a regional location.
    2. Use instant snapshots which are stored in the same zone.
    3. Create regionally scoped snapshots with restricted creation and restore locations.
    4. Use archive snapshots with a specific storage location.

References

AWS Elastic Block Store Storage – EBS

~ Last updated on : ~ jayendrapatil ~ 61 Comments

EC2 Elastic Block Store – EBS

  • Elastic Block Store – EBS provides highly available, reliable, durable, block-level storage volumes that can be attached to an EC2 instance.
  • EBS as a primary storage device is recommended for data that requires frequent and granular updates e.g. running a database or filesystem.
  • An EBS volume
    • behaves like a raw, unformatted, external block device that can be attached to a single EC2 instance at a time (except with Multi-Attach enabled io1/io2 volumes).
    • persists independently from the running life of an instance.
    • is Zonal and can be attached to any instance within the same Availability Zone and can be used like any other physical hard drive.
    • is particularly well-suited for use as the primary storage for file systems, databases, or any applications that require fine granular updates and access to raw, unformatted, block-level storage.
    • is designed for 99.999% availability and offers 99.999% durability for io2 Block Express volumes (0.001% annual failure rate).

Elastic Block Storage Features

  • EBS Volumes are created in a specific Availability Zone and can be attached to any instance in that same AZ.
  • Volumes can be backed up by creating a snapshot of the volume, which is stored in S3.
  • Volumes can be created from a snapshot that can be attached to another instance within the same region.
  • Volumes can be made available outside of the AZ by creating and restoring the snapshot to a new volume anywhere in that region.
  • Snapshots can also be copied to other regions and then restored to new volumes, making it easier to leverage multiple AWS regions for geographical expansion, data center migration, and disaster recovery.
  • Volumes allow encryption using the EBS encryption feature. All data stored at rest, disk I/O, and snapshots created from the volume are encrypted.
  • Encryption occurs on the EC2 instance, providing encryption of data-in-transit from EC2 to the EBS volume.
  • Elastic Volumes help easily adapt the volumes as the needs of the applications change. Elastic Volumes allow you to dynamically increase capacity, tune performance, and change the type of any new or existing current generation volume with no downtime or performance impact.
  • You can dynamically increase size, modify the provisioned IOPS capacity, and change volume type on live production volumes.
  • EBS now supports up to four Elastic Volumes modifications per volume within a rolling 24-hour window (previously required a 6-hour cooldown between modifications). A new modification can be initiated as soon as the previous one completes.
  • General Purpose SSD (gp3) volumes support up to 80,000 IOPS and 2,000 MiB/s of throughput with up to 64 TiB capacity (increased from 16,000 IOPS, 1,000 MiB/s, and 16 TiB in September 2025).
  • Provisioned IOPS SSD (io2 Block Express) volumes support up to 256,000 IOPS and 4,000 MB/s of throughput with up to 64 TiB capacity and sub-millisecond latency.

EBS Benefits

  • Data Availability
    • Data is automatically replicated in an Availability Zone to prevent data loss due to the failure of any single hardware component.
    • io2 Block Express volumes are designed for 99.999% durability (0.001% annual failure rate), while other volume types provide 99.8%-99.9% durability.
  • Data Persistence
    • persists independently of the running life of an EC2 instance
    • persists when an instance is stopped, started, or rebooted
    • Root volume is deleted, by default, on Instance termination but the behaviour can be changed using the DeleteOnTermination flag
    • All attached volumes persist, by default, on instance termination
  • Data Encryption
    • can be encrypted by the EBS encryption feature
    • uses 256-bit AES-256 and an Amazon-managed key infrastructure.
    • Encryption occurs on the server that hosts the EC2 instance, providing encryption of data-in-transit from the EC2 instance to EBS storage
    • Snapshots of encrypted EBS volumes are automatically encrypted.
    • EBS encryption by default can be enabled at the account level per region, so all new volumes created are automatically encrypted.
  • Snapshots
    • 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.
    • can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones or Regions.
    • are incremental backups and store only the data that was changed from the time the last snapshot was taken.
    • 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 Volume Types

Refer blog post @ EBS Volume Types

EBS Volume

EBS Volume Creation

  • Creating New volumes
    • Completely new from console or command line tools and can then be attached to an EC2 instance in the same Availability Zone.
  • Restore volume from Snapshots
    • Volumes can also be restored from previously created snapshots
    • New volumes created from existing snapshots are loaded lazily in the background.
    • There is no need to wait for all of the data to transfer from S3 to the volume before the attached instance can start accessing the volume and all its data.
    • If the instance accesses the data that hasn’t yet been loaded, the volume immediately downloads the requested data from S3, and continues loading the rest of the data in the background.
    • Volumes restored from encrypted snapshots are always encrypted, by default.
    • Provisioned Rate for Volume Initialization (May 2025) allows specifying an initialization rate (up to 300 MiB/s) to accelerate the transfer of snapshot data to new volumes, ensuring fully performant volumes within a predictable time frame.
  • Volumes can be created and attached to a running EC2 instance by specifying a block device mapping

EBS Volume Clones (Oct 2025)

  • EBS Volume Clones allow creating instant point-in-time copies of EBS volumes within the same Availability Zone with a single API call.
  • Cloned volumes are available within seconds and provide immediate access to data with single-digit millisecond latency.
  • Data is copied lazily in the background without impacting the performance of the source volume.
  • Eliminates the previous multi-step process of taking snapshots and creating volumes from them for same-AZ copies.
  • Useful for quickly setting up test/development environments with production data.

EBS Volume Detachment

  • EBS volumes can be detached from an instance explicitly or by terminating the instance.
  • EBS root volumes can be detached by stopping the instance.
  • EBS data volumes, attached to a running instance, can be detached by unmounting the volume from the instance first.
  • If the volume is detached without being unmounted, it might result in the volume being stuck in a busy state and could possibly damage the file system or the data it contains.
  • EBS volume can be force detached from an instance, using the Force Detach option, but it might lead to data loss or a corrupted file system as the instance does not get an opportunity to flush file system caches or file system metadata.
  • Charges are still incurred for the volume after its detachment

EBS Volume Deletion

  • EBS volume deletion would wipe out its data and the volume can’t be attached to any instance. However, it can be backed up before deletion using EBS snapshots
  • Recycle Bin for EBS Volumes (Nov 2025) allows setting retention periods for deleted volumes. Deleted volumes can be recovered within the retention period with all attributes (tags, permissions, encryption status) preserved.

EBS Volume Resize

  • EBS Elastic Volumes can be modified to increase the volume size, change the volume type, or adjust the performance of your EBS volumes.
  • If the instance supports Elastic Volumes, changes can be performed without detaching the volume or restarting the instance.
  • Volumes can be modified up to four times within a rolling 24-hour window (enhanced Jan 2026, previously limited to one modification with a 6-hour cooldown).

EBS Volume Snapshots

Refer blog post @ EBS Snapshot

EBS Snapshot Lock

  • EBS Snapshot Lock (Nov 2023) enables locking snapshots to protect them from inadvertent or malicious deletions for compliance and data retention requirements.
  • Snapshots can be locked for a duration ranging from 1 day to approximately 100 years.
  • Supports WORM (Write Once Read Many) compliance requirements.
  • Locked snapshots cannot be deleted until the lock duration expires.
  • No additional cost for locking snapshots.

EBS Snapshots Archive

  • EBS Snapshots Archive provides a low-cost storage tier for long-term retention of rarely-accessed snapshots.
  • Up to 75% lower cost compared to standard snapshot storage.
  • Archived snapshots can be restored when needed (restoration takes 24-72 hours).
  • Amazon Data Lifecycle Manager can automate archival and retention policies.

Recycle Bin for Snapshots

  • Recycle Bin enables restoration of accidentally deleted EBS Snapshots and EBS-backed AMIs.
  • Supports customized delete protection with exclusion tags (Nov 2024) to exclude non-critical resources.
  • Supports CloudFormation for managing Recycle Bin rules (Nov 2024).
  • Supports IPv6 endpoints (Dec 2024).
  • Now also supports EBS Volumes (Nov 2025) in addition to snapshots and AMIs.

EBS Encryption

  • EBS volumes can be created and attached to a supported instance type and support the following types of data
    • Data at rest
    • All disk I/O i.e All data moving between the volume and the instance
    • All snapshots created from the volume
    • All volumes created from those snapshots
  • Encryption occurs on the servers that host EC2 instances, providing encryption of data-in-transit from EC2 instances to EBS storage.
  • EBS encryption is supported with all EBS volume types (gp3, gp2, io2, io1, st1, and sc1), and has the same IOPS performance on encrypted volumes as with unencrypted volumes, with a minimal effect on latency
  • EBS encryption is available on all current generation instance types and select previous generation types.
  • Volumes created from encrypted snapshots and snapshots of encrypted volumes are automatically encrypted using the same encryption key.
  • EBS encryption uses AWS KMS keys (formerly called customer master keys/CMK) when creating encrypted volumes and any snapshots created from the encrypted volumes.
  • EBS volumes can be encrypted using either
    • the AWS managed key (aws/ebs) created for you automatically in each region.
    • a customer managed key that you created separately using AWS KMS, giving you more flexibility, including the ability to create, rotate, disable, define access controls, and audit the encryption keys used to protect your data.
  • Encryption by default can be enabled at the account level per region. When enabled, all new EBS volumes and snapshot copies are automatically encrypted.
  • Public or shared snapshots of encrypted volumes are not supported, because other accounts would be able to decrypt your data and needs to be migrated to an unencrypted status before sharing.
  • Existing unencrypted volumes cannot be encrypted directly, but can be migrated by
    • Option 1
      • create an unencrypted snapshot from the volume
      • create an encrypted copy of an unencrypted snapshot
      • create an encrypted volume from the encrypted snapshot
    • Option 2
      • create an unencrypted snapshot from the volume
      • create an encrypted volume from an unencrypted snapshot (selecting encryption during volume creation)
  • An encrypted snapshot can be created from an unencrypted snapshot by creating an encrypted copy of the unencrypted snapshot.
  • Unencrypted volume cannot be created from an encrypted volume directly but needs to be migrated

EBS Multi-Attach

  • EBS Multi-Attach allows attaching a single Provisioned IOPS SSD (io1 or io2) volume to up to 16 Nitro System-based EC2 instances within the same Availability Zone.
  • All attached instances have full read and write access to the shared volume.
  • io2 Block Express volumes support NVMe reservations for I/O fencing, enabling shared storage with proper coordination between instances (enabled by default for io2 volumes created after Sept 18, 2023).
  • Multi-Attach can be enabled for io2 volumes after creation (if not attached to any instances). For io1, it must be enabled at creation time.
  • Requires a cluster-aware file system (not standard XFS or EXT4) for data resiliency in production.

Refer blog Post @ EBS Multi-Attach

EBS Performance

Refer blog Post @ EBS Performance

EBS vs Instance Store

Refer blog post @ EBS vs Instance Store

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.
  1. _____ is a durable, block-level storage volume that you can attach to a single, running Amazon EC2 instance.
    1. Amazon S3
    2. Amazon EBS
    3. None of these
    4. All of these
  2. Which Amazon storage do you think is the best for my database-style applications that frequently encounter many random reads and writes across the dataset?
    1. None of these.
    2. Amazon Instance Storage
    3. Any of these
    4. Amazon EBS
  3. What does Amazon EBS stand for?
    1. Elastic Block Storage
    2. Elastic Business Server
    3. Elastic Blade Server
    4. Elastic Block Store
  4. Which Amazon Storage behaves like raw, unformatted, external block devices that you can attach to your instances?
    1. None of these.
    2. Amazon Instance Storage
    3. Amazon EBS
    4. All of these
  5. A user has created numerous EBS volumes. What is the general limit for each AWS account for the maximum number of EBS volumes that can be created?
    1. 10000
    2. 5000
    3. 100
    4. 1000
  6. Select the correct set of steps for exposing the snapshot only to specific AWS accounts
    1. Select Public for all the accounts and check mark those accounts with whom you want to expose the snapshots and click save.
    2. Select Private and enter the IDs of those AWS accounts, and click Save.
    3. Select Public, enter the IDs of those AWS accounts, and click Save.
    4. Select Public, mark the IDs of those AWS accounts as private, and click Save.
  7. If an Amazon EBS volume is the root device of an instance, can I detach it without stopping the instance?
    1. Yes but only if Windows instance
    2. No
    3. Yes
    4. Yes but only if a Linux instance
  8. Can we attach an EBS volume to more than one EC2 instance at the same time?
    1. Yes, with Multi-Attach enabled io1/io2 volumes to up to 16 Nitro-based instances in the same AZ
    2. No
    3. Only EC2-optimized EBS volumes.
    4. Only in read mode.

    Note: This answer has been updated. EBS Multi-Attach (available since 2020) allows io1/io2 volumes to be attached to up to 16 Nitro-based instances simultaneously within the same AZ.

  9. Do the Amazon EBS volumes persist independently from the running life of an Amazon EC2 instance?
    1. Only if instructed to when created
    2. Yes
    3. No
  10. Can I delete a snapshot of the root device of an EBS volume used by a registered AMI?
    1. Only via API
    2. Only via Console
    3. Yes
    4. No
  11. By default, EBS volumes that are created and attached to an instance at launch are deleted when that instance is terminated. You can modify this behavior by changing the value of the flag_____ to false when you launch the instance
    1. DeleteOnTermination
    2. RemoveOnDeletion
    3. RemoveOnTermination
    4. TerminateOnDeletion
  12. Your company policies require encryption of sensitive data at rest. You are considering the possible options for protecting data while storing it at rest on an EBS data volume, attached to an EC2 instance. Which of these options would allow you to encrypt your data at rest? (Choose 3 answers)
    1. Implement third party volume encryption tools
    2. Do nothing as EBS volumes are encrypted by default
    3. Encrypt data inside your applications before storing it on EBS
    4. Encrypt data using native data encryption drivers at the file system level
    5. Implement SSL/TLS for all services running on the server
  13. 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
  14. How can you secure data at rest on an EBS volume?
    1. Encrypt the volume using the S3 server-side encryption service
    2. Attach the volume to an instance using EC2’s SSL interface.
    3. Create an IAM policy that restricts read and write access to the volume.
    4. Write the data randomly instead of sequentially.
    5. Use an encrypted file system on top of the EBS volume
  15. A user has deployed an application on an EBS backed EC2 instance. For a better performance of application, it requires dedicated EC2 to EBS traffic. How can the user achieve this?
    1. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    2. Launch the EC2 instance as EBS enhanced with PIOPS EBS
    3. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    4. Launch the EC2 instance as EBS optimized with PIOPS EBS
  16. A user is trying to launch an EBS backed EC2 instance under free usage. The user wants to achieve encryption of the EBS volume. How can the user encrypt the data at rest?
    1. Use AWS EBS encryption to encrypt the data at rest (EBS encryption is supported on all current generation instance types including t2/t3 micro)
    2. User cannot use EBS encryption and has to encrypt the data manually or using a third party tool
    3. The user has to select the encryption enabled flag while launching the EC2 instance
    4. Encryption of volume is not available as a part of the free usage tier
  17. 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
    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
  18. A user has launched an EBS backed EC2 instance. The user has rebooted the instance. Which of the below mentioned statements is not true with respect to the reboot action?
    1. The private and public address remains the same
    2. The Elastic IP remains associated with the instance
    3. The volume is preserved
    4. The instance runs on a new host computer
  19. A user has launched an EBS backed EC2 instance. What will be the difference while performing the restart or stop/start options on that instance?
    1. For restart it does not charge for an extra hour, while every stop/start it will be charged as a separate hour
    2. Every restart is charged by AWS as a separate hour, while multiple start/stop actions during a single hour will be counted as a single hour
    3. For every restart or start/stop it will be charged as a separate hour
    4. For restart it charges extra only once, while for every stop/start it will be charged as a separate hour
  20. A user has launched an EBS backed instance. The user started the instance at 9 AM in the morning. Between 9 AM to 10 AM, the user is testing some script. Thus, he stopped the instance twice and restarted it. In the same hour the user rebooted the instance once. For how many instance hours will AWS charge the user?
    1. 3 hours
    2. 4 hours
    3. 2 hours
    4. 1 hour
  21. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  22. An organization wants to move to Cloud. They are looking for a secure encrypted database storage option. Which of the below mentioned AWS functionalities helps them to achieve this?
    1. AWS MFA with EBS
    2. AWS EBS encryption
    3. Multi-tier encryption with Redshift
    4. AWS S3 server-side storage
  23. A user has stored data on an encrypted EBS volume. The user wants to share the data with his friend’s AWS account. How can user achieve this?
    1. Create an AMI from the volume and share the AMI
    2. Copy the data to an unencrypted volume and then share
    3. Take a snapshot and share the snapshot with a friend
    4. If both the accounts are using the same encryption key then the user can share the volume directly
  24. A user is using an EBS backed instance. Which of the below mentioned statements is true?
    1. The user will be charged for volume and instance only when the instance is running
    2. The user will be charged for the volume even if the instance is stopped
    3. The user will be charged only for the instance running cost
    4. The user will not be charged for the volume if the instance is stopped
  25. A user is planning to use EBS for his DB requirement. The user already has an EC2 instance running in the VPC private subnet. How can the user attach the EBS volume to a running instance?
    1. The user must create EBS within the same VPC and then attach it to a running instance.
    2. The user can create EBS in the same zone as the subnet of instance and attach that EBS to instance. (Should be in the same AZ)
    3. It is not possible to attach an EBS to an instance running in VPC until the instance is stopped.
    4. The user can specify the same subnet while creating EBS and then attach it to a running instance.
  26. A user is creating an EBS volume. He asks for your advice. Which advice mentioned below should you not give to the user for creating an EBS volume?
    1. Take the snapshot of the volume when the instance is stopped
    2. Stripe multiple volumes attached to the same instance
    3. Create an AMI from the attached volume (AMI is created from the snapshot)
    4. Attach multiple volumes to the same instance
  27. An EC2 instance has one additional EBS volume attached to it. How can a user attach the same volume to another running instance in the same AZ?
    1. Terminate the first instance and only then attach to the new instance
    2. Attach the volume as read only to the second instance
    3. Detach the volume first and attach to new instance
    4. No need to detach. Just select the volume and attach it to the new instance, it will take care of mapping internally
  28. What is the scope of an EBS volume?
    1. VPC
    2. Region
    3. Placement Group
    4. Availability Zone

Additional Practice Questions (Updated 2025-2026)

  1. A company wants to create instant copies of their EBS volumes for testing purposes within the same Availability Zone without using snapshots. Which feature should they use?
    1. EBS Fast Snapshot Restore
    2. EBS Snapshot Copy
    3. EBS Volume Clones
    4. EBS Multi-Attach
  2. Which EBS volume type provides sub-millisecond latency, up to 256,000 IOPS, and 99.999% durability?
    1. gp3
    2. io1
    3. io2 Block Express
    4. gp2
  3. A company needs to protect their EBS snapshots from accidental or malicious deletion to meet regulatory compliance requirements. Which feature should they use?
    1. EBS Encryption
    2. Recycle Bin
    3. AWS Backup
    4. EBS Snapshot Lock
  4. What is the maximum size, IOPS, and throughput for a gp3 volume as of September 2025?
    1. 16 TiB, 16,000 IOPS, 1,000 MiB/s
    2. 64 TiB, 64,000 IOPS, 4,000 MiB/s
    3. 64 TiB, 80,000 IOPS, 2,000 MiB/s
    4. 32 TiB, 32,000 IOPS, 2,000 MiB/s
  5. A team needs to accelerate the initialization of hundreds of EBS volumes from snapshots for a large-scale deployment. Which feature ensures predictable initialization times?
    1. EBS Fast Snapshot Restore
    2. Provisioned Rate for Volume Initialization
    3. EBS Volume Clones
    4. EBS Elastic Volumes
  6. How many times can you modify an EBS volume within a rolling 24-hour window? (as of Jan 2026)
    1. 1 time with 6-hour cooldown
    2. 2 times
    3. 4 times
    4. Unlimited
  7. Which of the following statements about EBS Multi-Attach is correct? (Choose 2)
    1. Multi-Attach is supported on io1 and io2 Provisioned IOPS volumes
    2. Multi-Attach allows attachment to instances across multiple Availability Zones
    3. Multi-Attach enabled volumes can be attached to up to 16 Nitro-based instances
    4. Multi-Attach is supported on gp3 volumes

Reference

Amazon EBS User Guide