In August I was writing a cost analysis for a client and the daily view in Cost Explorer showed the best news of the month. Spend for the last three days read $284, then $158, then $62.
If that were real, something had just cut the bill by 78% in 48 hours. Nothing had. Nobody had shipped a cost change. No environment had been turned off.
It is the kind of chart that ends up in a status update, especially in the middle of a cost engagement where everyone wants good news. That is exactly when this mistake happens.
The first check was to look at the same period with a different granularity. The hourly data, pulled at the same time, put the recent days at $279 and $168. Still lower, but nothing like the cliff the daily view drew. Two views of the same bill, pulled at the same moment, should not disagree by that much.
That is the first sign. Real spend does not change after the fact. Late data does.
The second check is the one I now run every time. I broke the last few days down by service and compared each service's drop.
When a real change lowers your bill, it lowers one thing. You resized a database, so the database line drops. You removed a node group, so compute drops. Everything else stays where it was.
Here every service fell by the same share on the same day. That pattern makes no sense as an engineering change. It makes perfect sense as "AWS has not finished posting usage for these days yet". Each service had reported part of its usage, so each one looked smaller by about the same fraction.
The last clue was the line that did not move. On the most recent day, the only charge that looked normal was the Savings Plan commitment.
That is a fixed amount. AWS knows it in advance, so it posts on time, every hour. Usage charges arrive later, as each service meters and reports. So on a day where usage data is still coming in, the commitment fee sits there at full size while everything around it looks tiny.
If the flat commitment line is most of your total on the last day, you are not looking at a cheap day. You are looking at an incomplete one.
AWS billing data is not real time. Cost Explorer refreshes during the day, and usage from some services takes longer to arrive than others. The most recent day is almost always low, and the day before it can be low too. AWS says this in its documentation, and everyone who works with billing data knows it. It still catches people, because the chart does not draw incomplete days any differently from complete ones.
The forecast inherits the same problem. A month-end forecast built on the last few days will be optimistic until the data settles.
I do not report a saving that rests on the last 1 to 3 days. If a change went in on Monday, I compare full days after it with full days before it, and I wait until the data stops moving.
For anything that goes to leadership, I use complete months from Cost Explorer and say which months I am comparing. In that same engagement the number I quoted was May against August, both closed months: from about $20,800 to about $9,300 a month, 55% lower. Forecasts and partial months are useful for steering, but they are not results. One number that holds is worth more than a series of better ones that keep changing.
For day-to-day tracking, the per-service share check takes about a minute. Pick the last three days, group by service, and look at the percentage change for each. If they all moved together, wait.
If your cost reports keep changing after you send them, I can help you set up numbers you can stand behind. See Cloud Cost & FinOps.
On every cluster I looked at, workloads requested 7 to 20 times the CPU they used. The node autoscaler bought nodes for the requests, not the usage.
A fintech's CloudWatch line went from about $2.4k to $6.4k a month in two months. One API operation explained most of it: PutLogEvents.
Spot nodes were reclaimed, the on-demand fallback hit its own limit, and production was down for about 25 minutes. Then I moved production off spot.
