FinOps stopped being "check the AWS bill once a month" a while ago. The FinOps Foundation frames it as a cultural practice with three recurring phases — Inform, Optimize, Operate — run continuously, not a one-time cost-cutting project. The fundamentals below are what makes that loop actually function instead of stalling at the first phase.
Inform: visibility before anything else
You cannot optimize spend you cannot attribute. The Inform phase is about getting cost data allocated to the right team, product, or feature — via tagging, account structure, or a cost allocation tool — and getting that data in front of the engineers who actually make provisioning decisions, not just finance. The common failure is a beautifully built cost dashboard that only finance ever opens; if the team whose service is driving spend doesn't see it, nothing changes.
Cost allocation lives or dies on tag coverage. A resource without an owner, environment, or cost-center tag is untraceable spend, and untraceable spend is what accumulates into an unexplainable bill. Enforce tags at provisioning time (via policy-as-code) rather than trying to backfill them later.
Optimize: the well-known levers
Once spend is visible, the optimization levers are well understood: rightsizing (matching instance size to actual utilization), commitment discounts (reserved instances, savings plans, committed use discounts depending on cloud), eliminating idle or orphaned resources (unattached volumes, unused load balancers), and choosing the right storage tier for access patterns. None of this is exotic — the friction is almost always organizational, not technical: nobody owns cleaning up an idle resource that isn't clearly anyone's responsibility.
Operate: making it continuous
The Operate phase is where most FinOps efforts quietly die. It means setting spend thresholds and alerts, reviewing them on a cadence, and building cost awareness into the normal engineering workflow — a cost estimate in a PR that changes infrastructure, a budget alert that pages before the bill arrives rather than after. Without an Operate phase, Inform and Optimize become an annual fire drill instead of an ongoing discipline, and savings erode as new spend gets provisioned the same old way.
# Example: cloud budget alert threshold config
budget:
name: platform-team-monthly
amount_usd: 45000
period: monthly
alerts:
- threshold_percent: 50
notify: slack-platform-team
- threshold_percent: 90
notify: slack-platform-team,email-eng-lead
- threshold_percent: 100
notify: pagerduty-oncallUnit economics over absolute spend
A rising cloud bill is not automatically bad news if revenue or usage is rising faster. Mature FinOps practice tracks cost per unit — cost per customer, per transaction, per API call — rather than the raw total. A team that doubles infrastructure spend while tripling paying customers is improving unit economics even though the dashboard shows a bigger number. Reporting only the absolute figure to leadership invites cost-cutting pressure on a metric that's actually trending the right direction.
Reserved instances and savings plans lock in a usage pattern for one to three years. Commit before workloads stabilize and you're stuck paying for capacity shaped like last quarter's architecture. Start with on-demand, let usage patterns settle, then commit against the stable baseline.
Wrapping up
FinOps fundamentals in 2026 are the same three phases the Foundation has taught for years — Inform, Optimize, Operate — run as a continuous loop with engineering, not a quarterly finance review. Get allocation right first; every optimization lever is wasted effort if you can't tell which team's decisions produced the spend.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.