Throughput measured in MB/s, and includes the ability to burst up to 250 MB/s per TB, with a baseline throughput of 40 MB/s per TB and a maximum throughput of 500 MB/s per volume
HDD, Cold – (sc1)
– Volume size 500 GiB – 16 TiB.
Lowest cost storage – cannot be a boot volume
– These volumes can burst up to 80 MB/s per TB, with a baseline throughput of 12 MB/s per TB and a maximum throughput of 250 MB/s per volume: HDD, Magnetic – Standard – cheap, infrequently accessed storage – lowest cost storage that can be a boot volume
EBS Snapshots
Snapshots are incremental - only the changed blocks are backed up
EBS backups use IO and we should not run them while the application is handling a lot of traffic
Snapshots are stored in S3 (we are not able to see them)
It is not necessary to detach the volume to do a snapshot, but it is recommended
An account can have up to 100k snapshots
We can make an image (AMI) out of a snapshot, snapshots can be copied across AZs
EBS volumes restored from snapshots need to be pre-warmed (using fio or dd commands to read the entire volume)
Snapshots can be automated using Amazon Data Lifecycle Manager
EBS Migrations
EBS Volumes are locked to a specific AZ
To migrate it to a different AZ (or region) we have to do the following:
Create a snapshot from the volume
(optional) Copy the volume to a different region
Create a volume from the snapshot in the AZ of choice
EBS Encryption
When we create an encrypted EBS volume, we get the following:
Data at rest is encrypted inside the volume
All the data in flight moving between the instance and the volume is encrypted
All snapshots are encrypted
All volumes created from the snapshots will be encrypted
Encryption and decryption are handled transparently by EBS system
Encryption may have a minimal impact on latency
EBS Encryption leverages keys from KMS (encryption algorithm is AES-256)
Copying an unencrypted snapshot allows encryption
Encrypt an unencrypted EBS volume:
Create an EBS snapshot from the volume
Copy the snapshot an enable encryption on the process
Create a new EBS volume from the snapshot (the volume will be encrypted)
Attach the encrypted volume to an instance
EBS vs Instance Store
Some instances do not come with a root EBS volume
Instead, they come with an instance store (ephemeral storage)
An instance store is a physically attached to the machine (EBS is a network drive)
Pros of instance stores:
Better I/O performance
Good for buffer, cache, scratch data, temporary content
Data survives a reboot
Cons of instance stores:
On stop or termination of the instance, the data from the instance store is lost
An instance store can not be resized
Backups of an instance store must be done manually by the user
An instance store is:
A physical disk form the physical server where the EC2 instance runs
Very Hight IOPS disk
A disk up to 7.5 TiB, stripped to reach 30 TiB
A block storage (just like EBS)
Can not be increased in size
An ephemeral storage (risk of data loss if hardware fails)
EBS RAID Options
EBS is already redundant storage (replicated within an AZ)
If we want to increase IOPS of if we want to mirror an EBS volume we can mount EBS volumes in parallel RAID settings
RAID is possible as long as the OS supports it
Some RAID options are:
RAID 0
RAID 1
RAID 5, RAID 6 are not recommended for EBS
RAID 0: used for increased performance. We can combine to or more volumes and what we get is the total number of disk space and I/O
If one of the disks fail, all the logical data is lost
Use cases:
Applications with lot of IOPS but without the need for fault-tolerance
A database with builtin replication
RAID 1: used for increased fault-tolerance. Mirroring a volume to another.
If one the disks fails, the logical volume will still work
We have to send the data to two EBS volumes at the same time