EBS is one of the fundamental building blocks in AWS, but its variety of options and features makes it hard to manage costs. Here's how!
Elastic Block Storage (EBS) is one of the fundamental building blocks for an AWS cloud application. It's the filesystem you use to add persistence to your Elastic Compute Cloud (EC2) instances and offers various configurations to suit your computing needs. But those different options can get complicated and makes managing EBS pricing difficult.
In this post, we'll look at EBS, what it has to offer, and how you can master EBS pricing. Let's dive in!
EBS is Amazon's block storage offering for AWS. It looks and performs like a local storage device for Amazon EC2 compute instances. But, unlike a dedicated local storage device, EBS is backed by AWS' high-availability cloud infrastructure. This means it can perform better and more reliably than standard storage options.
Depending on the volume type, your storage is backed up within the same availability zone, giving a 99.999% uptime rate. You can also create volumes up to 64 TB in size with 260,000 maximum IOPS and 7500 MB/s of throughput per instance.
Even if you don't opt for the highest-performance (and most costly) EBS volume, EBS offers a minimum of 99.8% availability and replicates all volumes within their availability zone. You can also save "point-in-time" snapshots of your volumes to Amazon Simple Storage Service (S3.)
Amazon EBS encryption will encrypt all volume types for you, using their secure key management infrastructure. All of your data will be encrypted at rest using Amazon's keys, or if you wish to manage the keys, you can use AWS Key Management Service.
EBS's primary use is for persistent data for EC2 instances. When you terminate an EC2 instance, AWS destroys its local store. If you want any data to outlive the instance, you need permanent storage. Amazon recommends using EBS for this. It acts as a local disk, and it's easy to back up. EBS is also the default storage for AW cloud services like Amazon RDS and Amazon OpenSearch.
If you want any data to outlive the instance, you need permanent storage. Amazon recommends using EBS for this.
The ability to snapshot EBS data opens up many possibilities. For example:
EBS and S3 are both storage services, but that's where their similarities end. They are different products designed to solve different problems. Amazon bills S3 as "Object storage built to retrieve any amount of data from anywhere," and it's an apt description. S3 stores data in "buckets" that you can access from anywhere. S3's data is available both inside and out of AWS by more than one client at a time. You have granular control over who has access via Access Control Lists (ACLs.) (Of course, you can limit access to your buckets.) S3 stores data in a flat structure, and you access it via an API. You can also make the contents of your S3 buckets accessible like a web server.
EBS and S3 are both storage services, but that's where their similarities end. They are different products designed to solve different problems.
EBS is block storage for EC2 instances and managed services. It's only accessible inside AWS and only by one system at a time. You have to format block storage with a filesystem before using it, so unlike S3, you can tailor EBS' file structure to suit your specific needs.
EBS and S3 are related in that you can backup your EBS instances to S3. This is a significant feature that provides you with S3's higher reliability and cross-region availability for EBS data.
Like most AWS offerings, EBS pricing can be complex. It has many moving parts and a wide variety of service offerings. If you rely on EBS in your environment, ensuring that you have processes in place to maintain EBS cost efficiency is essential to your FinOps practice.
First, the most significant price differentiator in EBS storage is solid-state or traditional rotating media (HDD.) The default hard drive option costs just a little more than half of the default SSD. If you stay in the SSD option, you can choose from different speeds, throughput, and durability.
These tables are condensed versions of Amazon's features breakdown for EBS. They detail the different options alongside their pricing models.
First, here are the SSD options. You pay for SSDs based on the size of the volumes and input/output operations per second (IOPS.) Each product includes a free baseline IOPS level. You pay when your applications exceed it.
*Default volume type
**Not currently supported by EC2 R5b instances
***Volume throughput is calculated as MB = 1024^2 bytes
Next, the HDDs.
* st1/sc1 based on 1 MB I/O size
** volume throughput is calculated as MB = 1024^2 bytes
The costs for io1, io2, and io2 Block express are the same, while gp2 and gp3 are less. HDDs are substantially less expensive. EBS snapshots are billed based on size, so the cost remains consistent regardless of the type of drive you're snapshotting.
These differences seem trivial when looking at a single volume, but EBS costs can add up fast. Remember, you can't share EBS volumes, and each of your EC2 instances needs at least one, often more. So, the cost can add up very quickly.
Let's look at a few cost-saving strategies.
The first step to saving money with EBS, and AWS in general, is to track your spending carefully. This may seem obvious, but AWS resources can be hard to follow, and sometimes it seems easier to give up.
But there is a tool that can help, and it's built into your AWS dashboard: cost allocation tagging. Instead of tracking individual resources or treating cloud instances like machines in a data center, use tags to correlate spending to products and cost centers. Take a look at our handy guide.
Gp3 volumes are the most popular SSD type. They give you SSD performance for a reasonable price. Unless your application is very I/O intensive, it's probably good enough. That 25% savings adds up quickly as you add more volumes to more EC2 instances.
If you can get by with HDDs, you can save even more. While SSDs are faster, an application that reads sequential data into memory will do fine with rotating media. Run your OS from a small SSD and give the app a different data partition on a cheaper volume.
Stopping or terminating an EC2 instance does not remove the volume and Amazon will continue to charge for it. If you need the data, make sure you have an up-to-date snapshot instead of paying to retain the EBS volume. Snapshots are cheaper unless you're using the least expensive HDD class. Even then, snapshots are more reliable and easy to restore.
A snapshot is inexpensive. Too many snapshots are a waste. Review them regularly and implement a strategy that defines what you need to keep and how long.
We've discussed what EBS is and how you use it with your Amazon EC2 instances and managed services. We compared it to S3 and saw how they are very different products that overlap in one very important way. Finally, we looked at how EBS is priced and how you can manage how your expenses.
EBS's importance and variety of options mean it has many moving parts, but managing it doesn't have to be complicated.