Commvault Announced Acquisition of Clumio
Having trouble understanding your AWS backup costs? You definitely aren’t the first. One of the many conversations we have with customers has to do with even just understanding what their existing backup-related costs are. We have realized this is a very common mystery that our customers are trying to solve. This blog post will cover the top five things you need to know about your AWS pricing so that your backup costs don’t get out of control.
First, navigate to your AWS bill by logging into the AWS Management Console, click on your username in the top right (Figure 1: Step 1), and click “My Billing Dashboard” (Figure 1: Step 2). Once on the dashboard, on the left navigation under “Billing”, click on “Bills”. At the top of the page, you can select any month you want to analyze.
Figure 1: How to navigate to your AWS Bill
Now, let’s take a look at the top five things that you need to know about your AWS backup bill:
EC2/EBS volumes are a critical part of any AWS environment. So it will be no surprise that this tops our list of things to understand on your AWS bill. Navigate to the “Elastic Cloud Compute” part of your bill and expand it. Then expand the region where your EC2/EBS resources and backups are. And finally, expand the “EBS” section.
There are two things you look for on this part of the bill, namely the size of your EBS volumes, and the size of the backups themselves.
Figure 2: EBS and EBS Snapshot portion of the AWS Bill
We will only be interested in “GB-Mo” (Figure 2: Step 1) consumption line items. Next, look for all occurrences of “provisioned storage” (Figure 2: Step 2) to add up all your EBS data sources. In our example, we have 4,493GB of EBS Volumes. You may see multiple line items with “provisioned storage” on it so be sure to add all those up. This gives you a good idea of how much data you need to back up. However, it’s not perfect. Figure 2 shows how much capacity you reserved for EC2 instances, but not how much you have utilized. Utilization is important to know because this is the foundation of how your snapshot sizes are determined. After all, you don’t need to backup unused capacity that does not contain any of your data! There are ways of figuring this out, but we will cover that in a later post. Let’s assume you are backing up all volumes and utilizing around 80%. That would be 3,594GB utilized (4,493 x 0.80).
Now, let’s move onto the size of the backups themselves. We will stay in the same section of the bill (Elastic Cloud Compute → Region of interest → EBS). Now we are looking for any line items that reference “snapshot” (Figure 2: Step 3). In our example, we have 559GB of snapshots taken. In this case, our snapshot size is quite low and may indicate that this is a relatively new backup policy or that we don’t have a disciplined backup policies in place. Over time, backup sizes can be between 2-8x the size of the utilized figure, depending on the retention policies in place. It can get even larger if you aren’t expiring snapshots in a disciplined manner.
Now you should have a good idea of how much EBS data you need to protect and how large your current EBS backups are.
Next, let’s take a look at Amazon RDS (Amazon Relational Database Service) which can be another critical part of your AWS infrastructure. This is often where your structured data resides, and similar to EBS, we want to find how much data we have and the size of the backup. RDS has two classes of databases that it treats differently: Aurora and non-Aurora. The key thing to note between the two is that Aurora bills you on the auto-sizing utilized capacity versus the entire provisioned capacity. Both Aurora and non-Aurora come with up to 100% of your allocated database capacity in free backups. So, if you have 100GB of RDS databases then you get 100GB in backups free. After that, you are billed upwards of $0.095/GB for your backup so you definitely want to closely monitor your backup costs here.
Figure 3: RDS and RDS Snapshot portion of AWS Bill
To find out how much RDS data you have, look for all “GB-month” (Figure 3: Step 1) occurrences that don’t have the word “backup” in them. In our example, it totals 128.35GB of RDS. If you want to make your estimate more accurate, you would need to offset your non-Aurora databases by an assumed utilization rate since you aren’t likely to be consuming 100% of your database. And backups are based on your utilized capacity, not provisioned (unless you are doing cross-account backups).
Now let’s determine the size of our RDS backups. For this, we will look for all occurrences of “backup” (Figure 3: Step 2) in the RDS section of the bill. In our example, we have 4.7GB of total RDS backup. However, there are a couple of things to look out for here. One, we have multiple AWS regions in our example and two, remember that we get free backups equivalent to the storage we are consuming on RDS. But, the free backup you get is not combined into one pool of free and instead is isolated to each RDS class and AWS region. For our example, our Aurora had 0.07GB of usage and a backup size of 1.668GB. That means we actually have a backup size of 1.738GB (0.07GB free + 1.668GB on top of free). For our non-Aurora, we have 128GB of provisioned storage and no snapshots/backups in this region. This implies that we have not yet exceeded 128GB in backup sizes and therefore are not incurring any expense.
However, I am backing up my RDS database to another AWS region and incurring an expense there. As you can see, the free backup does not cross over database types and AWS regions. Is it now clear as mud? Yes, navigating your usage and backup is complicated which is exactly why we thought we’d help you navigate your bill.
To find your Amazon S3 costs on your AWS bill, navigate and expand “Simple Storage Service”. Because S3 is not currently segmented into “provisioned” and “backup”, you will have to possess some knowledge about your architecture. For example, if you are not using S3 except for backup, then you can assume all your S3 usage is only for backup. You will essentially add up all your “GB-mo” (Figure 4: Step 1).
Figure 4: S3 portion of your AWS Bill
Ahh, S3. The dumping ground for data. Many customers often have tried using scripts or third-party backup software to backup their EBS volumes to S3. After all, S3 is cheaper than EBS snapshots. While true, what is not considered is the cost of moving it there which often involves using your own EC2 resources and temporary EBS snapshots that YOU pay for. Often the break-even for moving EBS snapshots to S3 is three or more months, making it not a cost-effective solution for your daily and weekly backups. On top of that, customers are typically paying for a third-party snapshot manager license to manage all this that adds a hidden tax to the total cost of your backup that can add 25% or more to your total backup costs.
Another issue with S3 is the use of S3 versioning which are full copies of your S3 objects for every small change that occurs. So, if your application updated anything in your objects, you could easily have multiple complete copies of your data. And this immediately negates the cost savings you had by moving it to S3 in the first place. We often have customers that tried backing up to S3 but at the end of the day ended up saving more by leveraging Clumio’s Protect solution that simplifies backup considerably.
Transfer costs aren’t typically one of the most expensive items on your bill but they can be a pretty heavy tax if you aren’t careful. Take a look at the “Data Transfer” section of your bill. Most of the time, this is billed at $0.02/GB and it’s not a per month charge, like almost everything else on AWS, but is instead a one-time “tax”. If you are doing long term backups into another region, this can be another hit to the pocketbook. If you are putting your daily backups in another region, this can add significant costs to your overall TCO.
For example, if you are backing up 1GB a day at $0.05/GB (average AWS snapshot price) and are doing a daily backup with a retention period of 30 days, then that cost would be $0.05/GB plus the $0.02/GB transfer cost. Therefore, your total cost per GB/month becomes $0.07/GB, which equates to a 40% transfer “tax”. Alternatively, if you are retaining your data in the other region for longer periods, this transfer “tax” becomes lower for each additional month you leave your data there.
As you can see, your backup plan may add significant costs that you must consider.
One of the harder things to understand is how much of the backup snapshots you have in your AWS accounts are even needed. Your bill will just show you how much you are spending in a region, but doesn’t provide the level of granularity to the age of the snapshots or even what asset it is associated with. To even approach this problem, you must use more sophisticated tools such as AWS Cost Explorer or API’s. Life would be so much easier if there was an AWS backup solution out there that managed all of these problems for us.. 🙂
Clumio Protect has a free in-account AWS snapshot manager that will make sure snapshot management is a breeze. This feature is typically a licensed product from snapshot managers on AWS Marketplace and these third-party fees can additionally increase your backup bill by 25%. Although, most of our customers prefer just moving their snapshots to Clumio’s air-gapped backup service that provides added ransomware protection at less cost per GB than even native AWS snapshots.
One of the many values Clumio brings to our customers is helping them understand their existing backup costs. We do this through bill analysis, understanding their intended backup policies, and even more detailed analysis of their snapshots. Customers are literally spending 15 minutes to set up Clumio Cloud Protect thru AWS Marketplace and getting Enterprise-grade air-gapped backup for $0.045/GB versus AWS Backup’s $0.05/GB (EBS).
Don’t understand your backup bill? Can’t wait? Contact us and we would be more than happy to help you discover your true backup costs and what they could be.