Case 2 · Growing SaaS platform
Regaining control of cloud spending for a SaaS platform
A growing company wanted to understand its cloud costs, assign every resource to a service and cut unnecessary spending, without putting production at risk.
Context
The platform was growing fast, and so was the cloud bill, without a clear view of which service consumed what. The company wanted to understand its costs, assign every resource to a service and cut unnecessary spending.
Constraints
- Do not put a growing production platform at risk.
- Involve both technical and finance teams in decisions.
- Keep a record of architecture choices that affect costs.
Scope
- Cloud resource inventory and tagging
- Usage analysis and rightsizing
- Spending budgets and alerts
- Regular cost and capacity reviews
Out of scope : The choice of cloud provider and application redesign were outside this scope.
Method followed
Phases and their acceptance criteria.
Each phase ends with a verifiable criterion, agreed with the client before moving on to the next.
Phase 01
Inventory and tagging
Listing resources and applying a common tagging rule: service, project, environment.
Acceptance criterionEvery resource is assigned to a service; resources without an owner are listed and dealt with.
Phase 02
Usage analysis
Comparing reserved capacity with actual usage, identifying oversized or unused resources.
Acceptance criterionEach rightsizing proposal is approved by the technical team before it is applied.
Phase 03
Budgets and alerts
Setting budgets per service and alerts when they are exceeded.
Acceptance criterionAn overrun triggers an alert received by the right people, on both the technical and finance sides.
Phase 04
Regular management
Regular cost and capacity reviews with technical and finance teams, with decisions recorded.
Acceptance criterionEvery cost-related architecture decision is documented with its rationale.
Logical architecture
Cost management chain
Generic diagram: it does not reflect the client's cloud provider or actual architecture.
Points of attention
The risks the method had to cover.
Typical risks in this kind of project, and how the method addresses them.
Cutting costs at the expense of availability
No rightsizing without technical approval; changes are made in steps and remain reversible.
Tagging that degrades over time
A written tagging rule, checked at every review.
Alerts nobody reads
Every budget has a named recipient, on both the technical and finance sides.
Decisions forgotten between reviews
An up-to-date log of architecture decisions.
Results
Budget visibility per service and regular management of capacity and costs.
Deliverables
- Resources tagged and assigned to a service
- Spending budgets and alerts in place
- Documented architecture decisions
What we would do again
- Tagging comes before optimisation: without it, no figure is reliable.
- Bringing technical and finance teams into the same review avoids one-sided decisions.
- A saving that weakens production is not a saving.
This case is presented without names, figures or infrastructure details, in line with our confidentiality commitment. An introduction to the client can be arranged, only with their consent.
Go further
Your situation
A similar context?
Tell us about your environment: we will walk you through the right method, without disclosing anything about other clients.