Though the added detail allows for more accurate cost allocation, it also causes the cost allocation process itself to become more complex (and potentially inconsistent) for those who are mixing data sources. We’ve definitely seen this to be true for our own customers as they make an effort to tie Cloudability reports back to AWS bills and other data. There are three main spots we see customers get stuck when tying data sources back to their AWS bills.
Possibly the most common point of confusion is when it comes to costs associated with Data Transfer. Data Transfer isn’t actually a service in itself, rather it’s the cost (or fee) you pay for transferring data within a service or between services. In the detailed billing files, costs are handled by associating the cost with the service the transfer relates to. So, if you look at your EC2 costs within Cloudability, you will to be able to break out the part which relates to a data transfer by using a smart filter. Great! Now what do you see if you look at your bills in the AWS console? You may see something like this:
Ouch. At a very high level, AWS Data Transfer cost is broken out separately. What you are likely to see is that EC2 costs (and other services like S3) will appear to be lower than you may have expected, with the missing cost captured in the Data Transfer line item. This isn’t the end of the world; when all is said and done your totals will still match up, and we will still be able break out the Data Transfer component with some smart filters. Here is an example focused on EC2 data transfer.
It’s worth noting that the basic tools AWS offers for exploring your costs will behave in the same way as Cloudability, with data transfer fees being embedded in other service’s costs.
The next area of confusion we’ll discuss is related to tax. If your infrastructure is running in an AWS region where local taxes apply, you’ll be taxed accordingly. A well known example of this is when running infrastructure in ap-southeast-2 (Sydney) you’ll be charged a 10% goods and services tax (GST). In a previous iteration of AWS billing files, there was something called the Cost Allocation Report. This was a CSV file in which each resource was listed only once for the month. For example, if you had a particular EC2 instance it would exist as one row in this file, with summary cost data for the month so far. This would include the cost before and after tax. This was handy in some cases, but there was very little granularity, and this was the primary reason we switched over to using the detailed billing files here at Cloudability. The way these files handle tax is completely different. The rows in the CSV file which represent resource hour costs don’t contain anything pertaining to tax at all, but there are two separate cost metrics unblended cost and blended cost. Instead the tax component is summarized for each linked AWS account at the very bottom like this:
You’ll notice the cost is listed twice for the summarized tax, once for blended, once for unblended. So how does tax appear in Cloudability? As you might expect it will appear as its own line item in cost reports. Here is an example of how it may show in your cost report:
As you may guess, due to the way AWS detailed billing files work there’s no way to directly link this tax back to the many resources that generated it. In summary, use the metric Cost (Total) in your cost reporting and the Tax line items will appear just fine.
The last thing we’ll briefly cover is the fact that Amazon will send you separate invoices for some items. Generally, you’ll get an invoice for all of your actual resource usage, invoices for each of your upfront Reserved Instance purchases, and potentially an invoice for enterprise support. Be comfortable to know that all of the costs within these invoices are melded together into the detailed billing files we get from Amazon. If you were to add up all your separate invoices for a month these would match up to a monthly report you’d be able to generate in Cloudability.