From the cloud bill to cost per order: cost-centre allocation and unit cost across AWS, Azure and Google Cloud

"We spent 20% more on cloud this month." Put like that, nobody knows whether it is bad news. If orders grew 40%, it is an improvement. If they did not grow, it is a problem. Either way a second question is missing: which team or product took that money? The cloud bill answers neither. This article shows how AAA Sentinel answers both, with a full example across AWS, Azure and Google Cloud.

The two questions the bill does not answer

A cloud bill is organised by service: so much compute, so much storage, so much database. It is good for paying, not for deciding. Deciding takes two things the bill does not contain:

• Who each dollar belongs to: which cost centre, team or product spent it. Without this there are no owners, only a shared figure nobody feels is theirs.
• What you got for that spend: what each order, customer or transaction costs in cloud. Without this you cannot tell growth from waste.

What you gain

With allocation and unit cost in place, the conversation about cloud changes:

• Each team sees its share of the bill and answers for it, instead of arguing over a total.
• You know whether spend is growing faster than the business: if cost per order goes up, something has become less efficient even if the bill looks reasonable.
• You can price with data: you know what it costs to serve a customer before deciding what to charge.
• You see how much spend has no owner, which is usually where savings start.
• You have it for all your clouds in one place, with the same allocation rules.

How AAA Sentinel solves it: three pieces

The feature is part of the Business plan and rests on three pieces you set up once:

• FOCUS ingestion: each cloud exports its detailed bill in FOCUS, the open format shared by AWS, Azure and Google Cloud. AAA Sentinel reads it every day and processes the last closed month. You set it up per account, under My cloud accounts → FOCUS ingestion, and the page itself includes a step-by-step guide for each cloud.
• Cost allocation by tag: you choose the keys you want the bill broken down by (for example, cost_centre) and add rules to cover whatever is not tagged. It lives under Organization Settings → Costs.
• Business metrics: you declare your unit (orders, active customers, transactions) and provide how many there were each month, by hand or through the API. The platform divides cost by those units.

Real tags and virtual rules

Ideally every resource carries its tag in the cloud, but in practice some part is always untagged. Instead of making you tag everything before you see a result, AAA Sentinel lets you fill the gap with virtual tagging rules: "if the service is S3, assign it to data", "if the resource name starts with payments-, assign it to payments". Rules change nothing in your cloud and follow three simple principles:

• A real tag always beats a rule. A rule never overrides what your team tagged on purpose.
• If two rules assign the same key, the first one in the list wins.
• Whatever has neither a tag nor a rule stays "unallocated". It is never spread by guesswork: seeing how much has no owner tells you where to tag or which rule to create.

Worked example: ACME on three clouds

ACME sells online. Its shop runs on AWS, its data platform on Azure and its analytics on Google Cloud. It wants to know what each order costs and how much each cost centre spends: shop, payments and data. In September it had 9,900 orders. This is its bill for the month:

Step 1: connect the detailed bill of each cloud

Each cloud has its own way of exporting FOCUS and its own conditions. This is what to do in each one, and what is worth knowing before you start:

• AWS: activate the tag under Billing → Cost allocation tags (unless it is activated AWS leaves it out of the export, and it can take up to 24 hours to appear) and create a FOCUS 1.0 export in CSV under Data Exports. The export only writes from the day you create it, so the first full month arrives when the current month closes.
• Azure: in Cost Management, create an export of type "Cost and usage details (FOCUS)" and give the connection the Storage Blob Data Reader role on the storage account. Tags arrive on their own, and with tag inheritance it is enough to tag the resource group. Azure lets you export past months, so you can have results on day one. It is only available for EA, MCA or partner agreements.
• Google Cloud: enable the FOCUS export to BigQuery and give the connection service account read access to the dataset. With a multi-region dataset, Google backfills from the start of the previous month.

Step 2: define the allocation once

Allocation is set at organisation level and applies to every account at once. ACME uses a single key, cost_centre, with the same values on all its clouds, and three rules for what is not tagged:

• Use the same key and the same values on every cloud. If you write "Data" on one and "data-eu" on another, the report treats them as different cost centres.
• Rules apply to every account, but service names differ between providers: a rule on an AWS service does not affect Azure. To allocate Azure without tagging, a rule on the sub-account (the subscription) is the most practical.

Step 3: what ends up in each cost centre

When September is processed, AAA Sentinel applies real tags first and rules second. This is the result in the AWS account, resource by resource:

• AWS: shop 450 USD, payments 300 USD, data 210 USD and 30 USD unallocated. Without the rules, coverage would have been 82%; with them, 97%.
• Azure: data 350 EUR and 50 EUR unallocated.
• Google Cloud: 95 EUR that count in the total, but not in the breakdown.

Step 4: declare the metric and provide the units

Under Organization Settings → Costs → Business metrics, ACME creates the metric "Orders", with the unit "order" and the allocation key cost_centre. Then it provides the units for the month. There are two ways:

• By hand, once a month, from Reports → Unit cost: the total (9,900 orders) and, if you want the breakdown, the units of each cost centre. Sending a value again corrects it; it does not add to it.
• Automatically, every night, from your order system, with an OAuth2 application that has the metrics:write permission. If you send daily values, send them every day: days with no units are left out of the calculation and the platform tells you.

Step 5: read the report

With cost allocated and units declared, Reports → Unit cost shows this for September:

• One card per currency, and they are never converted. Each cloud bills in its own currency and mixing them would mean inventing an exchange rate; the real cost of an order is the sum of the cards.
• Breakdown by cost centre, also per currency: in USD you see shop, payments and data from AWS; in EUR, data from Azure. The breakdown does not add up to the total, because what stayed unallocated is not in it.
• Trend over recent months, which is where the value is: a single figure says little, the trend says whether each order costs you more or less than before.
• Accounts outside the calculation: if an account is missing its ingestion for the month, the report shows it with its name, the reason and how to fix it. A cost that goes missing silently would lower the ratio and look like an improvement.

Get alerted when unit cost rises

Once the loop is running, you do not need to open the report every month. Under Alerts → Alert channels you can turn on "Unit cost increase" and set a percentage: the platform compares each month with the previous one and only alerts on rises. It is the alert that catches something becoming less efficient while the total bill still looks normal.

What we learned setting it up

We set all of this up on our own accounts before writing the article. This is what is worth knowing before you start:

• Allocation works on closed months. Work out when you will have your first result: on AWS, when the month in which you create the export closes; on Azure and Google Cloud you can have it sooner, because they export past months.
• Changing keys or rules does not recalculate a month that was already processed. After changing them, click "Run now" on the FOCUS ingestion page of each account.
• Check the reconciliation: the ingestion page compares the imported cost with the cloud bill. If it does not match, the usual cause is a path pointing to more than one export.
• Start with rules and tag afterwards. Two or three well-chosen rules give you a useful first allocation in minutes, and "unallocated" tells you what is worth tagging.
• Decide the values before tagging. Few, lowercase and always written the same way.

Checklist to get started

With this in order, the next time someone asks what the cloud costs you can answer with what they really want to know: what each order costs and who spends it.

• Business plan and access as the organisation owner.
• Your cloud accounts connected and FOCUS ingestion set up on each one.
• An allocation key with agreed values, the same on every cloud.
• Rules for what is not tagged, and "unallocated" reviewed.
• A business metric with its units for the month, by hand or through the API.
• The unit cost increase alert turned on.