There are an increasing number of AWS billing tools supporting an array of use cases. In this article we introduce a subset of the AWS tools which we consider to be essential, explain the most common challenges facing FinOps practitioners using these tools, and recommend an approach for organizing your resources that lays the proper foundation for managing complex billing scenarios.
Basically, there are two approaches to organizing your AWS resources: you can either use a high number of separate AWS accounts, or you can use fewer accounts but rely heavily on naming conventions and tagging to track resources.
In the past, managing multiple AWS accounts was typically considered an issue of governance sprawl that caused administrative overhead, so most companies leaned towards the latter approach. However, as AWS tooling has evolved (along with the AWS Well-Architected Framework of best practices which include AWS Organizations), the exact opposite has become true. Today, an AWS account offers the best method for establishing security and billing boundaries to organize your AWS spending and align with the native tooling’s functionalities.
Let’s start with the four most common FinOps challenges that can be more easily solved using a multi-account (AWS Organizations) strategy.
Applying upfront commitments and payments (such as reservations and savings plans) to the correct resources is a challenge when those resources are not properly organized.
This is because AWS assigns commitments to resources automatically at the level of an account boundary; the upfront commitment made when purchasing a reservation within an account could get assigned to any of the resources in that account. Tags cannot help you direct these assignments to the correct destination, either.
This could, for example, cause an upfront payment you have made for a production e-commerce application to get used in a pre-production or development environment instead. Your payment could even wind up benefiting an entirely different cost center.
As you can imagine, these assignment mishaps can cause major financial complexity when annual upfront commitments and payments must be amortized down to seconds of usage. And this problem only magnifies as an organization scales if the underlying issue of resource organization isn’t addressed.
If you haven’t found out already, lowering your premium support bill requires lowering your total bill. AWS’s Premium Support is an additional cost that is charged as a percentage of your total AWS spend.
When your company maintains AWS resources owned by different departments, their individual inefficiencies (re: wasted spend) can be magnified by this percentage-based fee and be charged as an overhead to all departments—regardless of usage efficiency. It does not matter if they even take advantage of Premium Support or not.
The same issue of fairness holds true for line item purchases in your bill, such as third-party software and services available via the AWS Marketplace.
|AWS Developer Support||AWS Business Support||AWS Enterprise Support|
|Greater of $29 or 3% of monthly AWS charges||Greater of $100 or
||Greater of $15K or
Most companies beyond a certain size take advantage of the AWS Enterprise Discount Program (EDP). This program provides a discount against an aggregate annual spending commitment. However, the pricing of each individual AWS resource (such as an EC2 or Lambda function) doesn’t reflect the discount.
To view the discount’s application, you must spread the discount’s value across each cost center as you implement a usage-based charge-back model. This, however, adds more complexity. The same holds true for private pricing agreements that provide a discount to your data transfer charges, (for example, if you are willing to commit to an annual volume of usage).
On the other hand, negotiating a private pricing agreement with favorable terms is easier when you know exactly the type and total of resources your organization is consuming. For example, let’s say your organization has 4 AWS accounts. Between them, you’ve noticed a large consumption of Outbound Data Transfers. Individually, these expenses may not justify getting on the phone with AWS and asking about their Enterprise Discount Program. But together, consolidated as one bill? You’ve got a reason to negotiate.
Even after you separate your resources by AWS account boundaries, you are likely to still have to track consumption by application, project, and infrastructure components so that you can isolate inefficiencies and over-spending. In such a scenario, calculating the bill for a particular cost center, down to dollars and cents, requires cost allocation reports.
Cost allocation reports, however, rely on user-defined tags to add context to your cost data (who is spending, where, on what project). This in turn requires policies to enforce complete and accurate tagging of all of your resources. We deemed it worthwhile to cover this topic in depth in this guide.
Where to Start: AWS Tools for Organizing
Now that we’ve explored why organizing your cloud resources is critical to your FinOps strategy, let’s take a quick tour of the tools native to AWS that enable successful accounting.
AWS Organizations enables businesses to build out a clean hierarchical structure of accounts and sub-accounts, known as member accounts, that you can organize into groups, known as Organizational Units (OUs).
With OUs, your business can endlessly nest member accounts tied to projects, geographies, departments, or applications in such a way that automates the segmentation of your spend without even tagging the resources owned by the accounts.
The head of an organization is known as the management account. Once you have created a management account, you can begin to invite all existing business accounts under its umbrella and begin to organize them into OUs.
Want to learn more about AWS Organizations? Check out our in-depth guide.
Consolidated Billing is a feature that enables businesses to roll-up all accrued costs throughout their AWS accounts into one bill owned by a management account. Setting up Consolidated Billing can be a quick win for FinOps practitioners who need to begin rounding up costs.
Consolidated Billing is available for both standard management accounts and those using AWS Organizations.
Cost Explorer is a visualization tool that enables you to explore your spend across different AWS Services, such as On-Demand EC2 and Reserved Instances. Use Cost Explorer to get more familiar with the basics of your businesses weekly, monthly, and quarterly spending trends. It is the easiest tool to access and use as compared to all of the other cost management tools offered by AWS, so it should be your place to start.
The user interface is simple and easy to use, however its downside is it doesn’t contain any resource usage information. Some third-party vendors combine cost and usage into a single view as a value-added software as a service offering.
The Cost and Usage Report has recently replaced AWS’s Detailed Billing report as the primary report for granular cost data collection. Like many of the tools listed here, CUR becomes more valuable when you add consistent structure to your inventory (such as OUs and inventory tags).
This is because CUR includes this information as additional metadata about your AWS services, Reserved Instances, pricing, and Savings Plans. For example, with CUR, you can itemize everything down to the account or Organization level by product code, usage type, and operation.
Think of it as a second-by-second log file of all of your consumption and spending. As such, it contains hundreds of thousands of lines depending on the size of your environment, and it’s formatted in a way that seems more intended for programmatic consumption. Some third-party cost management tool providers help decipher the content and use it to formulate actionable recommendations.
Cost Categories are a relatively new addition to the cost management toolset and often overlooked by most FinOps administrators. They enable you to group cost and usage information and align those with your cost center reporting needs. These groups are defined by user-specified filters that include conditions on accounts, services, tags, charge type, and more. You can then add these categories to reporting templates, which helps with automating the mapping of your spend.
Tags have been mentioned a few times already in this article. But let’s get into a bit more detail. Cost Allocation Tags are based on regular operational tags, however they require a simple manual designation in the AWS console to be indexed by AWS for use with Cost Explorer and CUR reports.
In other words, you specifically select a subset of your operational tags to become Cost Allocation Tags. Each tag consists of a user-defined key and a value. Cost Allocation tags make it easier to manage, search for, and filter resources by dimensions like purpose, owner, environment, or other such criteria.
Here are tag examples for two resources:
If your business already has tags in place, it’s important to do a quick quality check and ensure that:
Wondering a bit more about this topic and how to achieve long-term success with Cost Allocation Tags? Check out our in-depth guide.
So far, we’ve identified the common challenges of accounting for cloud resources and surveyed the native AWS tooling available to enable accurate cost allocation. Next we will explore some prescriptive best practices for delivering an organized inventory by leveraging some of the tools mentioned here.
If you would like more information on some of the most important tools before jumping into our best practices, feel free to skip to our Cost Allocation Tags and AWS Organizations articles.