Skip to main content
← All posts
5 min read

Cloud Cost Attribution Without a FinOps Team

Your AWS bill is $X. You have no idea which features cost what. Here's the minimum-viable cost attribution that any small team can run.

Share

Your CFO asks: "We spent $43k on AWS last month. Which products drove that? Which customers?"

You don't know. Your bill is a heap of EC2, RDS, S3, Lambda, and CloudWatch line items. There's no obvious mapping back to features or revenue.

Big companies hire FinOps teams to solve this. You can't. Here's the minimum-viable version that gets you 80% of the answer.

What "attribution" actually means

You want to answer questions like:

  • How much does the email feature cost?
  • What's the unit cost per active user?
  • Are paid customers profitable after infra cost?
  • Which environment (prod, staging, dev) is eating the bill?

To answer these, you need to label resources by what they're for. AWS doesn't do this for you. You have to.

The minimum: tag everything

The single most useful action: enforce tags on every resource.

Required tags:

  • Environmentprod, staging, dev
  • Serviceapi, worker, cron, email, analytics
  • Owner — team or engineer responsible
  • CostCenter — for chargeback (if you have multiple business units)

How to enforce:

  1. AWS Service Catalog / IaC review — every Terraform module requires these tags or won't apply
  2. Tag policies — AWS Organizations can enforce specific tag values
  3. CI lint — fail PRs that add untagged resources
  4. Untagged-resource report — weekly Slack post listing untagged things

In practice, level 3 (CI lint) catches 90% of cases. Level 4 (the report) catches drift.

Cost Explorer: the underused tool

Once tagged, AWS Cost Explorer becomes useful. Group by tag:

Group by: Tag → Service
Filter: Environment = prod
Date range: Last 30 days

Now you see:

  • API: $12k
  • Worker: $8k
  • Email: $4k
  • Analytics: $19k

Right there: analytics costs more than the rest combined. Worth investigating.

Group by tag → Owner to assign that work to the right team.

Cost per customer: the harder ask

For multi-tenant services, you want cost per customer. AWS doesn't tell you this directly. You have to derive it.

Patterns that work:

1. Allocation by usage proxy. If your DB cost is $5k and customer A drives 10% of queries, attribute $500 to customer A. Use CloudWatch metrics + custom dimensions to track per-tenant usage.

2. Per-tenant resources. If feasible, dedicated infrastructure per customer makes attribution trivial. Expensive at small scale.

3. CUR + Athena. AWS's Cost and Usage Reports go to S3. Query with Athena. JOIN against your usage data.

For a startup, option 1 is usually right. Build a daily job that:

  1. Pulls AWS bill by service
  2. Pulls per-customer usage from your DB
  3. Multiplies to get per-customer cost
  4. Stores in a dashboard

This isn't precise. It's good enough to spot the customer paying $50/mo who's costing you $200/mo in compute.

The weekly cost review

A useful artifact: a weekly cost review.

Format:

  • Total spend vs. last week (delta)
  • Top 5 movers (services with biggest WoW change)
  • New resources created (>$100/mo each)
  • Untagged spend (the unattributable portion)
  • Top customer cost ratio

Slack post or email. 10 minutes to write, makes cost visible to the team.

When cost is invisible, engineers spin up resources without thinking. When it's reviewed weekly, "should we use this $300/month service?" becomes a conversation.

Quick wins worth running

These almost always save money on the first pass:

1. Right-size EC2. Most teams over-provision. Use AWS Compute Optimizer or simply check CloudWatch CPU graphs — instances at <20% utilization get downsized.

2. Reserved Instances / Savings Plans. If you're at $5k+/month on EC2, RIs save 30-50% with no downside. Match your committed baseline; pay on-demand for the rest.

3. Delete unattached EBS volumes. Old volumes from terminated instances rack up charges nobody notices.

4. S3 lifecycle policies. Move logs older than 30 days to Glacier, delete after 365. Saves 90% on storage.

5. CloudWatch Logs retention. Default is "never delete." Set to 30 days unless legal requires longer.

6. NAT Gateway data costs. If you have a NAT gateway and lots of cross-AZ traffic, examine. VPC endpoints for S3/DynamoDB save data transfer charges.

7. Stale dev environments. Auto-stop dev RDS instances and dev EC2 nightly. Restart in the morning. Saves ~70% on dev infra.

Each of these is 1-2 hours of work. Together they typically cut a startup's bill 20-30%.

The dev environment scandal

Most teams' dev/staging spend is bigger than they think. A typical pattern:

  • 5 developer-named environments running 24/7
  • Each with RDS, ECS tasks, ALB, etc.
  • Engineer leaves; environment forgotten
  • Costing $400/month, used 0 hours/week

Audit dev resources monthly. Auto-tag with creator. Auto-shutdown if no activity in 7 days.

You'll find ~$2-5k/month of pure waste at most companies, just from forgotten resources.

When to actually hire FinOps

Signals it's time:

  • Bill > $200k/month and growing
  • Cost per customer is a board-level metric
  • Multiple teams running independently with overlapping infra
  • Reserved instance / Savings Plan management is a part-time job nobody owns

Until then, a part-time engineer can run the playbook above with maybe 4 hours/month.

The tooling layer

Tools that genuinely help:

  • Cloudability / Apptio — managed FinOps, $$
  • Vantage — modern, cheaper, good for startups
  • CloudHealth — older, enterprise
  • Open-source: KubeCost, Komiser — for Kubernetes-heavy stacks

For most startups: AWS Cost Explorer + a weekly review + tags is enough. Tools come when scale demands.

The takeaway

Cost attribution doesn't require a FinOps team. It requires tags, a weekly review, and a few quick wins on the obvious waste. Spend a day setting it up. Save 20-30% of your cloud bill the first month. Repeat quarterly. The savings compound and your CFO gets answers.

Work with me

I consult with engineering teams on AI adoption, cloud architecture, and engineering effectiveness. If this post surfaced a challenge you're facing, let's talk.

Get in touch →

Explore more on these topics:

Subscribe to new posts

Get an email when I publish something new. No spam, unsubscribe any time.