Strategizing Your Billing Approach Within AWS

Cloud billing can be a tedious and complicated task if not planned for correctly. If you do not have a well thought out plan on how to approach your AWS bill when charging back to various departments or projects, things can get messy when attempting to divide the bill correctly. In this article we will discuss three methods to make strategizing your approach ahead of time to make things much easier when it comes to invoice time.
 
Cost Allocation Tags
If you are operating out of a single account, you may be faced with the challenge of separating your costs associated with various departments or projects that are consuming resources within this account. Let's say for example, that you have a development team and a test team that are both consuming AWS resources within a single account, and you need to associate costs for the resources that each team is using to the respective teams. This is where applying cost allocation tags within AWS can help parse out the costs of the resources that each team is using. There are two types of tags that can be used when planning for this solution: AWS-Generated Cost Allocation Tags or User-Defined Cost Allocation Tags. Cost allocation tags must first be defined by the management account owner within the Billing and Management console of the management account. These tags, once activated, can then be attached to AWS resources upon creation. All tags are created and applied as key value pairs. At the end of the billing cycle, tagged resources can then be organized to associate costs pertaining to the tag key that was assigned, making the objective of parsing the overall bill to align resources with the various teams an obtainable task. One thing to consider when taking this approach, is that not all AWS service charges are capable of having tags applied, so there may be a few lingering charges that would appear as untagged which could result in some complications when billing back certain teams or departments if there is not a centrally funded source.
 
Separate Member Accounts
One of the best methods for planning your cloud billing strategy, is to confine all resources associated to a particular project, department, team, or billable entity to a single member account. This can eliminate the need in most scenarios to apply tags to resources for billing purposes, and removes the issue of untaggable items within AWS. By confining everything to a single member account, you can consolidate spend across the board, making the billing process a much easier and streamlined effort. This approach can be further simplified with the provisioning of member accounts through AWS services like account factory within AWS control tower, by standardizing the way member accounts are provisioned. If you are intending to take this approach, having a standardized approach to provisioning new accounts can keep the process quick and easy.
 
Organizational Units
If you are in a situation where you have multiple member accounts that belong to a single billable entity or funding source, then you may want to consider grouping these accounts into what are called Organizational Units or OU's. Using this method, you can group member accounts together to bill back to a single funding source. This will require AWS Organizations to accomplish, and is typically the ideal method to use when planning to have a larger cloud footprint. If we look back to the previous cloud billing strategies of using cost allocation tags to separate costs within a single account, and billing back to separate member accounts, using Organizational Units can essentially accomplish both. Let's say that we have Project A and Project B, each using separate resources for the Research Department. Let's also assume that we need to track costs associated with each project, and that the Research Department team is responsible for paying the bill. We could set up an Organizational Unit for the Research Department, and create member accounts associated with each project. By doing this, we could track costs associated with each project without setting up cost allocation tags, confine all of the resources belonging to each account within a separate member account, and make sure that the bill goes to the Research Department for the total of both projects.
 
In summary, when planning on moving workloads into AWS, you should consider your billing situations and carefully plan ahead. Will you be operating within a single account, and using tags to associate costs to various different AWS services? Will you be confining all services belonging to a single billable environment within a single member account, so that you can invoice that account and not have to worry about tagging? Will you need to track costs across various different environments, and associate those costs to a single department that can be categorized into an Organizational Unit? Depending on your scenario, strategizing your billing approach is an important task that should be thought through ahead of time. Using Cost Allocation Tags, Separate Member Accounts, or Organizational Units should be able to solve for your approach.