AWS Account Movement Best Practices
Overview
As partners, you will occasionally need to move accounts at the cloud provider and/or edit your AWS account assignment configuration. To ensure no duplicate cost or incorrect, delayed billing, it is recommended to understand the implications of the change and to follow the best practices. This article discusses potential account movement scenarios and recommended best practices in detail.
Considerations
- If you make changes to PGB before the cloud provider finalizes the previous month’s bill, this could impact the data presented in the customer tenant. For a new bill drop, the previous month’s cost data will be re-processed to reflect the changes to PGB.
- If you are editing the existing billing block, or are creating a new billing block, note that you will not be able to assign any account that has already been assigned to another billing block.
- If the older billing block should be deleted after creating a new billing block.
Designated Payer Change within the same Billing Family
This refers to changing a channel customer designated payer from one linked account to another in a consolidated billing block. Partner changes the designated payer for a given channel customer to a different account in the same billing family.
On the next bill drop for the billing family, PGB reruns the entire month with the new designated payer account. Duplicate cost cleanup is required for PGB artifacts from the previous designated payer account which will occur automatically.
| AWS PGB Billing Block at Partner Tenant | AWS Accounts at Channel Customer | ||
|---|---|---|---|
| Before | After | Before | After |
| Consolidated Payer 1 at Partner | Consolidated Payer 1 at Partner | Linked account 1 -> Linked | Linked account 1 -> Linked |
| Linked account 1 | Linked account 1 | Linked account 2 -> Linked | Linked account 2 -> Consolidated |
| Linked account 2 | Linked account 2 | Linked account 3 -> Consolidated | Linked account 3 -> Linked |
| Linked account 3 | Linked account 3 | ||
| Designated payer Linked account 3 | Designated payer Linked account 2 | ||
Best Practice
Do not edit the billing block until after the previous month’s bill has been finalised. You can check the bill status, by navigating to Partner > Customers > Statements on Tanzu CloudHealth platform.
Consolidated to Consolidated
This refers to a Partner moving a Customer’s AWS accounts from one payer account to another payer account.
| AWS Accounts at Partner | AWS Accounts at Channel Customer | ||
|---|---|---|---|
| Before | After | Before | After |
| Consolidated Payer 1 at Partner | Consolidated Payer 2 at Partner | Linked account 1 -> Linked | Linked account 1 -> Linked |
| Linked account 1 | Linked account 1 | Linked account 2 -> Linked | Linked account 2 -> Linked |
| Linked account 2 | Linked account 2 | Linked account 3 -> Consolidated | Linked account 3 -> Consolidated |
| Linked account 3 | Linked account 3 | ||
| Designated payer Linked account 3 | Designated payer Linked account 3 | ||
PGB automatically combines the generated artifact from first part of the month (Linked Account 3 from Consolidated Payer 1) with the PGB generated artifact from the second part of the month (Linked Account 3 from Consolidated Payer 2).
Best Practice
Within AWS, migrate the linked accounts between the payer accounts. When the accounts appear in Tanzu CloudHealth partner tenant reconfigure the billing block to point to the new payer account. Update the billing block right after the account movement or at the very latest, before the next month finalizes to avoid discontinuity.
Consolidated to Full Family
This refers to moving a channel customer to their own dedicated payer account. Previously the Customer was configured as consolidated/standalone and now they wish to be configured as Full Account Family. The Partner adds the Customer’s new payer account at the partner tenant and creates a new Full Account Family billing block within AWS PGB.
Note: With Full Account Family all charges and credits, except the reseller credits, will be passed from the partner tenant to the customer tenant.
The partner should not delete the old consolidated billing block right on configuring the new account. The billing block can be deleted after the bill for the transition month is finalized, which is generally around 10th of the following month. If required, contact the support team to apply full family configuration to the previous month.
| AWS PGB Billing Block at Partner Tenant | AWS Accounts at Channel Customer | ||
|---|---|---|---|
| Before | After | Before | After |
| Billing Block 1 | |||
| Consolidated Payer 1 at Partner | Consolidated Payer 1 at Partner | Linked account 1 -> Linked | Linked account 1 -> Linked |
| Linked account 1 | Linked account 1 | Linked account 2 -> Linked | Linked account 2 -> Linked |
| Linked account 2 | Linked account 2 | Linked account 3 -> Consolidated | Linked account 3 -> Linked |
| Linked account 3 | Linked account 3 | Consolidated payer -> Consolidated Payer 1 | |
| Designated payer Linked account 3 | Designated payer Linked account 3 | ||
| Billing Block 2 | |||
| Consolidated Payer 2 at Partner | |||
| Linked account 1 | |||
| Linked account 2 | |||
| Linked account 3 | |||
| Designated payer Consolidated Payer 2 -> full family | |||
The Customer’s AWS accounts are moved from Payer Account 1 (shared payer belonging to the partner) to Payer Account 2 (dedicated payer account for the Customer) mid month and the partner creates a new Full Account Family billing block using the new Payer Account 2. All charges and credits associated with Payer Account 2 will pass through to the Customer tenant. This can result in Unused RI’s from the old Consolidated block since AWS EC2 Reservations collected from the AWS API do not reset the reservation end time while transitioning from one payer account to another. PGB will detect this automatically and will use Reservation information directly from the new Payer CUR rather than from Reservation assets collected from the AWS API.
Best Practice
Historical data is retained
- Keep the old Consolidated billing block and configure a new Full Account Family billing block with the new payer.
- In this case there should be no billing gap in the PGB generated bills or in any Cost or Usage report in the platform. The first part of the month will be covered by the old payer account from the consolidated block and the second part of the month will be covered by the Full Family payer account.
- There should be no cost categorized as Unused Reservation or Savings Plan (unless it is so even at the Partner tenant). If this happens, please contact support.
- Once the bill for the transition month is finalized, the old consolidated block can be removed.
Note:
It is not recommended to have the payer for the new Full Account Family billing block to be the same as the designated payer for the old Consolidated billing block. If this is the case, then please follow the steps below:
- In the transition month, that is the month in which the account moves from Consolidated to Full Family, create a second Consolidated billing block with the payer account and all its linked accounts.
- A consolidated to consolidated bill stitch will happen automatically in the transition month.
- In the following month, when the bills for the transition month are finalized, you can delete the new Consolidated billing block and create the Full Family billing block as intended.
- For the latter part of the transition month, you will not get the Full Family features that you require. For Full Family configuration, typically all costs are charged to the channel customer accounts except for reseller credits and Tax/VAT. AWS support, credits, tiered discounts, and RI usage are all expected to pass directly through. This will not be the case with the Consolidated block, so if needed, Customer Price Books updates would be required.
Historical data is not retained
- Delete the old consolidated billing block.
- Within AWS, delete all AWS accounts at the channel customer tenant.
- Wait for the overnight process to clear out all data in the platform.
- Configure a new billing block as Full Account Family.
- Reconfigure IAM roles at the channel customer tenant as permissions do not pass down for Full Family.
Full Family to Consolidated
Partner decides that the channel customer no longer requires their own designated account and instead can be linked to an existing payer account. This payer account could be used for other channel customers as well.
PGB will no longer pass all charges and credit from the partner payer account to the channel customer account.
| AWS Account Assignment | AWS Accounts at Channel Customer | ||
|---|---|---|---|
| Before | After | Before | After |
| Consolidated Payer 1 at Partner | Consolidated Payer 2 at Partner | Linked account 1 -> Linked | Linked account 1 -> Linked |
| Linked account 1 | Linked account 1 | Linked account 2 -> Linked | Linked account 2 -> Linked |
| Linked account 2 | Linked account 2 | Linked account 3 -> Linked | Linked account 3 -> Consolidated |
| Linked account 3 | Linked account 3 | Consolidated payer -> Consolidated payer 1 | |
| Designated payer Consolidated payer 1 -> full family | Designated payer Linked account 3 | ||
Best Practice
Historical Data is retained
- Keep the old Full Account Family billing block and configure a new Consolidated billing block with the new payer.
- In this case there should be no billing gap in the PGB generated bills or in any Cost or Usage report in the platform. The first part of the month will be covered by the old payer account from the Full Account Family billing block and the second part of the month will be covered by the Consolidated billing account.
- There should be no cost categorized as Unused Reservation or Savings Plan (unless it is so even at the Partner tenant). If this happens, please contact support.
- Once the bill for the transition month is finalized, the old Full Account Family billing block can be removed.
Note:
It is not recommended to have the payer for the new Consolidated billing block to be the same as the designated payer for the old Full Account Family billing block. If this is the case, then please follow the steps below:
- In the transition month, that is the month in which the account moves from Full Family to Consolidated, create a second Full Family billing block with the payer account and all its linked accounts.
- A Full Account Family to Full Account Family bill stitch will happen automatically in the transition month.
- In the following month, when the bills for the transition month are finalized, you can delete the new Full Family billing block and create the Consolidated billing block as intended.
- For the latter part of the transition month, you will not get the Consolidated features that you require. For Consolidated configuration, typically all costs are charged to the channel customer accounts except for reseller credits and Tax/VAT. AWS support, credits, tiered discounts, and RI usage are all expected to pass directly through. This will not be the case with the Full Family block, so if needed, Customer Price Books updates would be required.
Historical Data is not retained
- Delete the old Full Family billing block.
- Within AWS, delete all AWS accounts at the channel customer tenant.
- Wait for the overnight process to clear out all data in the platform.
- Configure a new billing block as Consolidated.
- Reconfigure IAM roles at the channel customer tenant as permissions do not pass down for Consolidated.
Direct to Managed
An existing Tanzu CloudHealth customer becomes a managed channel customer of a partner. During the transition month, all AWS CURs will be collected directly in their tenant. Raise a Customer Support ticket to run a Direct to Managed bill stitch so that the costs are consistent in the channel customer tenant.
Note: The S3 bucket can be left configured at the customer tenant to retain historical data.
Considerations
- Channel Customer must submit a request to Tanzu CloudHealth through a support ticket to move under a Partner.
- All relevant contracts must to be reviewed and the next steps should be determined based on the business requirements of all stakeholders.
- Partner must link the channel customer’s AWS accounts under the Partner’s master payer, if required.
Best Practice
- Remove the Cost and Usage Report settings at the Setup > Accounts > AWS > Edit page in the channel customer tenant to prevent Tanzu CloudHealth from collecting bills in both locations.
- Configure customer accounts in the Partner tenant.
- Wait 24 hours to ensure that Tanzu CloudHealth pulls in the cost and usage information at the partner tenant.
- Add the accounts into one or more PGB Billing Blocks at the Partner > Customers > List > Edit page.
- Wait 24 hours to ensure that Tanzu CloudHealth pulls cost and usage information at the channel customer tenant.
- On noticing a billing gap, raise a support ticket for a Direct to Managed bill stitch.
Managed to Direct
Best Practice
Option 1 - Partner retains data
- Check if the customer opted for Partner Generated Billing. If yes, then the customer’s cost and usage data should be saved in Partner’s S3 bucket. If no, then ensure that the customer’s accounts are created at the Partner level and that the Partner can save customer information in a separate S3 bucket.
- Once Partner has access to customer’s cost and usage data, determine how it should be reflected - Either in their own partner tenant or in an isolated customer tenant. In either case, the customer should retain their tenant. New tenant from there on will be associated with the partner and the customer will retain all historical cost and usage data as well as the tenant’s current configuration. One exception to this is where a Partner considers the customer tenant a part of their managed services and does not want to allow the customers to retain perspectives, policies, etc. as they move away from the partner.
- The tenant is moved away from the partner and if required, a shell tenant is created for the partner to assign the historical cost and usage associated with their churning customer. Ensure that all IAM associations to the churning customer’s accounts are ended.
Note: Partner must validate the timing from an invoicing perspective and also verify if the customer is bound to any Terms & Conditions.
Option 2 - Partner does not retain data
- Channel Customer must submit a request to Tanzu CloudHealth through a support ticket to de-link from a Partner.
- After migration, the customer must check if their AWS accounts are configured correctly. If the customer is migrating away from the Partner’s payer account, then they might need to add in a new payer account (and CUR).
- Check for IAM roles and ensure that the external ID associated to an IAM role is not the one for the Partner tenant. Change this to reflect the external ID of the the formerly Channel Customer.
