Managing your AWS bill should be simple. It should tell you everything you need to know, display your charges and line items clearly, have solid attribution and be easily accessible.

Sadly, things are never that easy when it comes to AWS.

But that’s why we’re here - to give you the simple rundown that Amazon doesn’t. You need to know what the different ways of finding and viewing your AWS bill are, what each section of it contains (and means), and how to deal with what it doesn’t tell you.

That’s why this post will show you:

• Where to find your AWS bill
• How to read your AWS bill
• What’s missing from your AWS bill
• Other issues with AWS bills

Let’s get started.

Where to find your AWS bill

Let’s start simple - how to find your AWS bill.

The easiest way to find and access your AWS bill is to open your AWS Billing console. This requires a direct login to AWS, which can immediately present a problem, as employees from finance tend to rarely have this.

However, assuming that your team has been given a dedicated direct login, AWS Billing console allows you to view and analyze your AWS bill in almost any format. Whether you prefer to view your bill as a PDF, CSV, or in the console itself, AWS Billing console has you covered.

The other option you have is to be emailed your AWS invoices directly. This needs a little forethought and setup, but can completely circumvent the need for a dedicated AWS login.

Inside AWS Billing console you’ll have the option to set up your invoices to be sent to specific email addresses, even if they don’t have an associated AWS account. You’ll need to have admin permissions to set this up - if you don’t have this then ask your engineering team to do so.

The format your invoices are emailed in is more limited than viewing it inside the console (you’ll receive a PDF), but it’s a great way of keeping your finance team in the loop without requiring a login for them, and training them up on how to use the console.

Remember; AWS is a fine-tuned tool that can be made useless if someone goes in and accidentally changes elements without knowing what they’re doing. Keeping those untrained interactions to an absolute minimum is thus a great way to increase your security and have everything run smoothly.

Plus you won’t have an annoyed engineering team breathing down your neck in the event of a mistake, which is always preferable.

How to read your AWS bill

You’ve got your AWS bill either from the console directly or via an invoice emailed to you. Great! Now let’s split up the different elements of your bill so that we can tell you everything you need to know to understand what it means.

Your AWS bill can be split into four sections:

• Header
• By-service analysis
• By-account analysis
• By-region drill-down

Header

The header of your AWS bill is where you’ll find all of the basic information about what that particular invoice covers. This includes your invoice summary and the general “Summary”.

In the top left of your bill you’ll see your invoice summary. This includes the invoice number, due date, and the total amount due, and is useful for when you just need to know the basics - what you owe(d), and when you owe(d) it.

The first section of your bill proper titled “Summary” will show you your total charges, taxes, and credits. These credits can be acquired through a variety of AWS credit programs which are usually particular to certain services or customer sizes.

Think of your credits as deleting line item charges on a pre-tax basis. They’re not any kind of refund or cash owed being taken off your AWS bill - they’re more akin to offsets or discounts you’ve earned. For example, AWS Activate Portfolio offers up to $100,000 to startups less than 10 years old which haven’t received funding beyond series A.

By-service analysis

Below your header you’ll see the by-service analysis of your bill. This is all of the charges for the organization, broken up by which AWS service incurred the charge.

These aren’t SKUs or conventional merchant invoice line item details, they’re merely summaries of your charges by service.

This breakdown is particularly meaningful for your AWS organization because each AWS service is operated as if it’s an independent business, which makes it difficult for them (and you) to know where to associate their charges. For you, the customer, it’s a nightmare because you’ll likely have multiple uses of the same AWS service across your organization - having an overall figure for S3 storage costs doesn’t tell you anything useful.

Let’s look at an example to fully understand the problem.

Let’s say that you have $100 in S3 costs, but that there are 15 different ways that your software stores and retrieves data in S3. This means that your AWS bill will show that your S3 account is costing $100, but without the by-service analysis you’d have no idea what part of S3 storage and retrieval was costing you the most.

It’s the context that tells you precisely what service and what type of usage is costing you the most. Without that knowledge there’s no way that you can reliably optimize your bill or even know whether you can reduce it without affecting core performance.

As a final note on the by-service analysis, don’t enter these line items into your accounting system individually. They hold no meaning to your overall company operations - they’re useful in relation to your AWS bill but not any further.

By-account analysis

Before diving into the specifics, note that you’ll only have a by-accounts analysis of your AWS bill if your company operates multiple AWS accounts in the same organization. If you don’t have this, you can skip this section.

The by-account analysis is detailed in a section called “Linked Account Allocation”. This breaks apart all of your by-service charges into each subsidiary account in the organization. 

This can be useful depending on how your accounts are set up. If they’re organized by customers, environments, products, or another consistent methodology that correlates to your bookkeeping systems then this breakdown can be massively helpful to simplify your AWS accounting.

For example, say you have an organization with three accounts. You’ve called Account 1 “Production”, Account 2 “Development” and Account 3 “Test”, and each relates to the stages of the product hosted by them.

“Production” is all of your live software, so the charges shown to be resulting from it should be booked to a Cost of Goods Sold account. The other two aren’t running software used by customers, so their charges should be booked to an operating expense account (most likely under research and development).

It’s vital that you check how the accounts are organized with the leadership figures of your engineering team. Making assumptions will completely throw off what you can learn from your bill, so you need to know for certain.

Bear in mind that AWS accounts are often shared too, meaning that you might need to apply a percentage of allocation on an account to divide between multiple business units, GL accounts, customers, etc.

By-region drill-down

If you’re viewing your bill as a PDF, CSV or anything else that isn’t in the AWS Billing console itself, you won’t have access to the by-region drill-down of your AWS bill.

However, if you are in the console, you’ll be able to review all service and account charges by the region in which they’re incurred.

AWS regions are simply the location of the data center being used, and have nothing to do with where user traffic comes from or where a client is located, so there won’t always be a correlation that you can see from this data.

However, if your company restricts your customer usage of systems by the closest AWS region to that customer, you could use the by-region breakdown to build a more effective customer or sales-region cost allocation model.

No matter what you’ll be able to see which region is incurring the highest costs. The usefulness of this data, as we’ve stated above, will depend on how your accounts are set up.

What’s missing from your AWS bill

From everything we’ve listed above, it’s easy to think that your AWS bill shows you everything you could possibly need.

Sadly, that’s not true. There are two key elements that are incredibly useful but missing from your bill and the billing console.

The first is your line item charges. In a typical merchant invoice these will be detailed enough that your finance team can meet with the person responsible for the order and ask why the numbers are what they are. For example, they would usually be able to see if you’ve ordered far more of a specific supply or resource than usual, but an AWS invoice doesn’t give you those details.

The only way to get your line item charges is to go into your Cost and Usage Report.

Cost and Usage Reports (CURs) from your AWS Billing console let you see the specifics of your cost and usage data. In other words, they’re how you can see precisely what you’re spending and why you’re being charged that amount.

They’re also the only way to verify that you’re being billed correctly, and the only way to see what your usage is at all.

In terms of your overall AWS bill, this makes CURs a core piece to understanding why you’re paying the amount you are. By analyzing the data they give you, you should be able to verify to your team that your bill is correct, fair, and isn’t being run up by something you don’t actually need.

For a full rundown check out our post on Cost and Usage Reports.

Returning to your AWS bill, the second major missing item is the actual business purpose of your charges.

Let’s face it, you’re lucky if your engineering team has organized their accounts in a way that makes any sense from an accounting perspective. That’s not a criticism of engineering, it’s just a fact that organizing accounts in that way often clashes with what makes the most sense for their own jobs.

The problem is this; most engineers manage business purpose tracking by using cost allocation tags or cost categories, but AWS bills don’t break down expenses by these tags. Plus, the tags themselves aren’t even mutually exclusive - there’s plenty of chance for expenses to overlap the two.

If you do want to report expenses based on tags you’ll need to dive into the AWS Cost Explorer, which itself will require further access permissions and AWS console experience. In other words, to handle your accounts in the most logical way, you’ll need to be trained with a tool that you otherwise shouldn’t have to use.

That’s not even accounting for the accuracy of tracking AWS costs in this way, as there’s no limit to how many tags can be associated with a particular event. If you plug your costs (with their tags) into your accounting system without vetting every last one of them, the total could easily exceed the invoice total due to costs being present multiple times through multiple tags.

Sadly, the problems with your AWS bill don’t stop there…

Other issues with AWS bills

One of the other main issues with AWS bills is that there’s no limit on creating new accounts or organizations separately from the one you’re monitoring for billing. This can lead to your financial team finding credit card charges on statements while not having any corresponding bill in any of your records.

Think of it like your team having one universal credit card that is properly accounted for and billed, then getting your statement and seeing charges from five other cards that you didn’t know existed. You’re not only going to have to scramble to find out where the extra charges are coming from and examine whether they’re actually necessary (and beneficial), but you’re also going to have to find out how this happened at all without proper attribution.

Unless you spend a very large amount on AWS, your charges are also paid automatically via credit card or direct debit ACH. You have no control over the timing of payment or have the ability to get an extension on your payment terms, so any accidental charges are paid as quickly as intentional ones.

It’s also very difficult to independently verify whether your charges are accurate without going over your CUR in detail. We’ve already mentioned that this is due to line item details being missing from your invoice and the Cost Explorer, but it’s worth saying again because it’s so vital to accounting.

So how can you solve these issues?

The solution? Aimably AWS Invoice Management Software

Here at Aimably, we’re dedicated to making AWS management as simple and painless as possible. That’s why we’ve developed our AWS Invoice Management Software.

Our tool consolidates all of your AWS charges into a single bill, even if those charges come from different accounts or organizations. That means you won’t be left confused and chasing up random charges like you would with a simple AWS bill!

Speaking of covering for AWS bill faults, the AWS Invoice Management Software also validates all invoice totals and subtotals against all line item usage details found in the CUR.

With Aimably, the accuracy of your AWS bill is certain.

To top it all off, you can even build an allocation schedule which is custom to your company’s operations. This will let you divide expenses by GL accounts, business units, customers, and any other accounting segment in use at your company, which you can then import into your ERP for automatic processing.

Don’t let the inherent flaws of AWS hold you back from managing your bill effectively. Click here to start using our AWS Invoice Management Software now!