How-to chargeback shared services: An AWS Transit Gateway example

The consolidated billing feature of AWS Organization helps customers streamline billing and payments for multiple AWS accounts to one single invoice, accelerating migration, innovation, and scalability. Moreover, security and compliance can be centrally governed and user-based permission management is simplified. However, it can complicate internal cost allocation processes when it comes to shared services. For instance, centrally purchased commitments, data transfer, and networking costs are often billed at one central account, but often shared and used by other accounts within the organization.

In this blog, we will review how to define a chargeback and cost allocation strategy, and then walk you through a reference architecture to build and automate the chargeback process. The example will provide prescriptive guidance to chargeback AWS Transit Gateway costs. It runs in a centralized Networking Account shared with multiple usage accounts; the singular Amazon Virtual Private Clouds (VPCs) are used in multiple regions.

Four steps to design a chargeback strategy

Chargeback means to allocate central service spend to cost units based on a strategy suitable for a specific financial management process. For customers, this will be charging the cost occurred from one shared services account to different financial cost categories suitable for a customer reporting process. They can be multiple linked accounts, cost categories, resource tags, or any other categories that make sense.

This blog presents a four-step approach to designing a chargeback strategy:

1. Decide on the cost units to chargeback to
2. Calculate the total cost of the shared services
3. Choose a distribution logic – equitable or proportional
4. Gather the data to chargeback accurately

This strategy can be applied to shared services; for instance, central compute savings plans, enterprise support cost at billing account, etc. The Optimizer Data Connection Lab is available to automate the chargeback process.

AWS Transit Gateway example

Let’s walk you through an AWS Transit Gateway chargeback strategy. AWS Transit Gateway is a central hub that connects VPCs and on-premises networks, acting as a cloud router. It simplifies peering relationships by only adding a new connection at a time, with the possibility to expand to different regions with inter-region peering. In this example, it is deployed in a centralized networking account. Then, usage accounts attach VPCs (shown as accounts A, B, and C in the diagram below) via transit gateway attachment and peering.

Figure 1. AWS Transit Gateway reference architecture

AWS Transit Gateway is charged per attachment and per GB data processed; each is billed differently. The attachment is billed at each individual account with the AWS Transit Gateway. The data processed is only billed at the central networking account. The invoice for each end user’s individual account will NOT include data processed through the AWS Transit Gateway. Therefore, we need a chargeback strategy to allocate the data processing cost to each end user.

Here’s where we execute each of the four chargeback strategy steps:

1.  Decide on the cost units to chargeback to

In this example, the reseller is selling AWS Transit Gateway service to end users, who are represented as linked accounts in the AWS Organization and independently mapped to region-specific cost centers. So, these linked accounts are the cost units that need to pay for their share of the processed data.

2. Calculate the total cost of the shared services

As previously mentioned, data processing costs need to be properly allocated. AWS Cost & Usage Report (CUR) and Amazon Athena can be used to query and calculate. For other services, this library of queries in the Well-Architected lab is helpful to build other customized queries for other services.

Below is the query to calculate the total cost of the shared AWS Transit Gateway data processing costs:

SELECT bill_payer_account_id,
    bill_billing_period_start_date,        
    CAST(
    SUM(
        CASE
        WHEN (
            line_item_usage_type LIKE '%VPN-Usage-Hours:%'             
            OR product_group = 'AWSTransitGateway'
        ) THEN line_item_unblended_cost ELSE 0
        END
    ) AS DECIMAL(5, 2)
    ) "Total_Cost"
FROM {YOUR_TABLE}
WHERE line_item_usage_account_id ={YOUR_NETWORK_ACCOUNT_NUMBER}
    AND (
    line_item_operation = 'TransitGatewayVPN'
    OR line_item_operation = 'TransitGatewayVPC'
    OR line_item_operation = 'CreateVpnConnection'
    OR product_group = 'AWSTransitGateway'
    )
    OR product_product_name = 'AWS Direct Connect'
    AND line_item_line_item_type <> 'Tax'
   GROUP BY 1,2 

3. Choose a distribution logic

With the output of the Amazon Athena query, we have the total spend for data processing. The next step is to determine how to charge it back to the usage accounts. There are two different options: 1) the equitable logic distributes cost evenly among all the usage accounts. 2) the proportional logic distributes according to share of the usage.

In this example, each usage account downloads and uploads different amounts of data from the central networking account. Hence, we choose the proportional logic since it ensures that each user is paying and only paying for the share that what they used.  (Here’s an example of using equitable logic to build a chargeback/showback model for Savings Plans using the CUR.)

4. Gather the data to chargeback accurately 

Now that we’ve decided which logic to use, we need to collect the data so we can chargeback to the usage accounts. Amazon CloudWatch collects NetworkIn(Upload) and NetworkOut(Download), which reflect metrics of data processed through AWS Transit Gateway.

Based on our proportional logic, we’ll use this calculation to find the % of usage:

NetworkIn(Upload) + NetworkOut(Download) per usage account/ total data processed in network account

Then, we’ll multiply this by Total Cost of AWS Transit Gateway from the Amazon Athena Query calculated in Section 2:

% of usage x total cost = chargeback cost per usage account

For example, if the central networking account incurred $100 for data processing with a total of 10000 GB processed, an end user account with 100 GB upload data and 500 GB download is accountable for 6% of the total data processed. Therefore, $6 cost will be allocated to that end user’s account (6% * $100 = $6).

In this example, we showed how to proportionately allocate the shared data processing cost of AWS Transit Gateway to each end customer. For data source, it pulls the total shared cost from the CUR through the Athena query, and connects it with the share of usage collected from Amazon CloudWatch metrics. By joining these two data, the total % of usage cost is the final chargeback amount.

Figure 2. AWS Transit Gateway chargeback solution reference architecture

Using the Optimization Data Collector Lab

Want to automate this logic for your AWS Transit Gateway chargeback? You can use the Optimizer Data Connection Lab, which presents a Cloud Formation template to gather data from multiple resources across an AWS Organization. It automates the data connection infrastructure for your chargeback strategy. The lab collects Amazon CloudWatch metrics,  uploads to a S3 bucket, and provides you with the relevant Amazon Athena queries to find these costs.

If you have a chargeback strategy in mind after reading the blog, try to deploy it with the Optimizer Data Connection Lab to automate your strategy!

✔️Check it out: Optimizer Data Connection Lab