Best practices for AWS Billing Conductor

This section highlights some best practices for when you're working with AWS Billing Conductor.

Understanding the importance of the primary account join date

The date when the primary account joined your organization defines the historical boundary for pro forma costs for that billing group. If you choose a primary account that was created or linked to your management account in the middle of the month, the pro forma costs won’t include costs from other accounts in the billing group, including accounts that were part of your organization before the primary account joined.

For example, let's say that the primary account joined your organization on October 15. The pro forma bill for all accounts in the billing group will only include the cost and usage starting from that date. The pro forma bill starts on October 15, even if other accounts in the billing group have been members of the organization before the current month.

There will be a discrepancy between the billable and the pro forma billing domain for the billing group’s first month. The pro forma domain won't include any usage accrued before October 15. After the first month, the pro forma costs will capture all usage.

To avoid this initial discrepancy between the billable and pro forma data in the first bill for the billing group, choose a primary account that was linked to the management account for the entire month or earlier.

Controlling access to AWS Billing Conductor

The Billing and Cost Management is only accessible to users who have access to the payer or management account. To grant IAM users permission to create billing groups and see the AWS Billing Conductor Key Performance Indicators (KPIs) in the Billing and Cost Management console, you must also grant IAM users the following:

• List accounts within Organizations

To learn more about giving users the ability to create billing groups and pricing plans in the AWS Billing Conductor console, see Identity and access management for AWS Billing Conductor.

You can also create AWS Billing Conductor resources programmatically using the AWS Billing Conductor API. When you configure access to the AWS Billing Conductor API, we recommend creating a unique IAM user for allowing programmatic access. This helps you define more precise access controls between who in your organization has access to the AWS Billing Conductor console, and the API. To give multiple IAM users query access to the AWS Billing Conductor API, we recommend creating a programmatic access IAM role for each.

Understanding the AWS Billing Conductor data set

While the AWS Billing Conductor data models share many similarities with the standard AWS Billing data model, there are a few differences.

The AWS Billing Conductor does not include:

• Credits (redeemed at the payer or linked account level)

• Tax

• AWS Support charges

Additionally, the AWS Billing Conductor shares reserved instances and Savings Plans with the accounts placed within the same billing group, irrespective of your sharing preferences in the standard billing domain.

Understanding the AWS Billing Conductor computational logic

The AWS Billing Conductor computation is flexible to the changes that you make in a given month, while retaining the historical integrity of your prior period billing data. This is best described with an example.

In this example, we have two billing groups, A and B. Billing group A starts the billing period with accounts 1 through 3 in the group. At mid-month, the payer account moves Account 3 to Billing Group B. At that point, the re-computation of the costs for Billing Groups A and B are required to accurately model the latest change. When Account 3 is moved, Billing Group A’s usage is modeled as if Account 3 was not a part of the billing group during the current billing period. Additionally, Billing Group B’s usage is modeled as if Account 3 was a part of Billing Group B since the beginning of the billing period. This approach eliminates the need to calculate complex rates and chargeback models when accounts move across groups within the billing period.

Billing Group A	Days: 1 - 15	Days: 16 - 30	End of Month
Account 1	$ 100	$ 100	$ 200
Account 2	$ 100	$ 100	$ 200
Account 3	$ 100	N/A	N/A
Total	$ 300	$ 200	$ 400

Billing Group B	Days: 1 - 15	Days: 16 - 30	End of Month
Account 4	$ 100	$ 100	$ 200
Account 5	$ 100	$ 100	$ 200
Account 6	$ 100	$ 100	$ 200
Account 3	$ 100	$ 100	$ 200
Total	$ 400	$ 400	$ 800

Understanding the AWS Billing Conductor update frequency

AWS billing data is updated at least once a day. AWS Billing Conductor uses this data to compute your pro forma billing data. Custom line items that are generated to apply to the current month are reflected within 24 hours. Custom line items that are generated to apply to the prior billing period might take up to 48 hours to reflect in a billing group AWS Cost and Usage Reports, or on the bills page for a given billing group.

Understanding the differences between AWS Billing Conductor AWS CUR and standard AWS CUR

There are a few differences between the standard Cost and Usage Reports and pro forma AWS CUR created using the AWS Billing Conductor configuration.

• The standard AWS CUR computes the cost and usage for each account in your consolidated billing family. A pro forma AWS CUR per billing group only includes the accounts in the billing group at the time of computation.

• The standard AWS CUR populates the invoice column once and invoice is generated by AWS. A pro forma AWS CUR doesn't populate the invoice column. Currently, no invoice is generated, or issued by AWS based on pro forma billing data.