finops-architect-toolkit
FinOps calculators for AWS architects: RI, S3, Lambda, and tagging strategy.
git clone https://github.com/fernandofatech/finops-architect-toolkit.gitfinops-architect-toolkit is a Next.js 16 + TypeScript web application that gives solution architects a set of focused cost calculators — EC2 Reserved Instance break-even, S3 storage-class optimizer, Lambda cost estimator, and a tagging strategy generator — designed to support real procurement and engineering conversations about AWS spend.
Why I built this
Architecture decisions drive the majority of a cloud bill. When I sit in a room with procurement, engineering, and finance, the conversation stalls because each group is working from different spreadsheets with different assumptions. I built this toolkit to close that gap with a single, shareable URL.
Each calculator is self-contained and opinionated: it asks only the inputs that actually move the needle and surfaces the number that matters — break-even months for RIs, effective cost per GB-month across S3 storage tiers, total monthly spend for a Lambda workload given invocation rate, average duration, and memory. The tagging generator produces a structured allocation taxonomy aligned to FinOps Foundation recommendations, which I use as a starting point when defining cost allocation policies for clients.
This is not a replacement for AWS Cost Explorer or Compute Optimizer. It is a conversation tool — fast, transparent, and reproducible. The formulas are visible in the source, so any engineer can audit them, challenge the assumptions, and adapt them to their own pricing agreements.
What the toolkit includes
How the application is structured
The toolkit is a purely client-side Next.js app — all calculations run in the browser. There is no backend API. Deployment is automated via GitHub Actions to Vercel, with DNS managed through Cloudflare.
- Architect · browser
- Cloudflare · DNS + proxy
- Vercel · Next.js 16 SSG
- RI vs On-Demand · calculator
- S3 storage-class · optimizer
- Lambda cost · estimator
- Tagging strategy · generator
- GHA: CI · lint + type-check
- GHA: Frontend · Vercel deploy
- GHA: Security · scan
Tech stack and design decisions
The frontend is built with Next.js 16 and React 19, styled with Tailwind CSS 4, and written entirely in TypeScript 5. I chose Next.js because static generation gives me zero-latency page loads and trivial Vercel deployment — there is no server to manage, no database to provision, and no API to secure. All calculation logic lives in pure TypeScript functions that are easy to unit-test and audit.
Three GitHub Actions workflows run on every push: a CI pipeline that runs lint and type-checking, a Frontend pipeline that builds and deploys to Vercel, and a Security pipeline that scans dependencies and static code. The security workflow is not cosmetic — I treat a public portfolio repo the same way I treat a production service: supply-chain hygiene matters.
Tailwind CSS 4 keeps the styling co-located with components and eliminates the need for a separate design-system package at this scale. The result is a codebase that any TypeScript engineer can clone, read, and extend in under an hour.
The live site is served from finops.moretes.com, deployed on Vercel with DNS proxied through Cloudflare for DDoS protection and caching at the edge.
Running locally
- 1
Clone the repository
Run
git clone https://github.com/fernandofatech/finops-architect-toolkit.gitand enter the project directory. - 2
Install dependencies
Navigate to the
frontenddirectory and runnpm install. Node 18+ is recommended to match the Vercel runtime. - 3
Start the development server
Run
npm run dev. The app will be available athttp://localhost:3000. Hot reload is enabled — changes to calculator logic or styles are reflected immediately. - 4
Build for production
Run
npm run buildfollowed bynpm startto verify the static output locally before pushing. ReviewSETUP.mdandOPERATIONS.mdfor deployment-specific configuration. - 5
Review architecture documentation
Read
docs/architecture.mdfor a deeper explanation of each calculator's formula assumptions and the tagging taxonomy rationale.
git clone https://github.com/fernandofatech/finops-architect-toolkit.git
cd finops-architect-toolkit/frontend
npm install && npm run dev
# App available at http://localhost:3000All calculations are client-side and auditable
There is no backend, no API call, and no telemetry. Every formula runs in the browser and is readable in the TypeScript source. If your organization has negotiated custom pricing or EDP discounts, you can fork the repo and adjust the rate constants directly — the code is intentionally straightforward.
Common questions
Are the AWS prices in the calculators kept up to date?
The rate constants in the source reflect AWS public pricing at the time of each commit. AWS changes prices infrequently for compute and storage, but you should verify against the official AWS Pricing pages before using outputs in a formal business case. The formulas are transparent enough that updating a rate is a one-line change.
Can I use this toolkit with Savings Plans instead of Reserved Instances?
The current RI calculator models Standard and Convertible RIs. Savings Plans have a different commitment structure ($/hour rather than per-instance). The calculator does not currently model Savings Plans — that is a known gap and a reasonable contribution if you want to extend the project.
Is this suitable for multi-account AWS Organizations environments?
The tagging strategy generator is explicitly designed with multi-account allocation in mind — the taxonomy it produces maps to AWS Organizations tag policies and Cost Categories. The calculators themselves are workload-scoped, not account-scoped, so you would run them per workload and aggregate manually.
Why Next.js for a toolkit that has no server-side logic?
Static generation, file-based routing, and zero-config Vercel deployment make Next.js a pragmatic choice even for fully static sites. The alternative — a plain Vite SPA — would have been equally valid. I chose Next.js because it aligns with how I build production frontends and keeps the door open for adding server components or API routes later without a rewrite.
Who this is for
This toolkit is for solution architects and cloud engineers who need to make cost trade-offs legible to non-technical stakeholders — quickly, without building a custom spreadsheet for every engagement. If you are running a FinOps practice, preparing a migration business case, or defining a tagging governance model for a new AWS environment, the calculators give you a reproducible starting point that you can share as a URL or fork and adapt. It is not a monitoring tool, not a cost anomaly detector, and not a replacement for AWS Cost Explorer. It is a planning and communication aid. The source is MIT-licensed, the formulas are auditable, and the architecture is simple enough that adapting it to your organization's specific pricing or taxonomy takes hours, not days. The live version is at finops.moretes.com if you want to try it before cloning.