The 4 phases of FinOps, and why the fourth one matters
The FinOps Foundation framework rests on three phases: Inform (make costs visible), Optimize (find the savings) and Operate (get them applied). We add a fourth: Stay in control. Governance is what keeps waste from coming back on the next project.
Minimal tagging, linked to the CMDB
Teams are often asked to set a dozen tags. The result: incomplete, inconsistent tags that nobody maintains. Our approach is the opposite: as few mandatory tags as possible. Depending on the client, a single one is sometimes enough, for example an application code. It links the cloud to the CMDB, and every other piece of information (owner, cost center, environment, criticality) lives in the CMDB.
- Tag enforced at resource creation (Azure Policy, or Service Control Policies and Tag Policies on AWS).
- Automated consistency checks between the cloud and the CMDB.
- Tagging compliance tracked in the dashboard.
Showback, then chargeback
As long as teams don't see what they consume, they have no reason to optimize. Showback makes costs visible by application and business unit. Chargeback goes further by charging consumption to each budget. It is often the trigger: when a team pays for what it consumes, a non-prod running all weekend immediately becomes an issue.
When teams don't pay for their consumption, a clear mandate from leadership takes over: reliable recommendations are applied without waiting for each application owner's approval.
Light but regular governance rituals
- FinOps champions in each business unit, the first point of contact for the teams.
- Monthly SteerCo: consumption, annual forecast, variance to budget, savings achieved, action plan.
- Automatic budget alerts per scope, sent to the owner.
FinOps by design: standards, building blocks and checks
We set up FinOps governance that makes FinOps by design. From then on, everything that lands in the cloud is optimized from the start.
| Building block | Content |
|---|---|
| Standards | Default VM SKUs and disk types, data and log retention policies, backup policy per environment, sizing for today's need |
| Building blocks | Mandatory tag applied at creation, auto Stop + Start on demand enabled by default in non-prod, budget alerts created with every scope, filtered log collection |
| Project checks | FinOps checklist in architecture reviews and the CAB, policies that block non-compliant configurations, review at go-live |
In the cloud, you size for today's need: scaling up is easy. It is a cultural shift compared to on-premise, and it is what governance must anchor.
FinOps in the project lifecycle
FinOps by design happens project by project. We build it into your existing project process, with a simple cycle that repeats: estimate, monitor, alert, optimize.
| Stage | What is done |
|---|---|
| Framing | A first cloud cost estimate with the providers' calculators. It doesn't need to be exact: it must identify the most expensive components and options. |
| Build | Right components from non-prod onwards. A new estimate mid-project, after performance and volume tests. |
| Go-live | Scoring session with the project team and the run team: starting score, known cost risks, budget alerts created. |
| Run | Monthly monitoring in the dashboard, alerts at 80% and 100% of budget, cost increases analyzed with the tech lead, optimization. |
Every change gets re-estimated. Some options change the bill entirely: enabling verbose logs on a heavily used resource, adding geo-redundancy, launching a massive data transfer. A few days after the change, we check its real effect on costs. These are exactly the situations in our real FinOps incident cases.
Moving to the cloud: apply the rules from day one
Building it right at migration is much easier than fixing hundreds of VMs afterwards. We suggest adding three rules to the migration process:
- Size for the real workload, not for the on-premise spec, which is often oversized.
- Enable auto Stop and Start on demand on every non-prod VM from creation.
- Validate before go-live: a FinOps compliance check becomes a mandatory step of every migration.