What is FinOps, and What It Actually Reports

FinOps is the practice of making cloud spending understandable and actionable - not just visible. The FinOps Foundation defines it as an operational framework and cultural practice that maximises the business value of cloud, enables timely data-driven decisions, and creates financial accountability through collaboration between engineering, finance and business teams.

That definition is accurate and slightly abstract. In my work on AWS cost optimization, FinOps comes down to something concrete: a recurring report that tells the people who can change the bill what changed, why it changed, and what to do about it. This page shows what that report contains, how I build it on AWS, and the difference between reporting costs and actually managing them.

Short answer: a useful FinOps report answers three questions every week - What changed? Why did it change? What should we do about it? Everything else - dashboards, tags, tooling - exists to answer those three questions faster.

Reporting costs is not managing them

This is the distinction most FinOps efforts miss. A report that says "EC2 spending increased by 18%" is accurate and nearly useless: nobody knows whether that is good, bad or expected, and nobody owns doing anything about it.

A report that is worth reading turns the same number into a decision:

Same data. The second version identifies the affected workload, explains the likely cause, estimates the financial impact and proposes a specific remediation with an owner. That gives the engineering team something to act on - which is the whole point.

What a weekly FinOps report should contain

This is the structure I use. Six sections, in this order, because each one narrows down what the next should look at.

1. Spend overview

Total AWS spend for the week, month-to-date spend, and the forecast for the end of the month against budget. One line answers the first question anyone asks: are we on track?

2. Biggest cost changes

The services and resources with the largest week-over-week increases and decreases, with an explanation wherever the data allows one. Decreases matter too - they confirm an optimisation landed, or reveal that something stopped running that shouldn't have.

3. Cost breakdown

Spend by environment, by service, and by team or product, using AWS cost allocation tags where they exist. The share of spend that can't be attributed is itself a number worth reporting: untagged spend is where waste hides, because nobody owns it.

4. Optimisation opportunities

Concrete recommendations, not categories. "Review compute" is a category. "The staging RDS instance runs at under 10% CPU around the clock; downsize one class" is a recommendation. Typical items: oversized workloads, unattached EBS volumes and old snapshots, NAT Gateway traffic that could go through VPC endpoints, and Savings Plans for workloads whose usage has stabilised.

5. Anomalies

Unexpected spikes, newly expensive resources, and likely misconfigurations - a log group that started ingesting ten times its usual volume, an instance type nobody recognises, cross-AZ traffic that appeared after a deployment. AWS Cost Anomaly Detection catches many of these between reports; the weekly report records what was found and what was done.

6. Action tracker

Every recommendation from previous weeks, with estimated monthly savings, implementation effort, owner and status. This section is what turns a report into a practice. Without it, the same recommendations reappear every week and nothing changes.

What it looks like on one page

An illustrative example of the layout - the numbers are made up, the structure is the one I use:

WEEK 42 - AWS COST REPORT
Spend this week ......... $9,840     (last week $9,120, +7.9%)
Month to date ........... $27,300
Forecast end of month ... $41,800    (budget $40,000 - 4.5% over)

BIGGEST CHANGES
+ $610  EC2 / reporting-workers (prod)   batch frequency doubled in release 3.14
+ $140  CloudWatch Logs / payments-api   debug logging left on after incident
- $220  RDS / staging                    downsized last week, as planned

UNALLOCATED SPEND: 6% of total (target under 5%)

ACTIONS                                  EST. $/MO  EFFORT  OWNER     STATUS
Move reporting batch to Spot             ~1,800     Medium  Data      In progress
Set log level back to INFO               ~600       Low     Payments  Open
S3 gateway endpoint for private subnets  ~450       Low     Platform  Done

A page like this takes two minutes to read, and every line on it either confirms something is fine or names who is doing what about it.

How I build it on AWS

The data sources are the same at every size; what changes is how much tooling sits on top.

• AWS Cost Explorer for the quick views: spend by service, account and tag, and the month-end forecast.
• Cost and Usage Reports (CUR) for anything Cost Explorer can't answer - resource-level detail, custom groupings, unit costs. Export to S3 and query with Athena.
• AWS Budgets and Cost Anomaly Detection for alerts between reports.
• Grafana or a BI tool on top of CUR when the client needs dashboards that more than one team will look at.
• AWS-native tooling or a dedicated FinOps platform for larger, multi-account or multi-cloud environments, where the setup effort pays for itself.

The "biggest changes" section, for example, is one Athena query against CUR 2.0:

SELECT service, this_week, last_week, this_week - last_week AS change
FROM (
  SELECT
    line_item_product_code AS service,
    SUM(CASE WHEN date(line_item_usage_start_date) >= current_date - INTERVAL '7' DAY
             THEN line_item_unblended_cost ELSE 0 END) AS this_week,
    SUM(CASE WHEN date(line_item_usage_start_date) <  current_date - INTERVAL '7' DAY
             THEN line_item_unblended_cost ELSE 0 END) AS last_week
  FROM cur
  WHERE date(line_item_usage_start_date) >= current_date - INTERVAL '14' DAY
  GROUP BY line_item_product_code
)
ORDER BY abs(this_week - last_week) DESC
LIMIT 10;

Two caveats when you build this. Billing data settles over a day or two, so compare complete days and leave the most recent ones out. And if you hold Savings Plans or Reserved Instances, use amortized cost to judge efficiency - unblended cost makes the month you bought a commitment look terrible and the following months artificially cheap. The AWS cost optimization guide covers both in more detail.

The metrics that matter

Total spend is a poor headline number for a growing company, because it should grow. The metrics I track instead:

• Unit cost - cost per customer, per tenant or per transaction. It tells you whether infrastructure scales slower than the business, which is the question finance and investors actually ask. See AWS cost optimization for SaaS.
• Allocation coverage - the share of spend attributed to a team, product or environment. Below roughly 90%, cost conversations turn into arguments about whose cost it is.
• Commitment coverage and utilisation - how much steady usage is covered by Savings Plans, and how much of the commitment is actually used.
• Forecast accuracy - the gap between forecast and actual. A shrinking gap means the team understands its own spend.
• Action throughput - recommendations closed per month and the savings they realised. It measures whether the practice changes anything.

How FinOps matures

The FinOps Foundation describes maturity as Crawl, Walk, Run. In practice on AWS:

• Crawl: Cost Explorer, a budget alert, partial tagging. Spikes are found when the invoice arrives. The weekly report above is the step that moves you out of this stage.
• Walk: most spend tagged and allocated, anomaly detection on, a weekly report with an action tracker, commitments bought deliberately.
• Run: unit costs tracked per product, cost visible in design and deployment decisions, and teams acting on their own numbers without being chased.

You don't need to reach Run everywhere. For most startups, a reliable Walk - clean allocation, a weekly report people read, and an action tracker that moves - is where the return is.

When a company actually needs FinOps

Earlier than most think, but lighter than most vendors suggest. Once AWS spend is material against revenue, or more than one team deploys to production, a weekly report pays for itself. Before a fundraise it becomes urgent, because investors ask exactly these questions - see AWS cost optimization before fundraising.

If your bill is a few thousand dollars a month and one team owns everything, a budget alert and a monthly look at Cost Explorer is enough. Do the zero-risk cleanup and revisit when spend or team count grows.

FAQ

What does FinOps stand for?

Financial operations - specifically for cloud and technology spend. It brings engineering, finance and the business together so spending decisions are made with cost data, not discovered afterwards on the invoice.

What should a FinOps report include?

A spend overview with forecast against budget, the biggest week-over-week changes with explanations, a breakdown by environment, service and team, concrete optimisation opportunities, anomalies, and an action tracker with savings, effort, owner and status.

Is FinOps just cost cutting?

No. The goal is spending well, not spending least. Sometimes the right decision is to spend more - for redundancy, or capacity for growth - as long as it is a deliberate decision with the cost known in advance.

Do we need a FinOps platform?

Not to start. Cost Explorer, CUR with Athena, Budgets and Cost Anomaly Detection cover most single-cloud AWS environments. A dedicated platform starts paying off with many accounts, multiple clouds, or many teams that need self-service views.

Who should own FinOps?

Engineering owns the usage, finance owns the budget, and someone has to own the report and the action tracker. In a startup that is usually a platform or DevOps lead with a finance counterpart; in larger organisations, a small central FinOps function that enables teams rather than doing the work for them.

Want this set up for your AWS account?

I build the reporting, tagging and action tracker as part of AWS cost optimization consulting. For many teams, the first report is the first time anyone has looked at the biggest changes, their causes and their owners on one page.