From this case study you will learn
- why an AWS bill without a weekly rhythm lands at the end of the month
- how a landing zone and an instance-type list change cost
- how to arrange daily reports and an alert when a threshold is crossed
- what the cleanup did: 40 percent less on a monthly scale
The client ran services on AWS. The account grew with products, environments and experiments. There was no landing zone. Instance type was chosen in the console, often in a size kept in reserve. Cost was visible when the invoice arrived. By then a month of idle, oversize and services nobody had turned off had already passed.
What the client brought
There was no account split and no guardrails. Instances were launched from the console. Tags were not required, so the service had no owner. Cost Explorer, if it was on, had no rhythm. Nobody received a report in the morning. Nobody received an alert when daily cost crossed a threshold.
What stayed in the bill
Preview, logs without retention, disks after a migration and a dead load balancer stayed until the end of the period. Instance type was not a decision from a measurement. It was a click. At the end of the month the team woke up to a figure that could no longer be undone, only explained.
This was not ill will. It was a missing frame: who may create a resource, in which account, with which type and with which tag.
Why the bill lands at the end of the month
AWS bills usage continuously. Visibility once a month is not control. Without a landing zone there is no frame. Without an alert a spike is visible after the fact. Without a daily report nobody ties yesterday’s deploy to today’s cost.
Oversize without a list
An instance type without a list in the Terraform module returns to oversize. Idle has no owner, so nobody closes it. An invoice at the end of the month is then the first signal, not the last check.
For finance it looks like a surprise. For engineering it looks like a month of work without a mirror. Both teams receive the same PDF and have no shared language for the week in which cost leaked.
How we arranged it
We put a landing zone in place: accounts, IAM, SCPs, logs and default networks. Instance type went into the Terraform module, with a separate policy for production and for preview. Tags are required. A resource without an owner does not pass.
A daily report, an alert on a threshold
We introduced a cyclic, daily cost report per account, service and environment. An alert goes out when daily or cumulative cost crosses an agreed threshold, or when a new spend type appears. Idle, disks after a migration and dead load balancers we close in the same rhythm as rightsizing.
This is not IT accounting. It is an engineering rhythm: a week of anomalies, a month of rightsizing, a quarter of commitments. A morning report gives a chance to close a leak in the same week it appeared.
Order before commitments
Allocation and idle first. Then a change of instance type and storage class where measurement confirms it. RIs and Savings Plans enter after a few cycles, not in the first week. Otherwise a commitment freezes oversize.
Result
After measurement and cleanup the bill fell by 40 percent on a monthly scale. On a yearly scale that is hundreds of thousands of dollars that previously went to oversize, a missing limit and a missing owner. The ongoing rhythm stays: report, alert, quarterly review. The same layout is described in the FinOps service.
Summary
A cloud without a landing zone and without an instance-type list is not cheaper. It is unreadable. A daily report and a threshold alert do not replace architecture. They give time to close architecture and idle before the invoice arrives.
Write to us