Cost Allocation Blog Series #1: Cost Allocation Basics That You Need to Know
If it’s Everyone’s job, it’s No One’s job. On our team, we take this lesson to heart and always make sure there is a clear owner for everything we do. This helps ensure everyone is responsible for specific tasks or goals, and will not be bystanders, assuming someone else will pick up the work.
The same old principle applies to the cloud financial management. When costs are seen as a public good or organizational overhead (aka “IT tax”), end users can overlook the importance of building cost-efficient applications or making rational, informed purchase decisions related to their applications. The best way to raise cost awareness is to make users accountable of their own cost and usage – a process that starts by making costs visible internally. There are various approaches to meet this objective. For example, we’ve heard organizations send out monthly reports of cost and usage information by teams to the entire organization, put up a big display monitor and project these information to increase the visibility. We know a few engineers who like a good competition and the use of gamification to create a friendly competition internally for teams to rival for the most cost-efficient applications has led to impressive results. Others apply a more commercial method, in which they’ll actually allocate the cloud costs back to the actual teams, projects or business initiatives. With this method, some allocate the costs evenly across cost centers or business units; others may spend more time in adjusting the costs before allocation, for instance to add premium charges to cover additional IT labor costs, or modify the actual costs to either incentivize or discourage the consumption of certain cloud services.
We got a lot of questions about how you can set up these cost allocation models, so let’s look at a few basic steps.
Whichever approach you plan to use to build your cost allocation model, you need a clean AWS account structure to begin with. We recommend you designating a person or team to design the account structure and policies, and implement these across the organization. Depending on your objectives, you can choose from a variety of account structures to establish the right level of hierarchical account order and logical account groupings. For example, you can centralize the account creation and permission controls in a single account, store and process AWS log and configuration data in a parent logging account, and/or centrally manage the creation and distribution of pre-approved server images, AWS Cloud Formation templates, and AWS Service Catalog. You can choose to use one or a combination of these account structures. You can read more about best practices of the multi-account strategy from this whitepaper.
With AWS IAM, you can create users, store and manage their identities, and specify user access to certain AWS services and activities. You can also create roles and manage permissions of these roles to certain operations or AWS resources. Users can assume the roles and get access to services or operations as a way to delegate the permission control. You can also enable federated AWS access for your workforce, such as migrating user attributes from your identity providers to AWS and implement access permissions based on these attributes.
AWS Control Tower allows you to quickly set up and provision a multi-account environment and employ best-practices blueprints, so you can configure things such as federated access with AWS Single Sign-on, centralized logging, and implementing account baselines with network configurations. You can also govern accounts centrally at scale, while AWS Control Tower helps enforce and provides a summary report to show the compliance with your policies, such as Service Control Policies (SCPs).
You can create a holistic view of your organizations’ accounts using AWS Organizations to reflect your business needs. You can centrally manage and govern your accounts, share resources across accounts, consolidate billing to a single payment for all of your AWS accounts. You can also deploy AWS Landing Zone into your AWS Organization account. You’ll work with AWS Solutions Architects or your Professional Services consultants to create a customized baseline of your AWS accounts, networks and security policies.
Tag allows you to assign metadata to your AWS resources. You can define your own key and value of your resource tag, so that you can easily manage and filter your resources, create AWS Resource Groups and enable granular access control for users. General tagging best practices are shared in this whitepaper.
In this blog, we will focus on tagging for cost allocation purpose. To better understand where usage is coming from and identify areas for savings, you need to create and implement your own tagging strategy. You can leverage several AWS resources for this:
You can add, edit, or delete tags in the service console or API one at a time, or use AWS Tag editor to add, edit, or delete tags of multiple resources at once. Once you create your resource tags, you can activate your cost allocation tags in the Billing and Cost Management console. There are User-defined and AWS-generated cost allocation tags. Based on the types of services you need to tag, and the level of customization you require, you can use one of these two cost allocation tags or a hybrid of both. AWS Cost Categories allows you to logically group accounts and resources with attributes, such as tags, to better map your cost and usage information to your organizational structure.
Since you can’t retroactively tag resources, it is important to start tagging as soon as possible and maintain the consistency of your tagging strategy. You can use AWS Organizations Service Control Policies (SCPs) to enforce the tag usage and AWS Organizations Tag Policies to keep the consistency of your tag usage, for instance, tag keys and values, the case treatment of these information.
3. Reporting on Shared Costs
When you allocate costs back to individual teams, projects, or initiatives, you will run into situations where you can’t easily identify owners for certain costs, for example, Data Transfer costs, AWS Support fees, or other costs that are shared by all users. We recommend you to reach an internal alignment on how to allocate these costs. AWS Cost Categories is a great way to group shared resources. There are getting started tips for AWS Cost Categories in this blog.
AWS provides reporting tools, such as AWS Cost Explorer, and AWS Cost and Usage Reports, that can help generate the cost and usage information at your desired level of granularity. You can view shared costs in AWS Cost Explorer by filtering and grouping the cost and usage information via cost allocation tags and cost categories that you created. With AWS Cost and Usage Reports, you receive these reports in your designated Amazon S3 bucket. You can set up the AWS Cost and Usage Report integration with Amazon Athena, which allows you to easily query your detailed cost and usage information. If you grant Amazon QuickSight the access to Amazon Athena and Amazon S3’s bucket of your AWS Cost and Usage Reports, you can get the Data Sets you created in Athena and use various types of visuals in Amazon QuickSight to help you better understand the cost drivers.
As we help customers better organize and report AWS cost and usage information, we have curated tips and tricks of how to leverage AWS resources to achieve your reporting and cost allocation needs. In the coming weeks, we will present several blogs that can provide more details in the strategies and tactics mentioned in this blog. You will have more hands-on instructions on how to use AWS resource tags, enforce and validate your resource tagging strategies, visualize specific costs in your AWS Cost and Usage Reports, and build your cost allocation strategies with AWS and partner solutions.