Insights — Cloud and costs
Your AWS bill is not expensive: it is badly steered.
An account created on a Friday afternoon, a forgotten NAT gateway, three test environments running all night: cloud cost drift rarely comes from the price of servers, almost always from decisions nobody took. Here is how we read a bill, line by line.
01 — The problem
One year later the bill is up 35 %, with not a single new application.
In our clients' accounts, the bill grows for the same reasons every time: staging environments that never switch off, instance types chosen once and never revisited, storage that piles up without a lifecycle rule, and traffic crossing the public internet when a private link would do.
None of these causes is dramatic. All of them are invisible in the console, because the console shows the present state — never what changed, and never what is no longer used.
01The five lines that drift unnoticed
Compute comes first, but it is rarely the only culprit: an oversized instance is expensive because it is too large, not because the provider is pricey. Databases come next, with storage and backups that grow and are never purged.
Object storage is the third line, and usually the worst organised: gigabytes kept in the most expensive class for files nobody has opened in two years. Network is the fourth — and the most surprising for finance teams, because it contains no visible resource. Observability is the fifth: logs and metrics kept forever, at a cost that eventually exceeds the application being monitored.
- Compute: frozen instance families, test environments left running
- Databases: backups and logs kept without a retention policy
- Storage: wrong classes, orphaned versions, detached volumes
- Network: NAT gateways and cross-zone traffic never measured
- Observability: logs kept without filter or defined retention
02Reading a bill in three passes
The first pass is factual: we attach every line to an application, a team and an environment. Without that step no decision is possible, because nobody can arbitrate a cost line that has no owner.
The second pass compares: we look at twelve months, not the current month. A stable bill that doubles in three months tells a precise story — a deployment, an import, an unfiltered replication.
The third pass looks forward: we rebuild the target bill with capacity commitments matched to genuinely stable workload, and a budget per application with alerts at 60 %, 80 % and 100 %.
03The six levers that actually cut the bill
On a mid-sized platform, six actions usually remove more than half of the wasted spend without touching availability.
Rightsizing comes first, because it needs no negotiation and takes effect immediately. Capacity commitments come next, but only on stable workload: paying ahead for an uncertain workload turns a variable cost into a risk.
- Resizing oversized instances
- Moving to Graviton processors where the workload allows
- Capacity commitments on predictable workload only
- Automatic lifecycle rules towards cold storage classes
- Replacing public paths with private endpoints
- Scheduled shutdown of non-production environments
04What we never cut
One saving is forbidden: reducing redundancy. Removing an availability zone or disabling the backup copy lowers this month's bill and raises the cost of the incident that will come.
We also refuse to optimise without measurement. Every recommendation is costed, dated and verifiable in the following month's bill: if the promised saving does not appear, the method is at fault, not the accounting.
A real reading: €3,200 a month down to €1,420, that is €21,400 a year, at constant scope and constant service level.
02 — Common questions
The three questions we are asked on this topic
How long before the bill actually goes down?
The first effect appears the following month on visible lines: unused environments switched off, instances resized, orphaned storage deleted. Capacity commitments show on the second or third month, because the genuinely stable workload has to be measured first.
Can you optimise without hurting performance?
Yes, provided you measure before deciding. We only resize an instance after looking at thirty days of real usage, and we only change processor family after a comparison in staging. Every optimisation is reversible.
Do we need a paid tool to track all this?
No. Native AWS features are enough: mandatory tagging, budgets per application, cost reports per service and drift alarms. Specialised tools add comfort as a platform grows; they never make the decisions for you.
Do you want to know what your platform should cost?
Five-day AWS audit: mapping of accounts and network, twelve-month billing analysis, costed and ranked optimisation plan.