Measure before you cut
The first saving always comes from sizing: most machines are provisioned for a peak that never comes.
Before touching anything, we therefore started with two weeks of observation: actual CPU and memory usage, hour by hour, for every machine and every database. Two weeks, because a single week does not show the month-end cycles, and that is often where the real peak hides.
The finding is almost always the same: servers sized at launch, "to be on the safe side", and never reviewed since. A machine that never goes above a quarter of its capacity over the whole period can drop one size without anyone noticing.
First lever: right-sizing
The rule we apply is simple: size for the observed peak, plus a reasonable margin, not for an imagined peak. And do it gradually:
- one size down at a time, never two at once;
- starting with the least critical environments;
- with a saturation alert and a rollback ready for every change.
Where the load varies a lot during the day, autoscaling does the rest: few machines at night, more at peak hours. The service is never degraded, since capacity follows demand instead of anticipating it.
Once the load is stable and well understood, one- or three-year reservations become worthwhile: the provider grants a significant discount in exchange for a commitment. But you only reserve after right-sizing, never before. Committing for three years to a machine twice as big as needed locks in the waste.
Second lever: the storage lifecycle
Storage is the expense that grows silently. Application logs, backups, exports, files uploaded by users: everything piles up, and everything is billed at the same rate, whether you look at it every day or never.
Yet providers offer cheaper storage classes for rarely read data, and lifecycle rules that automatically move or delete files based on their age. Together with the business and legal teams, we defined a retention period for each type of data:
- technical logs stay available for a few weeks, then are archived;
- backups follow a clear rotation: daily, then weekly, then monthly;
- temporary exports are deleted automatically.
The tricky part is not technical: it is getting a written decision on what you are allowed to delete. Once that decision is made, the rule applies itself, without anyone having to think about it.
Third lever: switching off what is not in use
Development, test and acceptance environments have no reason to run at night and over the weekend. Yet they almost always do, out of habit. A schedule that stops them in the evening and restarts them in the morning cuts their cost by more than half, simply because a week has far more off-hours than working hours.
The same logic applies to forgotten resources: detached disks, reserved IP addresses with no machine, snapshots of old servers, demo environments set up for a client a year ago. A monthly inventory, with a named owner for each resource, is enough to make them disappear.
Making the bill readable
None of these levers lasts if nobody knows who consumes what. So we tagged every resource with three pieces of information: the project, the environment and the owner. The bill, until then a long list of technical lines, becomes a table by team and by application.
This simple change shifts behavior. When a team sees its own consumption every month, it switches off what is no longer used of its own accord. A budget alert per project completes the setup: an overrun is spotted within a few days, not at the end of the quarter.
What we did not do
We did not change providers, rewrite the application or reduce production redundancy. Savings that require taking a risk on the service are not savings: you pay for them later, at the first incident.
A cloud bill is managed like a budget: you measure it, assign each line to an owner, and review it every month.
The biggest gain, in the end, is not technical. It is the habit of looking at the bill regularly, line by line, with someone who knows what each resource is for.