Fixer

Delete idle volumes to save 10% or more on Amazon Elastic File System (EFS)

Learn how to reduce cloud expenses by identifying and eliminating idle EFS (Elastic File System) volumes.

The easiest way to save money on the cloud is to not use it at all.

– Meredith Holborn, AWS Technical Account Manager and AWS Made Easy guest

Obviously the quote above, from one of our favorite guests on the AWS Made Easy livestream, is tongue in cheek. Team CloudFix, of all people, would be the last to recommend that anyone NOT use the cloud! We wholeheartedly agree, however, with Meredith’s point: the easiest way to save money on AWS is to use less of it. That doesn’t mean scale back where it counts – it means stop paying for what you’re not using.

We’ve been down this road before, eliminating unnecessary EBS volumes, idle QuickSight users, unused Elastic IP addresses, idle Elastic Load Balancers and more. Today, we’ll do the same for Amazon Elastic File System (EFS) volumes, and reduce your EFS costs by 10% along the way.

Table of contents

  1. How Amazon Elastic File System (EFS) compares to other AWS storage options
  2. How to save 11% on EFS by using the backup storage tier
  3. How to find idle EFS file systems
  4. How to remove idle EFS volumes
  5. Remove idle EFS volumes automatically with CloudFix

1. How Amazon Elastic File System (EFS) compares to other AWS storage options

Amazon Elastic File System (EFS) is a managed Network File System v4 (NFS) service. It’s accessible by multiple AWS services, such as EC2 and Lambda, simultaneously. This allows EFS to act as a common data store for an application, using files as a basis of communication. Although EFS tends to be more expensive than options like S3 or EBS, it’s a great choice if you have an existing application that needs a big disk drive and you don’t want to rework it to use Amazon’s native tools. 

As usual with AWS, there is more than one way to do things. EFS, defined in the simplest possible terms, is a way to store files where multiple users can access them simultaneously. There are other ways to do this with AWS. The ones that come to mind are S3 (especially with the new Mountpoint for Amazon S3 feature), sharing an EBS volume over NFS via an EC2 instance, modifying the code to work on data objects rather than files and then using DynamoDB, and even more exotic options such as hosted HDFS on an Amazon EMR cluster (this is overkill. Don’t use this if you don’t know what it is). Each of these options has different prices and different tradeoffs.

Relative to S3, EFS offers a hosted network file system that’s supported natively by nearly all operating systems. Rather than interacting with S3 via an AWS-supplied library, EFS file systems simply appear as a mounted network drive. This can simplify application development and make it easy to “lift and shift” applications to AWS without making drastic code changes. This simplicity does come at a cost, as EFS is more expensive on a per-GB basis than S3.

Compared to EBS, EFS offers access to multiple clients simultaneously. Multiple lambda functions, EC2 instances, and ECS clusters can all access the same EFS file system at the same time. Since EFS is an implementation of the Network File System, it is explicitly designed for this use case. EBS is block-level storage, designed to emulate a raw storage device attached to a particular EC2 instance. To get this feature using EBS, you would have to host your own NFS server using EC2, which is way too much complexity.

EFS can be a very flexible option when it meets your requirements and can act as a key part of your infrastructure. But eventually that infrastructure is no longer needed, and we end up with EFS volumes that aren’t being used by anyone. Since EFS volumes are often a shared resource (multiple data scientists accessing the same data set, for example), people are hesitant to delete EFS volumes because they aren’t sure if anyone else still needs it. Eventually, the unused volumes add up.

That’s where we come in. By identifying and removing idle volumes, while still retaining backups of each one, we can significantly lower EFS costs without risking the loss of any data.

2. Using the AWS Backup of EFS Volume storage tier to save 11% on EFS

Let’s start by taking a look at EFS pricing. It’s relatively straightforward: 

Storage mechanism

Cost per GB per month

EFS Standard

$0.30

EFS Standard-IA

$0.025

EFS Average effective rate when using Intelligent-Tiering

$0.08

AWS Backup of EFS Volume

$0.01

The first row, EFS Standard, is the price of a “standard” EFS volume. EFS volumes by default are created with this storage class. Similar to S3, there is a lower tier of access called Standard Infrequent Access (Standard-IA), which costs substantially less. There are also savings available by reducing the availability of the volume to a single availability zone within a region. 

As you can see, EFS also has an Intelligent-Tiering option, like S3. In fact, we wrote a whole blog post about how to enable EFS Intelligent-Tiering across your organization, so if you haven’t done that, it’s a good place to start. In the pricing chart, the EFS “average effective rate when using Intelligent-Tiering” refers to the average EFS per-GB cost when using Intelligent-Tiering, which would be a mix of Standard and Standard-IA based on usage.

Which brings us to the final row, where we find our savings. AWS Backup of EFS volume refers to the cost of backing up the EFS volume. When we eliminate idle EFS volumes using the process below (or automatically with CloudFix), we use AWS Backup to save the data on the volume before deleting it. This lets us pay far less than EFS Standard and 1/8th the price of the Intelligent-Tiering effective rate, without risking that the data is gone forever. The result: an average of 11% savings on EFS. Not too shabby.

3. How to find idle EFS file systems

We’ve seen how much we can save by leveraging the AWS Backup tier for unnecessary volumes. Next, let’s find the EFS volumes that are good candidates for deletion.

We all know what “idle” means in a general sense, but it’s important to put guardrails around its definition when applied to a shared file system. At its simplest, an idle EFS volume is one that nobody has used for an extended period: no one is mounting it, and no data is being read or written. It would be like having a Netflix subscription, but not having watched any movies or shows in months. In both cases, that’s a waste of money. (If you have an EFS volume whose only job is to support an occasional batch process, factor that in.)

Confirming that a volume is truly idle takes more than a glance at the console. A volume with no mounts today may have been in use last week, and a volume that is still mounted may not have moved a byte in months. So you need to look at the volume’s history as well as its current state. EFS is well monitored by CloudWatch (for more on CloudWatch, which is one of our favorite AWS tools, go here), and the EFS metrics page describes what AWS publishes for each file system. Your Cost and Usage Report (CUR) tells you what each volume costs, which helps you prioritize the most expensive ones first.

4. How to remove idle EFS volumes

Now comes the (relatively) easy part: backing up and eliminating the volumes that we no longer need, and don’t want to pay for.

AWS Backup is a “fully-managed service that makes it easy to centralize and automate data protection across AWS services, in the cloud, and on premises.” We can use AWS Backup to save the data from an EFS volume at the cost of $0.01/GB/month. This is a drastic reduction from the $0.30/GB/month rate for standard EFS, and is still far cheaper than $0.08/GB/month when using EFS Intelligent-Tiering.

At a high level, removing an idle volume safely means taking a backup of it with AWS Backup, making sure that backup has completed, and only then deleting the file system. Once that’s done, you’ve gone from paying $0.30/GB/month to $0.01/GB/month without any loss of data, and if anyone ever does need the data again, it can be restored from the backup.

5. Remove idle EFS volumes automatically with CloudFix

We built CloudFix to take care of the simple, well-understood fixes that, at scale, add up to serious AWS savings. Many of those, like this fix, delete idle resources. There are a number of steps and it involves deleting things, so you want to be certain it’s a process you can trust.

Here’s how it works. The CloudFix finder uses your cost and usage data and the volumes’ own usage metrics to identify idle EFS volumes, read-only. Each one appears in your Recommendations for you to approve. Once you do, the fixer runs as an AWS Systems Manager Automation runbook in your own account: it backs the volume up with AWS Backup, then deletes it, and every execution is logged. We have run and tested this automation across tens of thousands of accounts and have made sure that you can realize these savings without losing data. That means you can focus on adding value to your business while we take care of the cleaning up.

Whether you use CloudFix or write your own automation, you can definitely save money by eliminating idle EFS volumes. So go forth and delete: the easiest way to save money on the cloud, after all, is by not using it at all.


More from the blog

All 81 posts

See which fixers apply to your account.

About 5 minutes to connect with read-only roles. Results typically within 24 hours.