EBS Snapshots, Encryption, and RAID

EBS snapshots are point-in-time backups of EBS volumes stored durably in Amazon S3 (though managed by EBS, not directly accessible via the S3 console). The first snapshot is a full copy; subsequent snapshots are incremental — only the blocks that changed since the last snapshot are stored. Despite incremental storage, you can restore any single snapshot to a full volume. Snapshots are the primary mechanism for EBS volume backup, migration, and disaster recovery.

You are billed for the actual storage consumed by incremental snapshot blocks across all snapshots of a volume — not for the volume size. If you delete intermediate snapshots, S3 consolidates the data so remaining snapshots still represent complete restore points. To manage costs at scale, use Amazon Data Lifecycle Manager (DLM) to create snapshot schedules and retention policies — for example, take daily snapshots, retain the last 7 daily + 4 weekly + 12 monthly, and delete older ones automatically.

Snapshots can be copied across Regions for disaster recovery and geographic distribution. You can also share snapshots with specific AWS accounts (or make them public) to transfer EBS data across accounts without using the network. When copying a snapshot, you can change the encryption key — this is how you move data from an unencrypted volume to an encrypted one, or from a key in one account to a key in another.

Creating a volume from a snapshot is straightforward, but there is a performance consideration: volumes restored from snapshots start with all blocks stored in S3 and are lazily loaded on first access. This can cause higher latency for blocks not yet loaded into the volume. For production databases, use Fast Snapshot Restore (FSR) — a paid feature that pre-warms the snapshot so volumes are immediately at full performance. Alternatively, pre-warm by reading all blocks with dd or fio after restore.

EBS encryption uses AES-256 to encrypt data at rest (on the volume), in transit between the volume and the EC2 instance, and in snapshots. Encryption is handled transparently by the EC2 hypervisor — your application does not see any difference. Encryption uses AWS KMS keys: you can use the AWS-managed key (aws/ebs) or a customer-managed key (CMK). Once a volume is encrypted, all data written to it and all snapshots taken from it are also encrypted.

You cannot directly encrypt an existing unencrypted EBS volume. The workaround is a multi-step process: (1) create a snapshot of the unencrypted volume, (2) copy the snapshot with --encrypted to create an encrypted snapshot, (3) create a new encrypted volume from the encrypted snapshot, (4) stop the instance, detach the old volume, attach the new encrypted volume, and restart. This process can be scripted and is tested in the SAA-C03 exam as a migration scenario.

RAID 0 (striping) distributes data across multiple EBS volumes to aggregate their IOPS and throughput. Two 16,000 IOPS gp3 volumes in RAID 0 provide approximately 32,000 IOPS. The trade-off is that if either volume fails, you lose all data — there is no redundancy. RAID 0 is appropriate for temporary or easily re-created data where maximum throughput is the priority: cache layers, processing queues, or scratch space. EBS snapshots of the entire RAID array require consistency coordination.

RAID 1 (mirroring) writes identical data to two EBS volumes simultaneously. If one volume fails, the other contains a complete copy. RAID 1 provides the redundancy of two volumes with only the capacity of one. However, for EBS volumes this is generally redundant with EBS's built-in AZ-level replication. AWS recommends using EBS Multi-AZ architectures (via Multi-AZ RDS or ASG across AZs) rather than RAID 1 on EBS, since EBS already replicates within an AZ. RAID 1 on EBS is rare in modern architectures.

An Amazon Machine Image (AMI) is a blueprint for launching EC2 instances, and it is backed by one or more EBS snapshots — one snapshot per volume the AMI includes (typically one for the root volume). When you create a custom AMI from a running instance, AWS stops (or uses VSS on Windows), takes snapshots of all attached EBS volumes, and records the mapping in the AMI. Deregistering an AMI does not automatically delete its backing snapshots — you must delete the snapshots separately to stop paying for them.

Snapshot best practices for production workloads: freeze or quiesce the file system before snapshotting databases to ensure consistency (most managed databases like RDS do this automatically). Tag snapshots with environment, volume ID, and date to make lifecycle management and cost allocation easy. Test restore procedures regularly — a snapshot you have never restored is not a backup. Store cross-region copies for disaster recovery. Use AWS Backup for centralised policy management across EBS, RDS, DynamoDB, and other services.

The EBS Snapshot Recycle Bin protects against accidental deletion of snapshots and AMIs. When enabled with a retention rule, deleted snapshots are moved to the Recycle Bin instead of being permanently destroyed. You can recover them during the retention period (1 day to 1 year). This is particularly important for compliance scenarios where you must be able to recover from accidental deletion by an administrator or a runaway automation script without restoring from an older backup tier.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: EBS snapshots are incremental and stored in S3, with DLM for automated lifecycle management, encryption requires a snapshot copy workflow to convert unencrypted volumes, and RAID 0 stripes volumes for aggregated performance while RAID 1 mirrors for redundancy (though EBS already replicates within an AZ). Next up we explore EFS for shared Linux file storage.