AWS: L2 CUR Functionality

As AWS continues its push forward to replace the Detailed Billing Report (DBR) with the Cost and Usage Report (CUR), we have retooled our CloudCheckr platform—enabling our customers to use the CUR as a primary billing method and access CUR-only features.

Initially, only our L1 customers, or partners, could take advantage of this functionality. With our latest release, however, we have extended the CUR benefits to our L2 customers, or child partners.


FAQs

Read our Frequently Asked Questions (FAQs) to learn more about how L2 customers can use the CUR in their CloudCheckr environment.

If you are an L2 customer, you can:

  • access CUR-only features—like Savings Plan Cost Allocation and RI Consuming Account Based Allocation—even if you are using the DBR as long as you are linked to an L1 that uses the CUR
  • host Proof of Concept (POC) prospects who can ingest their own CUR data, and later link to a reseller to support historic CUR month reloading

You can access L2 CUR if you are:

  • an L1 already using the CUR
  • an L2 already using the CUR
  • an L2 using the DBR but you are linked to an L1 on the CUR, which allows them to pass onto you the information required to enable the CUR functionality

You cannot access L2 CUR if you are:

  • an L1 using the DBR
  • any L2 attached to an L1 only using the DBR
  • an L2 of an L1 using the CUR but there is no reseller link

Accounts with access to the CUR use Redshift, the AWS service that powers our CUR billing engine. In addition, our CUR-only features, Savings Plans and RI Consuming Account Based Allocation, will also be visible in the CUR accounts.

To verify if you are in an account where the CUR is enabled:

  1. Log in to CloudCheckr as a SysAdmin.
  2. Select a partner that is mapped to a CUR payer account.
  3. From the account list, click the CUR payer account.
  4. From the left navigation pane, choose Cost > AWS Partner Tools > Configure > Configure Custom Cost.

    You will see the RI Consuming Account Based Allocation and Savings Plans Deallocation features if the CUR is enabled:

  5. From the left navigation pane, choose Admin > System Info and scroll down to the Billing Type Write entry.

    If the type is Redshift, you are in a CUR-enabled account:

Yes. You can now see the Reseller start date on the Reseller Settings page. Previously, you couldn't access the Start Date information after CloudCheckr sent the Reseller link.

To show you how this works, let's set up a new reseller and then confirm that the Start Date is visible in the Reseller Settings page.

  1. Launch CloudCheckr.
  2. Select the partner where the L1 master-payer with the Redshift/CUR access is located.
  3. From the menu bar, click the Settings icon and choose Partner/Account > Resellers.
  4. On the Resellers Settings page, click + New Reseller Link.
  5. In the New Reseller Link dialog box:
    1. provide the IDs associated with your Master-Payer Account and your reseller
    2. select the Reset history starting on radio button and click the calendar to select a date
    3. Click Link Accounts.

      CloudCheckr will update your billing data to reflect the addition of the new reseller.

      The time it takes for CloudCheckr to update the Reseller Settings depends on the amount of billing data.
  6. Return to the Resellers Settings page.
  7. Select the reseller associated with the L1 that has Redshift/CUR access.
  8. In the Account Family column, click the Family Details icon.

    The dialog box displays the Reseller Start Date, which you selected when you configured the new reseller.

CloudCheckr will display a project notification any time you attempt to turn on CUR-Only features and then reprocess a month that does not have the required CUR columns:

When you click the Custom Cost Configuration Issue link, you will get more details about why the billing reprocessing failed:

To get even more context:

  1. From the left navigation pane, choose Cost > AWS Partner Tools > Files > Reprocess Billing Report.

    Notice that December 2018, which was the month identified in the project notification, was processed using the DBR, so it does not have the required CUR setup:


Use Cases

For examples of conditions that will trigger a project notification, review these use cases:

Conditions:
  • Billing files from January 2020 to May 2020
  • L1 is using the CUR
  • L2 is using the DBR
  • A reseller link started in March 2020
  • The L2 CUR functionality was rolled out in April, so the L1 reprocesses April to ensure the CUR columns are included.
Scenario:

If the L2 turns on the L2 CUR-only Custom Cost features and attempts to reprocess all the months, the following will occur:

  • CloudCheckr will send a notification for January and February 2020 since those months are using the DBR files
  • CloudCheckr will send a notification for March 2020 because it created the billing file prior to the addition of the L2 CUR rollout
    To fix this error for March 2020, the L1 can reprocess March so that the billing file contains the necessary CUR columns. Once the L1 has completed the reprocessing, the L2 can reprocess March since the billing file passed down from the L1 now contains the CUR columns.
  • CloudCheckr won't send a notification for April or May since the L1 wrote the CUR columns to the reseller file
Conditions:
  • Billing files from January 2020 to May 2020
  • L1 is using the CUR
  • L2 is using the CUR
  • A reseller link started in March 2020
  • The L2 CUR functionality was rolled out in April, but the L1 does not reprocess March 2020
Scenario:

If the L2 turns on the L2 CUR-only Custom Cost features and atttempts to reprocess March 2020, the following will occur:

  • CloudCheckr will send a notification for March 2020 because it created the billing file prior to the addition of the L2 CUR rollout
    To fix this error for March 2020, the L1 can reprocess March so that the billing file contains the necessary CUR columns. Once the L1 has completed the reprocessing, the L2 can reprocess March since the billing file passed down from the L1 now contains the CUR columns.
  • CloudCheckr won't send a notification for January and February 2020 since both the L1 and L2 used the CUR files during those months
  • CloudCheckr won't send a notification for April or May 2020 since the L1 wrote the CUR columns to the reseller file
Conditions:
  • Billing files from January 2020 to May 2020
  • L1 has migrated to the Redshift/CUR platform in March 2020, but it has historic DBR billing months for January and February 2020
  • The L2 CUR functionality was rolled out in April
Scenario:

If the L2 turns on the L2 CUR-only Custom Cost features and atttempts to reprocess all the months, the following will occur:

  • CloudCheckr will send a notification for January and February 2020 because it created those billing files used the DBR
  • CloudCheckr won't send a notification for March, April, and Mary 2020 since both the L1 and L2 used the CUR files during those months

How did we do?