Cloud Cost Management on AWS: Who Owns Which Number?

Cloud cost management is sold as a dashboard problem and it is not. Every account we open has Cost Explorer switched on, a budget somebody made in the first month, and a tagging policy in a Notion page. The bill still arrives with a third of it in a bucket nobody can attribute, and the spike still gets noticed on the 4th, when finance reconciles.

The gap is not tooling. It is that the three mechanisms AWS gives you — tags, budgets, anomaly detection — each answer a day late, and one of them does not look at a large part of what a fintech actually buys.

So the position: decide who owns which number before you decide which dashboard shows it, and build the split into the account structure rather than retrofitting it with tags.

Why does cloud cost management break at the second product?

With one product, the account is the answer. Everything in it belongs to the same team, so the bill needs no allocation at all.

The second product breaks that. Now there is shared infrastructure — a NAT gateway, a cluster, a bastion, an observability stack — and two teams who both think the other one is the expensive tenant. The instinct is to reach for tags. That instinct is right and it is also six months late, for a reason nobody reads until they need it.

What will tags never tell you?

Anything about the past. AWS's documentation is blunt: "Tags are not applied to resources that were created before the tags were created." There is no backfill. The EC2 instance somebody launched in March, the RDS cluster from the migration, the S3 bucket holding your CERT-In log copy — none of them acquire a Product tag because you wrote a tagging standard in September.

Then there is the wait. After you apply a tag, "it can take up to 24 hours for the tag keys to appear on your cost allocation tags page for activation. It can then take up to 24 hours for tag keys to activate." Two days from "we agreed on a tagging standard" to "the tag exists in cost data", and the cost data only starts from then.

This is why the untagged bucket never shrinks on its own. Tagging new resources fixes next quarter. The existing fleet has to be tagged deliberately, resource by resource, and the older the account the more of the bill sits outside the scheme. Start by measuring how much:

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=TAG,Key=Product \
  --query 'ResultsByTime[0].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]' --output table

The row with an empty key is your unallocated spend. If it is over a fifth of the bill, allocation is the work, not optimisation. Cutting is a different job, and we wrote about what a fintech can cut without failing an audit separately.

When do you actually hear about a spike?

Later than the spike. Both alerting mechanisms run on billing data, and billing data lags.

AWS Budgets, per its documentation, "information is updated up to three times a day. Updates typically occur 8–12 hours after the previous update", and the same page warns that "you might incur additional costs or usage that exceed your budget notification threshold before AWS Budgets can notify you".

Cost Anomaly Detection is in the same boat and says so: it "runs approximately three times a day", uses Cost Explorer data "which has a delay of up to 24 hours", so "it can take up to 24 hours to detect an anomaly after a usage occurs". A new monitor takes 24 hours to start working, and a service you have just started using needs "10 days of historical service usage data" before anomalies can be detected for it at all.

Read that last clause twice if you are about to launch something. The week you most want an anomaly alert — a new service, a new region, a load test that did not stop — is exactly the week the detector has nothing to compare against. Cost alerting is a second line of defence. The first is a quota or a budget action that refuses to let the thing scale past a number you chose.

What sits outside the monitor entirely?

Your SaaS bill, if you buy it through AWS Marketplace. Anomaly Detection "does not monitor third-party products and services available through AWS Marketplace", with an exception for third-party models on Bedrock. AWS's own advice is to cover it with a cost budget using the billing entity filter.

For a fintech this is not a corner case. Observability, a WAF, a KYC vendor, a data provider — Marketplace is the convenient way to buy all of them on one invoice, and it is the part of the invoice that grows without anyone watching. An observability bill in particular moves with traffic and with the number of hosts, which is the whole subject of our post on cutting a Datadog bill on AWS. If it is bought through Marketplace, no anomaly monitor will tell you it doubled.

Accounts or tags — which one carries the split?

Accounts, wherever the boundary is permanent. Tags, for everything inside one.

An account boundary needs no discipline to hold. Nobody forgets to put a resource in the right account, because they had to authenticate into it. A tag holds only as long as every Terraform module, every console click and every contractor remembers it, and the one that gets forgotten is the expensive one. The same argument decides who can reach what, which is why how a provider gets into your account and how you split the bill end up being the same conversation.

The line we use: a separate account when the thing has its own blast radius, its own compliance scope or its own owner — production versus non-production, the cardholder-data environment versus everything else, one per product where products have separate P&Ls. Tags for the layers inside that: environment, component, cost centre, ticket.

This costs nothing extra. Consolidated billing rolls the accounts into one invoice and the volume discounts still aggregate. What it buys is a number per account that is correct without anybody maintaining it, and, when an auditor asks which account holds the in-scope workload, an answer that is a fact rather than a query — which is the same reason PCI DSS scoping starts with the account layout.

What can you set up on Monday?

Four things, in order, about an hour:

1. Run the query above and write down the unallocated percentage. That is your baseline and the number you report on in a month.
2. Activate the tag keys you have actually agreed on, in bulk, and accept that the data starts today:

   aws ce update-cost-allocation-tags-status \
     --cost-allocation-tags-status TagKey=Product,Status=Active \
                                   TagKey=Environment,Status=Active

3. Create one cost budget per account with the billing entity filter set to AWS Marketplace, because nothing else is watching it.
4. Put a budget action — not just an alert — on the non-production accounts. An alert asks somebody to wake up. An action denies the next launch.

What we would not do on Monday: buy a cost management tool. Every third-party platform reads the same Cost and Usage Report with the same lag, and an allocation problem it inherits is an allocation problem it reports more prettily. Fix the account layout and the tag coverage first; then a tool has something true to work with. The deeper reason the bill resists all of this is the one we wrote about in what lock-in costs a fintech: you cannot negotiate a number you cannot move.

The short version

Measure the unallocated share of the bill this week; if it is above a fifth, that is the problem, not instance sizing. Tag new resources from today and tag the old fleet deliberately, because nothing backfills. Expect to hear about a spike up to a day late, and put a quota or a budget action in front of anything that can scale while you sleep. Cover Marketplace with its own budget, since the anomaly detector will not. And where a split needs to survive a year of staff turnover, make it an account, not a tag.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.