Image provided by: https://pixabay.com/en/hard-disk-technology-electronics-42935/
Amazon Elastic Block Store (EBS) is one of the many cloud services that Amazon Web Services offers. Amazon EBS provides block-level storage volumes, connectable to EC2 cloud instances. Among the main use cases for EBS storage volumes are the deployment of relational database systems in the cloud, supporting mission-critical enterprise apps with primary storage, and as storage mounts for Big Data analytics engines such as Hadoop.
EBS volumes are known for their persistence, meaning that even if you switch off the EC2 instance to which a given EBS volume is attached, the volume continues on with its data intact.
With this basic overview in mind, read on to find out five things you didn’t know about Amazon EBS (and check out this article by NetApp on additional EBS volume types and functions).
Performance and Cost Depend on Allocated Storage
Quite a few factors influence the performance you get from EBS, and one of the most important is whether or not you plan ahead for performance and choose the right storage size for your EBS volumes. The storage size you choose for a volume impacts the number of input-output operations per second (IOPS). The result of not choosing enough storage is that you end up with sub-optimal performance from EBS.
However, there is a fine balance here because while choosing the largest storage sizes seems like an easy shortcut to simultaneously reduce the chance of poor performance and incorporate future growth, you’ll often end up paying too much for unused resources. And when you over-provision an EBS volume, it takes significantly more effort and downtime to reduce to a more appropriate volume size for your needs than it would to expand an EBS volume with insufficient size/performance.
This is why it’s imperative to right-size your EBS capacity. Right-sizing is a challenge but it helps you strike the balance between performance and cost while minimizing application downtime.
You Can Modify EBS Volumes In Use
Related to the previous point, it’s now possible to increase the volume size or modify an EBS volume type while it is in use. This feature for modifying volumes in-use is not available for EBS volumes attached to several types of previous generation EC2 instances.
The ability to modify on-the-fly avoids downtime for workloads with unexpected spikes in data that require greater storage without having to go offline. Previously, modification involved detaching the old EBS volume from its associated EC2 instance, taking a snapshot, replacing it with a different volume size, and re-attaching it .
Being able to increase volume size for currently in-use volumes reinforces the importance of right-sizing volumes as opposed to purposefully over-provisioning them.
Snapshots Can Help Save Money or Lose Money
Taking a snapshot of an EBS volume is a very useful feature for keeping point-in-time copies of your data, particularly for disaster recovery or backup purposes. Furthermore, because EBS snapshots cost less than active volumes, you can delete low access volumes after you’ve created a snapshot of them, which saves you money.
On the other hand, snapshots can end up costing you money when you have too many of them. It’s good practice to delete outdated snapshots because you’ll typically only need to restore from your most recent snapshot.
Unattached Volumes Still Cost Money
While persistence is a useful feature of EBS volumes, it’s important to remember that unattached volumes still cost you money. Companies with large AWS cloud deployments can easily lose track of unattached volumes without a centralized dashboard that monitors cloud resources.
For example, when deleting an EC2 instance, IT admins might forget to delete the EBS volumes attached to them. Such volumes, despite being unattached an unused, still get tacked onto your monthly bill. Each time you launch a new EC2 instance, you can adjust a setting in the AWS console to delete any EBS volumes associated with a given instance when that EC2 instance terminates.
However, because you might sometimes need your EBS volumes to persist beyond the lifetime of the instance to which you attach them, the ideal way to avoid unnecessary expenses is to have a dashboard in place that monitors your cloud resource usage and deleting unattached volumes that serve no use.
Pre-Warming is No Longer Needed for New Volumes
Previously, when creating a new EBS volume, it was necessary to pre-warm it to avoid latency issues caused by accessing a block for the first time. Now, however, new volumes don’t require pre-warming, or initialization, as AWS now terms it.
An important exception to this is when your EBS volume is created from a snapshot. The first time you read from such blocks, there is a delay, causing up to a 50 percent performance degradation, which may be unacceptable for your workload. In such cases, AWS recommends pre-warming, which basically entails reading from each block on your volume before you use it.
Hopefully you have learned something you didn’t know about Amazon EBS from this article. You can check out the AWS FAQ page on Amazon EBS to find out some additional information that might be of help to you when using the service.
Check out our list of 100 Best Free SEO Tools & Resources for Every Challenge