3.5 KiB
Elastic Block Store
Persistent block storage for EC2 Instances.
TL;DR
Real world use cases
# Clean up unused volumes.
aws ec2 describe-volumes --output 'text' --filters 'Name=status,Values=available' \
--query "Volumes[?CreateTime<'2018-03-31'].VolumeId" \
| xargs -pn '1' aws ec2 delete-volume --volume-id
Volumes can have their size increased, but not reduced.
After increase, the filesystem must be extended to take
advantage of the change in size.
Apparently, Linux machines are able to do that automatically with a reboot.
Snapshots
The first snapshot is complete, with all the volume's blocks being copied. All successive snapshots of the same
volume are incremental, with only the changes being copied.
Incremental snapshots are stored in EBS' standard tier.
Snapshots can be unbearably slow depending on the amount of data needing to be copied.
For comparison, the first snapshot of a 200 GiB volume took about 2h to complete.
Snapshots can be archived to save money should they not need frequent nor fast
retrieval.
When archived, incremental snapshots are converted to full snapshots and moved to EBS' archive tier.
The minimum archive period is 90 days.
If deleting or permanently restoring an archived snapshot before the minimum archive period, one is billed for all the remaining days in the archive tier, rounded to the nearest hour.
When access to archived snapshots is needed, they need to be restored to the standard tier before use. Restoring can take up to 72h.
Further readings
- Amazon Web Services
- What is block storage?
- AWS' CLI
- Archive Amazon EBS snapshots
- Automate snapshot lifecycles
- Choose the best Amazon EBS volume type for your self-managed database deployment
- Extend the file system after resizing an EBS volume