Ref: https://learn.cantrill.io/courses/1820301/lectures/41301326

• Summary
• Contents:

EBS Snapshots - Characteristics

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0900-ELASTIC_COMPUTE_CLOUD(EC2)/00_LEARNINGAIDS/EBSSnapshots-1.png

• 🔧 EBS snapshots are backups of EBS volumes stored in S3
  • AZ resiliency (EBS) upgraded to region resiliency (S3)
  • Snapshots can be restored cross-AZ and cross-region → supports migrations
• ‼️ 👍 Great feature: Snapshots only copy used data, not the whole allocated data!!
  • EBS volume has a size of 40GB but has only filled up 10GB → full snapshot size = 10GB
  • You only get billed for used data, not whole allocated data of EBS volume
• ❗ Incremental volume copies
  • First snapshot is a full copy of the used data on an EBS volume
    • Can take some time, depending on size of data
  • Future snapshots are incremental
    • Reference previous snapshot → store only the difference between state of the volume now and previous snapshot
    • Consume much less space than original snapshot
    • Significantly quicker to perform than original snapshot
    • Original snapshot + incremental differences = Full backup of current volume state
  • EBS performance NOT impacted during any snapshot creation
  • ‼️ NB: Traditional incremental backups have the risk of losing backups if an intermediary incremental backup gets deleted (not able to track the differences any more). NOT the case for EBS snapshots!!
    • EBS is smart enough to update incremental snapshots to be functional if one intermediary incremental snapshot is deleted
    • Each snapshot can be hence thought of as self sufficient (even if incremental)
• Snapshots can be copied (restored) to other AZs or regions
  • 👍 Can be used as a migration tool
  • 👍 Can be used for global DR processes
• Billed for GB/month
  • One 2GB snapshot stored for a month costs the same as one 4GB snapshot stored for 15 days, etc.
  • 👍 Because snapshots are small, you can perform them regularly
    • Snapshots are incremental & only store used data → only updated data is charged
    • One snapshot per 5 mins will probably not cost much more than one per hour
• EBS encryption influences snapshots

EBS Snapshot Restore Performance & FSR

• EBS volumes can be created empty or restored from snapshots (clone volumes)
  • Create a new, blank EBS volume (without snapshot) → No need for initialization process → full performance immediately
  • Create/Restore an EBS volume from a snapshot → Lazy restore
    • Data fetched gradually → it can take a while to have all the snapshot data available in the new volume
    • 👎 Requesting not-yet-fetched blocks will prompt immediate fetching from S3, BUT that has lower performance than reading from EBS directly
• If production requires full performance immediately → Two options to restore volumes faster:
  1. Manually force a read of all data (with tools like e.g. DD on Linux)
     • Read all blocks one by one in the newly restored volume → forces fetching from S3
     • Do before using the volume in production, then performance is optimal
     • 👎 Requires admin overhead
  2. Fast Snapshot Restore (FSR)
     • Snapshot option that makes it instantly restore if enabled
     • Limit: up to 50 snapshot-AZ pairs per region
       • One snapshot set to restore on four AZs means 4 consumed out of 50
     • 👎 Costs extra
       • Can get expensive, especially if you enable it for many snapshots
       • If it's a concern → manual force read of data brings same end result (with some extra admin overhead)