5 Tips to Control EBS Costs: Tracking EBS Volumes

Managing your Amazon Elastic Block Storage (EBS) costs can be complicated. You have to make sure you’ve got the right kind of storage for your workload. You have to make sure you’re using your storage effectively. And you have to periodically look for unused and underused volumes. It’s a lot to tackle, but the right tools can help you find elusive EBS volumes and manage your EBS costs.

Why use EBS instead of EC2 storage?

EBS volumes go hand-in-hand with EC2 instances, but why? After all, EC2 instances have local storage, right? The thing is, EC2 storage and EBS volumes are two entirely different orders of magnitude.

EC2 local instance storage

EC2 local instance storage is attached to the physical server hosting your instance. The kind of storage depends on the instance. With some it’s solid-state drive (SSD), others use hard-disk drives (HDD) and some don’t even have any storage.

Local storage is often called ephemeral storage. Your data disappears if the instance fails or stops (although it does survive a reboot). No snapshots, backups or encryption are provided.

An example of a good time to use local storage is voice-to-text translation of uploaded video files. In-process files could be stored in local storage. They’re there for a few hours but, once you’re done, you delete them. Instance storage is fine for a situation like this and much cheaper than EBS.

EBS storage

EBS is block storage as a service. An EBS volume is a logical volume that’s comprised of blocks spread across a variety of physical devices.

An EBS volume exists in a single availability zone (AZ). The volumes are independent of your EC2 instances so, unlike local-instance storage, EBS is persistent storage. Most importantly, EBS allows you to match the exact amount and type of storage that you want with the exact instance that’s right for your workload. You can even detach and attach a volume to another EC2 instance within the same AZ.

Choosing the Right EBS Volume

There are many types of EBS. They’re either SSD-backed or HDD-backed and all of them are designed for a variety of workloads. Generally, the first major decision point is whether your priority is IOPS or throughput. For throughput, you need to figure out if you’re doing lots of small, random I/O, which means you want SSD, or if you’re doing large, sequential reads, which means you want HDD. Of course, cost and performance are always going to be considerations. To make things easier, here’s a diagram that steps you through the big choices.

The one place where EBS may not be right is with applications that require very high IOPS and very low latency. In that case, take a look at the EC2 I3 instance. EC2 I3 is storage-optimized and designed for high transaction, low-latency workloads.

The maximum IOPS per instance and maximum throughput per instance for EBS is always changing. Right now, the max IOPS/instance is 80,000 and the max throughput/instance is 1,750 MB/sec. If you want to check before you choose, see Amazon EBS Features for the latest numbers.

Another point to remember is that Amazon recommends you separate your boot volumes from your data volumes. Boot volumes can be small, but must be SSD — only io1 and gp2 can be used.

If you’re unsure about what your application needs, start out with gp2, a general-purpose SSD storage volume designed for many types of workloads. For a complete description of EBS volumes, take a look at Amazon EBS Volume Types.

Always Tag Your EBS Volumes

Tagging is the first step to effective management of EBS volumes. You need to manage your EBS volumes just like you do your EC2 instances and other resources. Tags let you assign a simple key/value pair to your instances, EBS volumes and snapshots so you can group and manage those resources together. One thing you can do with tags is activate them as cost allocation tags, which makes that data available to the billing pipeline. You can generate reports on costs and usage broken down by those tag values, such as Dev, Test and Backup.

After EBS volumes are created, it can be tricky to know how they’re being used, which makes them tricky to tag. Graffiti Monkey is a good tool for associating EBS volumes with their instances, and you can also use Lambda Graffiti Monkey to run Graffiti Monkey serverlessly.

To learn a few more tips, you can check out our blog post: Two Solutions for Tagging Elusive AWS EBS Volumes.

5 Tips to Control EBS Costs

Keeping track of your EBS costs and making sure you’re getting the most of your money can be challenging. Here are a few suggestions that can help.

Tip #1: Get rid of orphaned EBS volumes

The whole point of EBS is that the volume persists after the EC2 instances stops. This is good for data retention, but bad if you’re paying for storage you no longer need. Unused EBS volumes are called unattached or orphaned volumes, and they’re marked as “available” if you check their status. These volumes can’t take any traffic so they’re useless. A great first step to saving money is to get rid of them.

One option is to just terminate them, but only if you’re confident the data is never going to be used. To be sure, take a look and see when the volume was last attached. If it was months ago, there’s a good chance you no longer need it. This is especially true for non-production environments.

A more cautious approach is to first take a snapshot of the EBS volume and then terminate it. EBS snapshots are always cheaper than the original volume. They discard blank space, compress the data, and then are moved to S3, which has a far lower rate. If you do need to restore the volume, you can do this from the snapshot. To learn more, check out the Amazon EBS Snapshots documentation.

Tip #2: Focus on zero throughput or zero IOPS

Once you’ve gotten rid of unattached volumes, look for attached volumes that are doing nothing. These often show up when the associated instances have been turned off and the EBS volumes were forgotten. To discover these volumes, look at the volume network throughput and IOPS. If there hasn’t been any throughput or disk operations in the last ten days, the volume probably isn’t being used.

Tip #3: Make managing your EBS costs a priority

With EBS volumes, you pay for two key attributes: storage and performance. Storage is charged per GB stored with a rate based on the location and volume type. For performance, the better it is, whether in terms of IOPS or throughput, the more expensive it is.

This may seem obvious but, at Cloudability, we’ve noticed that EBS volumes are often ignored when optimizing AWS expenditure. While it’s relatively easy to turn off an EC2 instance, there’s no equivalent action for volumes. As a result, there’s a tendency to tune EC2 instances without placing the same emphasis on dealing with latent volumes, picking the right volume type or choosing an appropriate IOPS setting.

Make sure to devote some time to rightsizing and managing your EBS volumes to make sure you’re getting the most from your cloud.

Tip #4: Reduce the number of PIOPS volumes

PIOPS volumes aren’t cheap, and it’s easy to change them. Simply go through your list of EBS volumes and check out the scores for any PIOPS (io1) volumes. In the detailed view, you’ll be able to see the maximum IOPS that hit your volume. Add 10-20% above this max to be safe and then decide if you really need the PIOPS volume.

If you can, switch from an io1 volume type to gp2. This saves on IOPS/month and has a lower hourly storage rate. If your volume is 500GB or larger, then convert to sc1, a cold HDD. This will dramatically lower your storage rate. If your volumes start getting more traffic, you can easily go back to the PIOPS volume.

Tip #5: Take advantage of elastic volumes

In early 2017, Amazon introduced elastic volumes. With them, you can increase volume size, change volume types, and increase/decrease provisioned IOPS. You can do this while your application is actively driving IO to your volume. There’s no need for a maintenance window or downtime. There’s a big cost savings benefit because you no longer have to overprovision your storage.

Make sure to include elastic volumes in your evaluation process for better EBS optimization.

Get Total Control of EBS Costs & Volumes

As your infrastructure grows, it gets harder to keep an eye on all the moving parts and to come up with a good cloud management strategy. A platform like Cloudability gives you the visibility, control and recommendations you need to optimize your AWS spending.

For example, to get reliable reports on EBS storage, it helps to know a volume’s performance type and the API name that’s used in billing records. Cloudability identifies them and normalizes that reference in the Usage Family dimension. The Operation and Usage Type dimensions give you additional details.

Cloudability’s Automation feature is another powerful tool for controlling EBS costs. Using Automation, you can set up tasks that take care of tracking down and cleaning up unused EBS volumes. You can also automatically scale down or stop resources during slow periods, such as nights and weekends, or automate taking EBS snapshots.

Rightsizing

Cloudability’s Rightsizing feature gives you cost savings recommendations for your EBS volumes. It also evaluates the amount of IOPS for a period of time you select. If there are 0 IOPS for a volume, it labels the volume as unused and a candidate for termination.

With Rightsizing, you can balance the risks of resource clipping versus savings. Recommendations are arranged from left to right, with the leftmost option being the top recommendation — the highest savings option with the lowest risk. Other recommendations may have higher savings, but also higher risks.

Each volume is also associated with a suggested action, such as Rightsize or Terminate. You can also get details about a specific volume.

Cloudability has many other features that will help you get not just your EBS volumes, but all your AWS resources under control. Sign up for your free trial to see it in action!