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.

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 CMK during a copy operation always results in a full copy (not incremental)

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.
• Only unencrypted snapshots can be shared. Encrypted snapshots cannot be shared between accounts or made public
• Encrypted snapshot can be shared with specific AWS accounts by sharing the custom CMK key used must also be shared to encrypt it
• Cross-account permissions may be applied to a custom 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 CMK

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 CMK compared to the source snapshot, is always a full snapshot.

EBS Snapshot Lifecycle Automation

• Amazon Data Lifecycle Manager 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.

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 encrypted snapshots (NOTE: this has be updated partially where you can share a encrypted snapshot with other accounts)
    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 <code>DeployCode</code> 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.