Only get the AWS cost data you need
The first FinOps Toolkit tool, cost_and_usage.py, was built for simplicity: one command, one CSV, two columns — date and number. It pulls AWS cost data with minimal permissions and zero dashboards, proving that FinOps …
Connections
The context
The starting point for the FinOps Toolkit had to be something simple.
I wanted a tool that could prove a point: that FinOps can be hands-on, lightweight, and human-readable.
The context for cost_and_usage.py was precisely that — I needed a way to get AWS cost data out of the cloud without friction.
No need to learn the Cost Explorer API.
No need to navigate the console and download messy CSVs.
Just a small command that gives you what matters most: a date and a number.
The idea was to create the smallest possible working representation of FinOps — a tool that could extract data with minimal permissions and output it in the simplest possible format.
A file with two columns — date and value.
That’s it.
No layers of formatting, no dashboards, no noise.
From there, the simplicity becomes power: you can graph it in Excel, combine it with another script, or pipe it directly into the next tool.
It’s how context becomes concrete — one small, clear dataset at a time.
Why it exists
Most people start with AWS Cost Explorer. It’s powerful, but also overcomplicated.
You click, filter, wait, export, clean, and repeat. It’s a workflow that breaks focus.
I wanted the opposite — a way to stay in the flow.
One command. One output.
From there, you decide what to do with it.
So cost_and_usage.py became the first FinOps Toolkit script.
It pulls cost and usage data directly via the AWS CLI, groups it by your chosen dimension, and outputs clean CSV lines to standard out.
It’s small, transparent, and practical — the way command-line tools should be.
What it does
cost_and_usage.py uses the AWS Cost Explorer API to extract billing data at different granularities (hourly, daily, monthly) and group it by service, account, or tag.
It was designed for:
- Speed: a one-line command instead of a web console detour.
- Portability: plain CSV output so you can feed it anywhere.
- Composability: works as the first step in a chain of FinOps tools.
- Clarity: you always know exactly what data you’re looking at.
Example:
python aws/cost_and_usage.py --granularity daily --group SERVICE --output-format csv
That’s it — you get a simple, readable output you can:
- Graph in Excel
- Load into a notebook
- Pipe into another script like
forecast_costs.py
Why simplicity matters
FinOps starts with visibility, but visibility doesn’t have to mean dashboards.
Dashboards are where you end analysis — not where you start thinking.
By keeping the data small and local — just a list of dates and values — you stay closer to the truth.
You can see what changed, when it changed, and by how much.
It’s clean enough for finance, simple enough for engineers, and structured enough for machines.
Simplicity is the best form of interoperability.
A relatable use case
You’ve just been told, “You now own the AWS bill.”
You don’t want to learn a new platform; you just want a reliable dataset.
You open your terminal and type:
python aws/cost_and_usage.py --granularity daily --group SERVICE --output-format csv > costs.csv
A few seconds later, you’ve got a clear table of services and spend by day.
You can spot spikes, calculate averages, and — most importantly — talk about what’s actually happening.
That’s FinOps at its most grounded: not dashboards or abstractions, just a CSV and a conversation.
Design philosophy
cost_and_usage.py was built to be:
- Local-first: runs entirely on your machine.
- Composable: plays well with pipes and redirections.
- Forgiving: still works even when tags are missing or optional libraries aren’t installed.
- Explainable: every flag means something clear.
It’s not just a utility — it’s a mindset: start small, stay in context, build clarity.
What’s next
Once you have clean cost data, you can do anything with it.
The next natural step is forecasting — taking that same CSV and projecting where spend will go next.
That’s exactly what the next tool in the series, forecast_costs.py, does.
👉 Explore cost_and_usage.py on GitHub
(Open-source, MIT licensed, contributions welcome.)