In this lecture, I shall be talking about the Amazon Elastic Block Store service, known as EBS, which provides storage to your EC2 instances via EBS volumes, which offer different benefits to that of instance store volumes used with some EC2 instances.

EBS provides persistent and durable block level storage. As a result, EBS volumes offer far more flexibility with regards to managing the data when compared to data stored on instance store volumes. EBS volumes can be attached to your EC2 instances, and are primarily used for data that is rapidly changing that might require a specific Input/Output operations Per Second rate, also known as IOPS.

EBS volumes are independent of the EC2 instance, meaning that they exist as two different resources. They are logically attached to the instance instead of directly attached like instance store volumes. From a connectivity perspective, only a single EBS volume can only ever be attached to a single EC2 instance. However, multiple EBS volumes can be attached to a single instance.

Due to the EBS ability to enforce persistence of data, it doesn't matter if your instances are intentionally or unintentionally stopped, restarted, or even terminated, the data will remain intact when configured to do so. EBS also offers the ability to provide point in time backups of the entire volume as and when you need to. These backups are known as snapshots and you can manually invoke a snapshot of your volume at any time, or use Amazon CloudWatch events to perform an automated schedule of backups to be taken at a specific date or time that can be recurring.

The snapshots themselves are then stored on Amazon S3 and so are very durable and reliable. They are also incremental, meaning that each snapshot will only copy data that has changed since the previous snapshot was taken. Once you have a snapshot of an EBS volume, you can then create a new volume from that snapshot. So, if for any reason you lost access to your EBS volume through or incident or disaster, you can recreate the data volume from an existing snapshot and then attach that volume to a new EC2 instance. To add additional flexibility and resilience, it is possible to copy a snapshot from one region to another.

Looking at the subject of high availability and resiliency, your EBS volumes are, by default, created with reliability in mind. Every write to a EBS volume is replicated multiple times within the same availability zone of your region to help prevent the complete loss of data. This means that your EBS volume itself is only available in a single availability zone. As a result, should your availability zone fail, you will lose access to your EBS volume. Should this occur, you can simply recreate the volume from your previous snapshot and attach it to another instance in another availability zone.

There are two types of EBS volumes available. Each have their own characteristics. These being SSD backed storage, solid state drive, and HDD backed storage, hard disk drive. This allows you to optimize your storage to fit your requirements from a cost to performance perspective.

SSD backed storage is better suited for scenarios that work with smaller blocks. Such as databases using transactional workloads. Or often as boot volumes for your EC2 instances. Whereas HDD backed volumes are designed for better workloads that require a higher rate of throughput, such as processing big data and logging information. So, essentially working with larger blocks of data.

These volume types can be broken down even further. Looking at the following table we can see how different volumes can be used for both SSD and HDD volumes types.

You can see that depending on the use case for your EBS volume you can select the most appropriate type. Each of these volumes also offer different performance factors which include: Volume size, Max IOPS per volume, Max throughput per volume, Max IOPS per instance, Max Throughput per instance, and Dominant performance.

The performance of volumes change frequently and so for the latest information on these volume types, please refer to the AWS documentation found here.

For those who are not familiar with provisioned IOPS (input/output operations per second) volumes, they deliver enhanced predictable performance for applications requiring I/O intensive workloads. When working with these volumes you also have the ability to specify at IOPS rate during the creation of a new EBS volume, and when the volume is attached to an EBS-optimized instance, EBS will deliver the IOPS defined and required within 10%, 99.9% of the time throughout the year.

The throughput optimized HDD volumes are designed for frequently accessed data and are ideally suited to work well with large data sets requiring throughput-intensive workloads, such as data streaming, big data, and log processing. These volumes will deliver the expected throughput 99% of the time over a given year, and an important point to make is that these volumes can’t be used as boot volumes for your instances.

The cold HDD volumes offer the lowest cost compared to all other EBS volumes types. They are suited for workloads that are large in size and accessed infrequently. They will deliver the expected throughput 99% of the time over a given year, and again, it is not possible to use these as boot volumes for your EC2 instances.

One great feature of EBS is its ability to enhance the security of your data, both at rest and when in transit, through data encryption. This is especially useful when you have sensitive data, such as personally identifiable information, stored in your EBS volume. And in this case, you may be required to have some form of encryption from a regulatory or governance perspective. EBS offers a very simple encryption mechanism. Simple in the fact that you don't have to worry about managing the data keys to perform the encryption process yourself. It's all managed and implemented by EBS. All you are required to do is to select if you want the volume encrypted or not during its creation via a checkbox.

The encryption process uses the AES-256 encryption algorithm and provides its encryption process by interacting with another AWS service, the key management service, known as KMS. KMS uses customer master keys, CMKs, enabling the encryption of data across a range of AWS services, such as EBS in this instance.

To learn more about the Key Management Service, please see our existing course here.

Any snapshot taken from an encrypted volume will also be encrypted, and also any volume created from this encrypted snapshot will also be encrypted. You should also be aware that this encryption option is only available on selected instance types.

One final point to make on EBS encryption is that you can create a default region setting that ensures that all EBS volumes created will be encrypted by default.

For a detailed overview of exactly how this encryption process works, please take a look at the following blog post.

As EBS volumes are separate to EC2 instances, you can create an EBS volume in a couple of different ways from within the management console. During the creation of a new instance and attach it at the time of launch, or from within the EC2 dashboard of the AWS management console as a standalone volume ready to be attached to an instance when required. When creating an EBS volume during an EC2 instance launch, at step four of creating that instance, you are presented with the storage configuration options. Here you can either create a new blank volume or create it from an existing snapshot. You can also specify the size and the volume type, which we discussed previously. Importantly, you can decide what happens to the volume when the instance terminates. You can either have the volume to be deleted with the termination of the EC2 instance, or retain the volume, allowing you to maintain the data and attach it to another EC2 instance. Lastly, you also have the option of encrypting the data if required.

You can also create the EBS volume as a standalone volume. By selecting the volume option under EBS from within the EC2 dashboard of the management console, you can create a new EBS volume where you'll be presented with the following screen.

Here you will have many of the same options. However, you can specify which availability zone that the volume will exist in, allowing you to attach it to any EC2 instance within that same availability zone. As you might remember, EBS volumes can only be attached to EC2 instances that exist within the same availability zone.

EBS volumes also offer the additional flexibility of being able to resize them elastically should the requirement arise. Perhaps you're running out of disk space and need to scale up your volume. This can be achieved by modifying the volume within the console or via the AWS CLI. You can also perform the same resize of the volume by creating a snapshot of your existing volume, and then creating a new volume from that snapshot with an increased capacity size.

As we can see, EBS offers a number of benefits over EC2 instance store volumes. But EBS is not well suited for all storage requirements. For example, if you only needed temporary storage or multi-instance storage access, then EBS is not recommended, as EBS volumes can only be accessed by one instance at a time. Also, if you needed very high durability and availability of data storage, then you would be better suited to use Amazon S3 or EFS, the elastic file system.

That now brings me to the end of this lecture and to the end of this introductory course and you should now have a greater understanding of the Amazon Elastic Block Store service and how it can be used as a storage option for your EC2 instances.

If you have any feedback, positive or negative, please do contact us at support@cloudacademy.com. Your feedback is greatly appreciated. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.