AWS EBS Pricing and Cost Optimization Guide

Amazon Elastic Block Store (AWS EBS) isn’t a fancy service. It’s simply a tool that provides disk storage for all your Elastic Compute Cloud (EC2) instances.

A few months ago, an organization was testing a new system for a company (an SAP HANA database), and a new Amazon EC2 instance was automatically created from a template with associated EBS disks. As with any other services by AWS cloud, you only pay for what you use, so the instance was started only when that specific database needed to be utilized. However, at the end of the month, when the bill had increased from $10 USD to $250 USD, the organization had learned a very expensive lesson: there are multiple types of EBS storage volumes.

In this article, you’ll learn about EBS volumes (the storage for your EC2 instances), the EBS pricing structure, and in-depth and practical ways to lower your EBS costs.

If you want to take Cost Optimization one step further, you should check out CloudForecast’s ZeroWaste feature. The ZeroWaste feature is designed for straightforward AWS cost optimization, eliminating unnecessary complexity. Dive into our interactive demo of the ZeroWaste reporting tool to see how it can optimize your costs.

What Is AWS EBS?

AWS EBS snapshots is one of the oldest services by AWS. It offers a whole range of options to provide you block storage for your EC2 instances, and it’s generally opposed to object storage (like AWS S3 or Simple Storage Service).

EBS volumes are typically used as a disk to emulate a classic hard drive in an EC2 instance. AWS offers multiple EC2 instance types (t3.small, c5.large, etc.) to accommodate your workload requirements, and the same offerings are available for EBS in order to fit your instance storage requirements.

AWS EBS Snapshots offers multiple choices depending on your use case:

• General Purpose SSD (gp2 and gp3) is the most common choice. It’s recommended for most workloads.
• Provisioned IOPS SSD (io1 and io2) provides higher performance than General Purpose SSD (sub-millisecond latency, high throughput, and high IOPS performance). It’s recommended for very low latency or very high IOPS workloads.
• Classic HDD (st1 and sc1) uses HDD, not SSD, and is recommended for high-volume usage cases or data warehouses for big data.

For more information on Amazon EBS snapshot types, you can visit the AWS documentation.

What Is IOPS in AWS?

IOPS or input/output operations per second is a performance measurement dedicated to disk storage. It’s the number of input/output operations per second. For example, a mechanical hard drive can operate from 1 to 100 IOPS (depending on the specific operations), and SSD can provide generally greater performance, from 5,000 to 100,000 IOPS. This characteristic is used a lot in EBS pricing.

AWS EBS also provides a snapshot system to back up EBS volumes at a specific time. Behind the scenes, it’s using S3 to store your snapshots but is fully managed for you. It helps you recover the state of your instance before something bad can happen, like when your server has failed and you need to restore a backup.

Why Optimize AWS EBS snapshots?

There are many reasons you should optimize your EBS volumes and snapshots. Some of those include the following:

• Cost management: EBS can be pricey when you’re not choosing the correct option for your workload, and it takes time before your bill will arrive (as mentioned above).
• Workload optimization: you may find that the EBS type you chose is not the best fit for your workload. For example, if you’re using io2, the duration to handle the workload will be reduced so you can save your developer and customer time.
  Resource optimization: it’s easy to forget an old snapshot or even an orphan volume in the console since you have to find them yourself.

AWS EBS Pricing and Cost Factors

The pricing model is one of the most complex parts of EBS. It’s complicated, and it’s hard to know what your bill will be at the end of the month.

For reference, here is the Amazon EBS pricing page.

There are two main categories of EBS volume types:

1. General Purpose (gp2 and gp3)
2. High Performance (io1, io2, and io2 Block Express)

Other EBS volume types have not been included because they are either very specific or not an SSD (for example, st1 and sc1 are classic magnetic HDD).

EBS General Purpose Pricing

General Purpose SSD (gp2 and gp3) is one of the easiest volumes to understand. You pay a fixed price per gigabyte and time. For example, a 100 GB gp2 disk will cost you about $10 USD a month (in the Eastern United States).

Meanwhile, gp3 lets you choose a specific IOPS and a specific throughput (data rate speed in MBps). For example, the same 100 GB with 3,000 IOPS and 125 MBps (baseline values) will cost you $8 USD in the Eastern US. Depending on the provisioned capacity, the price can be slightly more or less than an equivalent gp2 EBS volume.

However, gp2 vs gp3 can become costly quickly. If you double the performance to 6,000 IOPS and 250 Mbps, then it will cost you $28 USD per month in the same region.

A note regarding gp2 performance: the performance will depend on the size of the disk (a disk with a bigger size will have better baseline performance), and you’ll have a specific amount of I/O that can be used for bursting. It’s designed to handle your instance boot process when a lot of I/O operations are needed. Once your I/O credit is exhausted, then you will stay on your baseline performance. For example, a 100 GB disk would have a baseline performance of 300 IOPS. The burst performance could then be up to 3,000 IOPS, and the throughput for gp2 would be set to 250 MBps (which is more than the gp3 baseline of 125 MBps).

If you’re looking for an in-depth analysis on gp2 vs gp3, we wrote an in-depth analysis between the two and how you can easily migrate from one to the other.

Read more: AWS EBS Volumes: gp2 vs gp3 analysis

AWS EBS High-Performance Pricing

High-performance pricing is like a premium SSD disk—better performance but at a higher cost. AWS recommends it for mission-critical, low-latency, or high-throughput workloads.

If you want to create a 100 GB io1 disk with 3,000 IOPS, then it will cost you about $207 USD per month in the Eastern US. It would cost the same as the io2 model since the models are equivalent.

Overall, gp3 is a better option than gp2 because it offers better performance (no more burst limitation) and the baseline performance is about 20 percent cheaper. gp3 is also a better pricing option compared to io1 or io2 if you can stay under 16,000 IOPS (which is the limit for gp3). If you need premium performance (sustained IOPS performance, I/O-intensive workloads, etc.), io1 and io2 are your best options.

Practical Tips to Lower AWS EBS Cost and Boost Performance

Below are practical tips that can help you optimize your EBS service by reducing your AWS cloud cost and preventing bottleneck performance on some disks.

Detect Orphan EBS Volumes

An orphan EBS volume is a volume that is not attached to any EC2 instance. It generally occurs when the instance has been terminated (deleted) but the attached volumes have not been deleted at the same time (ie the flag Delete on termination has not been checked).

However, you can easily detect orphan volumes using the AWS Console. Connect to the AWS account you want to work on, select the correct region (us-east-1 in the example below), and navigate to the service EC2; then Elastic Block Store > Volumes. Enter the Volume state: available filter to detect only orphan volumes.

Then delete the volume by using the context menu Delete volume.

Warning: this action needs to be done in each region where you are deploying EBS and in every AWS account you’re managing.

Alternatively, you can also use the AWS CLI to detect orphaned volumes. After installing the tool on your laptop and configuring your account, you can run the following command:

aws ec2 describe-volumes --region us-east-1 --filter Name=status,Values=available --output text

Then you’ll get a list of orphan volumes:

VOLUMES us-east-1a      2022-02-13T02:04:37.137000+00:00        False   100     False   1               available       vol-06ad1eac3f3dc16c8   gp2
TAGS    Name    orphan-volume

Detect Unused EBS Snapshots

An unused EBS snapshot is more complex than an orphan volume. Depending on the context, it can be as follows:

• a snapshot of an EBS volume that has been deleted (note: you don’t want to keep snapshots of deleted instances)
• a snapshot that is not used by any AMI (Amazon Machine Image) because you have removed the AMI (deleting an AMI is not the same as deleting the snapshots linked to the AMI)

What Is an AMI?

An AMI (Amazon Machine Image) is a resource created on AWS that lets you start a new instance based on a specific configuration (generally the EBS snapshot used to create the new EBS volumes). When you start an Amazon Linux 2 instance, you’re using a specific AMI (maintained by Amazon).

Using the AWS Console, it’s hard to detect unused EBS snapshots:

Each snapshot is linked to a Volume ID, which is the original volume from where the snapshot was created. But if the volume is not available anymore, then specific information will not be available (you will get a Volume not found alert when you click on the link).

The same is true for AMI; each one shows you the list of snapshots used in the Storage tab:

If you’re dealing with hundreds of AMI or volumes, it’s hard to quickly understand the state of your assets. You can find some AWS CLI examples that give you this type of information, but the most reliable script is a Python script (that uses AWS API under the hood). (It’s a fork from an existing script that was modified to fit the change of the snapshot description field.)

Once it’s correctly configured, you can launch it using the following command:

./snapshots.py snapshot-report

The command will generate a report.csv file:

The report will let you easily track the following:

• snapshots where linked EBS volume has been deleted (snap-049e51f9104133da1 in the example above)
• snapshots where linked AMI has been deleted (snap-0935322cfde3809be in the example above)
• snapshots generated more than eighteen months ago (based on the start_time field)

Warning: this tool relies on the description of the snapshot (Created by CreateImage ....), not on the actual AMI list.

Detect Overused or Underused AWS EBS Volumes

Because of the pricing model, it can be easy to overuse a gp2 volume (because you are doing too much IOPS on it). However, there is an easy way to detect this. Inside the AWS Console, under EC2 > EBS Volumes, identify the volume to study and click on the Monitoring tab. Then you’ll be shown some metrics about your volume:

The last one is the Burst balance, which shows you the I/O credit consumption. If this metric is going too low (like in this example), then your volume will be limited to the baseline IOPS performance (which is very low on a small disk).

Below is an example of a bigger version of the Burst balance metric, shown inside the CloudWatch service (click on the View in Metrics option on the small graph):

For reference, this example used an 8 GB disk and the following command to stress the disk (using FIO, the flexible I/O tester). It took half an hour to exhaust all I/O credits for this volume:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

You can also use the monitoring screen to check a few other metrics:

• The Write and Read Bandwidth can help you check if your throughput is correctly configured (you may be able to lower this setting to save money).
• The Average queue length will let you know how many I/O operations are waiting. It’s a great indicator to check the I/O health of the volume.

On the volume below, you can see low usage of a disk:

Use AWS EBS-Optimized Instances

Better performance is generally a good way to reduce your AWS bill. For instance, if you can achieve your workload in one hour instead of two, you can save the cost of one hour of an EC2 instance. It’s possible to improve performance on your instances by choosing an EBS-optimized instance type. You can refer to the documentation regarding this specific feature. In a nutshell, try to avoid non-optimized types, like t2:

It’s possible to switch the EBS-optimized flag by using Instance settings > Change instance type (this option is accessible only when optimization is not enabled by default):

When using an EBS-optimized instance, AWS provides dedicated capacity for Amazon EBS I/O designed to deliver 99 percent of expected performance (for gp2, gp3, io1, and io2).

Detect Unused AWS EC2 Instances

With EC2, you only pay the instance cost for the time it’s up and running. That means keeping an instance stopped will lower your overall costs. But, the EBS volumes attached to the same EC2 instance will cost you the same amount at the end of the month. A good practice is to get a look at your list of instances and check if you have some dormant ones, which means they haven’t been used for a few weeks or months. To find these instances, sort the Launch time column in descending order on the Instances page:

You may be surprised by the old instances you find.

Migrate from gp2 to gp3

Another way to save cost is migrating from gp2 to gp3. We wrote an in-depth guide and analysis here: AWS EBS Volume: gp2 vs gp3 Analysis. You’ll also get a practical step-by-step guide on migrating from gp2 to gp3 from the ec2 console and from the AWS CLI.

Final Thoughts

You may have already discovered that the cost of EBS is an important consideration when you’re relying on EC2 in your infrastructure. The practical tips shared here will help you if you want to challenge your actual EBS costs and save money.

If you want to take Cost Optimization one step further, you should check out CloudForecast, with its ZeroWaste feature. CloudForecast is designed to detect automatically available EBS optimizations (like unused EBS snapshots and unattached EBS volumes), and it helps you with other services, like EC2, Amazon Relational Database Service (Amazon RDS), and S3.