EBS Snapshots | Overview & Hands-On.

An Overview & Hands-On for EBS Snapshots.

Focus,

• Tailored for DevOps.

Breakdown:

• Intro,
• Key Features and How EBS Snapshots Work,
• Common Use Cases,
• Considerations,
• Key Benefits of EBS Snapshots,
• Reasos to detach EBS volume before creating Snapshots (NOT necessary BUT still recommended)
• Architecture of EBS Snapashot
• Best Practices & Summary table of best Practices,
• Cross-Region Snapshots Copy,
• Cross-Account Snapshot Sharing,
• Restore Snapshot to Volume in Target Region/Account,
• How to Handles Encryption for Snapshots,
• How to enable a retention rule before deleting snapshots,
• How to recover deleted volume snapshots from bin (UI & CLI),
• Tips to mitigate Accidental Deletion of Snapshot,
• Quick Overview of AWS Snapshots Tpyes,
• Project: Hands-On,
• twtech Final thoughts.

Intro:

• EBS snapshots are incremental, point-in-time backups of Amazon Elastic Block Store (EBS) volumes, used for data protection, disaster recovery, and data migration within the AWS cloud. The snapshots are stored securely in Amazon S3 for high durability and availability.
• An EBS Snapshot is a point-in-time backup of an Amazon Elastic Block Store (EBS) volume. Snapshots are stored in Amazon S3 (although not directly accessible from S3), and they are used to back up data or create new EBS volumes.
• Snapshots are incremental—only the blocks that have changed since the last snapshot are saved, making them storage-efficient.

Key Features and How EBS Snapshots Work

Incremental Backups:

•  The first snapshot is a full copy of all data blocks written to the volume.
• Subsequent snapshots only save the blocks that have changed since the previous snapshot, making them cost-effective and efficient for regular backups.

Storage:

•  Although stored in Amazon S3, users cannot access the underlying S3 buckets directly via the S3 console or API; management is done through the EC2 console or APIs.

Restoration: 

• A snapshot contains all the information needed to restore a volume to its state at the moment the snapshot was taken. 
• When a new volume is created from a snapshot, data is "lazily loaded" in the background, meaning the volume is available almost immediately, but performance may be impacted for uninitialized blocks until all data is transferred.

Encryption: 

• Snapshots automatically inherit the encryption status of their source volume. Encrypted snapshots use AWS Key Management Service (KMS) for key management, ensuring data security at rest.

Automation:

•  The creation, retention, and deletion of snapshots can be automated using AWS Data Lifecycle Manager (DLM) or AWS Backup, which helps enforce backup policies and manage costs.

Common Use Cases

Disaster Recovery: 

• Snapshots can be copied across Availability Zones and AWS Regions, providing a robust solution for cross-regional disaster recovery.

Data Migration:

•  They facilitate easy migration of data across different regions, accounts, or even from on-premises environments to AWS.

Development and Testing:

•  Snapshots allow developers to create copies of production environments for testing without affecting the live system.

Use Cases summary

• Backup and Restore
• Dev/Test Environment Cloning
• Volume Migration Across AZs or Regions
• Compliance and Audit Readiness
• Data Recovery in CI/CD Pipelines
•  Not necessary to detach volume to do snapshot, but recommended. 

Considerations

Application Consistency:

•  By default, snapshots are crash-consistent, meaning they capture the disk state at a point in time, which may not include data cached in memory by applications. 
• For database-intensive applications, AWS recommends pausing writes, unmounting the volume, or using application-consistent snapshots via AWS Systems Manager (SSM) agent integration to ensure data integrity.

Cost Management:

•  While incremental backups are cost-effective, accumulating numerous snapshots over time can increase costs. 
• Implementing retention policies and using the EBS Snapshot Archive tier for long-term, seldom-accessed data can help optimize expenses. 

Architecture of EBS Snapashots.

 

Key Benefits of EBS Snapshots

Data Backup and Disaster Recovery

• Protects data against accidental deletion, corruption, or failure.
• Can be used to restore EBS volumes quickly in the same or different Availability Zones or regions.

Incremental Backup

• After the first full snapshot, only changed blocks are saved.
• This reduces storage cost and backup time.

Fast Volume Creation

• twtech can launch a new EBS volume from a snapshot in minutes, enabling fast scaling and deployment.

Cross-Region and Cross-Account Copy

• Snapshots can be copied to other AWS regions or shared across AWS accounts.
• Helps with geo-redundancy, compliance, and cross-account workflows.

Automation with Lifecycle Policies

• Use Amazon Data Lifecycle Manager (DLM) to automate snapshot creation, retention, and deletion.
• Simplifies management and ensures compliance with backup policies.

Cost-Efficient

• Because they're incremental, snapshots are more storage-efficient than full disk clones.

Supports Encryption

• Snapshots of encrypted volumes are encrypted.
• twtech can also copy unencrypted snapshots to create encrypted versions, helping with data security and compliance.

Reasos to detach EBS volume before creating Snapshots (NOT necessary BUT still recommended)

 Recommended Because:

Although technically allowed, detaching the volume (or freezing I/O) is recommended for data consistency, especially for:

 File Systems and Databases

• If twtech snapshot a volume while a database or file system is writing data, it may end up with inconsistent or corrupted data (e.g., incomplete transactions, unflushed file system buffers).
• Think of it like pulling a hard drive out of a computer while it's still writing.
• The blocks might be consistent, but logical files or databases might not be accessible.

Not Necessary Because:

Amazon EBS supports online snapshots—twtech can take a snapshot of a volume while it is attached and in use. 

This is possible because:

• The snapshot captures a point-in-time copy of the data blocks.
• AWS ensures crash-consistent snapshots at the block level.
• This means it captures the data as it exists at that moment—even if the volume is actively being written to.

Best Practices:

• Flush I/O buffers (e.g., use fsfreeze on Linux or sync).
• Stop services or pause the application briefly before snapshotting.
• (Optional) detach the volume to ensure no writes occur at all during snapshot.

Summary table of best Practices

Action	Consistency Level	Recommended When
Snapshot attached, active volume	Crash-consistent only	Low-write workloads,  non-critical data
Snapshot after flushing buffers	Application-consistent	Most workloads
Snapshot after detaching volume	Fully consistent	Critical data, databases,  compliance-sensitive backups

Types of EBS Snapshot Migration 1. Cross-Region Snapshot. Copy an EBS snapshot from one AWS Region to another. Benefits: Disaster recovery / backup in a different region Compliance with data residency laws Enable creation of volumes in other regions AWS CLI  #  bash aws ec2 copy-snapshot \   --source-region us-east-1 \   --source-snapshot-id snap-0123456789abcxxxx \   --destination-region us-east-2 \   --description "Copy to us-east-1" 2. Cross-Account Snapshot Sharing Share snapshots with other AWS accounts by modifying snapshot permissions. Benefits: Centralized backup management Sharing data across teams or organizations Migrating workloads between accounts AWS CLI : twech Makes a snapshot public or share with a specific account: #   bash aws ec2 modify-snapshot-attribute \   --snapshot-id snap-0123456789abcdxxx \   --attribute createVolumePermission \   --operation-type add \   --user-ids 123456789xxx NB:  twtech cannot share encrypted snapshots directly unless using an AWS KMS key shared with the target account. 3. Restore Snapshot to Volume in Target Region/Account Once the snapshot is copied/shared, twtech can create a new volume from it: #   bash aws ec2 create-volume \   --snapshot-id snap-abcdef1234567xxx \   --availability-zone us-east-2a \   --volume-type gp3  How twech Handles Encryption for Snapshots twtech can copy encrypted snapshots across regions, but the KMS key must be accessible in the destination region. For cross-account copies of encrypted snapshots: Share the KMS key with the target account. Re-encrypt with a new key during copy if needed. twtech-Best Practices Tag snapshots with metadata (e.g., source, date, purpose). Use automation tools like AWS Data Lifecycle Manager or AWS Backup. Monitor snapshot copy status with CloudWatch or AWS Config. Secure snapshots using encryption and IAM policies. EBS Snapshots Features • twtech may move EBS Snapshot to Archive.(storage for snapshots)   Moving Snapshots to an ”archive” would be 75% cheaper for twtech to manage (cost efficiency)  Sometimes It takes twtech, between  24 up to 72 hours for the EBS Snapshots to be fully restored from the archive.   For safety, twtech always delete EBS Snapshots into a bin, so that  those deleted snapshots may be restored if need arise.  twtech creates retention rules to retain deleted snapshots so they may recover them if accidental deleted  twtech may specify retention period for deleted snapshots from day-1 up to 1 year.  How twtech recoveres deleted volume snapshots from bin. Step-by-step: UI & CLI NB: EBS snapshots cannot be recovered once permanently deleted. There is no "Recycle Bin" for snapshots by default ...deletion is immediate and irreversible, unless twtech explicitly enable the AWS Recycle Bin feature before deletion. Step-1: twech Enabled AWS Recycle Bin The concept: AWS Recycle Bin AWS Recycle Bin lets twtech to retain deleted EBS snapshots for a specified time (retention period), even after they are deleted. twtech must enable a retention rule before the deleting snapshots, This Works for any twtech EBS snapshots and AMIs. This allows EBS Snapshots go to a "recoverable" state during the retention period. Step-2:  How twtech Recovers Snapshots from Recycle Bin If a snapshot was deleted after a Recycle Bin rule was applied: GUI Go to EC2 Console → Snapshots Change the filter to: State: recoverable Select the snapshot to restore Click Recover Snapshot Or twtech may use the:  AWS CLI: #  bash  aws rbin restore-snapshot \   --snapshot-id snap-0abcdef12345xxx NB:  This only works if the snapshot is within the retention window.  If Recycle Bin Was Not Enabled Before Deletion There is no way to recover a permanently deleted snapshot. twtech key options: Look for older snapshots or AMIs. Check if AWS Backup was used (which has its own retention). Restore from application-level backups (e.g., RDS snapshots, S3, or database backups).  twtech tips to mitigate Accidental Deletion, Use Recycle Bin retention rules for all snapshots. Tag critical snapshots with "DoNotDelete" and enforce IAM policies. Automate backups with AWS Backup or Lifecycle Manager. Monitor deletions with CloudTrail logs. Quick Overview of AWS Snapshots Tpyes Types of AWS Snapshots In AWS, the term "snapshot" usually refers to backups of data volumes or machine images, but different services support various kinds of snapshots.  Below are the main types categorized by service:  1. EBS Snapshots (Amazon Elastic Block Store) Type: Point-in-time backup of EBS volumes Storage: Stored in Amazon S3 (not user-visible) Features: Incremental Can be encrypted Can be copied across regions/accounts Supports Recycle Bin (optional)  Use case:  Backup EC2 instance storage, DR, cloning environments.  2. EC2 AMI Snapshots Type: Image-based backup that includes EBS snapshot(s) and instance metadata Components: EBS volume snapshots (root + data volumes) Launch config (instance type, networking, permissions, etc.)  Use case: Launch pre-configured EC2 instances from saved images.  3. RDS Snapshots (Relational Database Service) Types: Automated Snapshots: Managed by AWS (retention based on backup window) Manual Snapshots: User-created, retained until explicitly deleted  Use case: Point-in-time recovery of RDS databases.  4. Redshift Snapshots Types: Automated Snapshots Manual Snapshots Can be copied across regions and accounts.  Use case: Backup and restore Redshift data warehouses.  5. Amazon FSx Snapshots Supports snapshots for: Amazon FSx for Windows File Server Amazon FSx for Lustre Amazon FSx for NetApp ONTAP  Use case: File-level recovery or full file system restore.  6. Amazon EFS (Elastic File System) Backup (via AWS Backup) Not snapshots per se, but AWS Backup lets twtech to take scheduled backups (which act like snapshots). twtech can create restore points and recover data to a new file system. Use case: Versioned backup of NFS file systems.  7. AWS Backup Snapshots A centralized backup service that supports: EBS, RDS, DynamoDB, EFS, FSx, EC2, Storage Gateway These backups are policy-driven and stored in a centralized Backup Vault. Use case: Centralized, policy-managed backups across services. Summary Table of AWS snapshot types: Service Snapshot Type Incremental Manual/Auto Cross-Region EBS Volume Snapshots ✅ Yes ✅ Both ✅ Yes EC2 AMI (uses EBS) ✅ Yes ✅ Manual ✅ Yes RDS DB Snapshots ✅ Yes ✅ Both ✅ Yes Redshift Cluster Snapshots ✅ Yes ✅ Both ✅ Yes FSx File System ✅ Yes ✅ Both ✅ Some types EFS Backup via AWS Backup ❌ (not traditional snapshot) ✅ Both ✅ Yes AWS Backup Multi-service Depends on service ✅ Both ✅ Yes Preject: Hands-on How twtech migrate EBS Snaphots to other regions within its AWS Landscape (environment): UI Step-1: twtech Goes to EC2 UI (console) & select:  EBS / Volumes. Step-2: twtech Selects a volume and Create a snapshot ( EBS-twtech-web-server) Assign a description for the EBS Snapshot: twtech-web-server-SnapShot Step-3: twtech Assigns a tag for the snapshots: Let tag describe snapshot Sample Name: twtech-web-server-SnapShot-do-not-delete-april-05-2025 Create Snapshot. Step-4: twtech Verifies that the snapshots has been created. Go to ----->  EC2-menu: navigate to  ----->  Elastic Bock Store, then  ----->  Snapshots More details for the snapshot:  twtech-web-server-SnapShot-do-not-delete-april-05-2025 Step-5: How twtech migrates (copy) snapshot to another region( from: us-east-2 to us-east-1) Copy snapshots to any destination (region) : from us-east-1 (origin) us-east-2 (Destination) Snapshot destination: us-east-1 Encrypt snapshot with kms key: aws default key Step-6: Assign a tag: Name Copied snap-of-twtech-web-server from us-east-2 to us-east-1 april-05-2025 Step-7: twtech Goes to us-east-1 (N Virginia) to verify that twtech-web-server snapshopts were successfully : (migrated from) us-east-2 (Ohio) Yes: successfully the snapshots was migrated from one region to another. Step-8: twtech needs to creates an EBS volume from EBS snapshopts in distination region (N. Virginia), then attached it to an instance in that same AZ. Create volume Select the target Availability Zone (AZ): AZ can be changed From: To: Assign a tag: Name: twtec-web-server-volume-recreated-migrated-from-us-east-2a to us-east-2b Step-9: Verify that twtech-web-server- snapshot from us-east-2a has been use to create a new twtech web-server volume in us-east-2b. Yes: successfully, twtech recreated a volume in another region from snapshots migrated from another region. Step-10: The status of the volume is still Available, and twtech needs to attach it to an instance in the same AZ (us-east-2b) Select the creatd volume, navigate to Action and Attach volume: to an instance Step-11: How twtech protects snapshots with retaintion rule from accidental deletion with:  aws Recycle Bin  Create retention rule Select the resource type for the retaintion rule: EBS Snapshots Add tag: Name: twtech-web-server-SnapShot-do-not-delete-april-05-2025 Retention period: 365 day (1year) Step-12: Rule lock settings  Lock the retention rule to prevent snapshots from being accidentally or maliciously updated or deleted. Lock setting: unlock means the rule can be later deleted  if no longer needed. Step-13: Add Tag A tag is a label that twtech assigns to an AWS resource.  Each tag consists of a key and an optional value.  twtech can use tags to search and filter its resources or track its AWS costs.  This is the tag for twtech retention rule. Before deleting snapshots,  verify the resources in the Recycle Bin ( twtech-recycle-bin) Step-14: twtech deletes ebs snapshots:  To verify if the snapshots are store in the recycle bin for later recovery (after accidental deletion) Note: If the snapshot is a standard storage tier, it can be move to an archive before deleting.  Once snapshots is archived, it will take 24 up to 72 hours to restore the snapshots. Deleting the snapashops: Confirm deletion: Step-15: twtecn verifies in the AWS Recycle bin ( twtech-recycle-bin) that the snapshots were move to the bin successesfull and should be recoverable (DR) if they were accidentally deleted.  Successfully, the EBS snapshot was deleted and stored in the aws recycle bin:  Step-16: How twtech recovers deleted snapshots from the aws recycle bin. Confirm recovery: From: To: Step-17: NB: twtech deletes snapshots from aws recycle bin finally, Once the retention rule is deleted, the snapshot will have no place to be stored: To Permanently deletes snaphots from the aws recycle bin, twtech must first delete the created retention rule.  Confirm deletion of retention rule: At this point that there is no aws retention rules ( recycle bin) if the snapshots are deleted, that will be permanent  Confirm deletion: Again, Without a retention rule created before deletion of snapshot, that is catastrophic. Permanent deletion. Final takeaway: EBS Snapshot migration generally refers to copying EBS snapshots across AWS regions or accounts.  twtech does this for disaster recovery (DR), multi-region deployment, cost optimization, or compliance. twtech creates retention rule for aws recycle bin before deleting  unwanted snapshots.