Infrastructure Cost Analytics: turning cost data into next steps
Around 2023, Amazon was making a broad push to reduce costs. Service owners had detailed infrastructure cost data, but understanding a change meant digging through tools, resource types, regions, and time periods. They still had to work out what to do next.
A grid representing infrastructure spending recedes around three highlighted priorities, linked as a set and marked with server, database and cloud symbols. Illustrative priorities, not actual cost data or product UI.
A senior engineer had proposed automated cost reporting and built a narrow prototype. I saw an opportunity to go further: show service owners which actions could improve efficiency and help them decide where to start.
As an SDE II, I built the product from scratch, writing and testing the code myself. I also handled integration, user outreach, feedback, support, and the roadmap.
Give people a useful next step
I chose email because it was already part of people's work. It also forced me to be direct: the report needed to make its point without asking someone to spend more time in another tool.
Users could configure daily or weekly reports for the cloud services they cared about. Each report showed key numbers, short- and long-term trends, efficiency metrics below target, and three prioritized recommendations. Senior leaders could receive aggregated reports across services. Separate daily checks sent alerts when an efficiency metric dropped below its target.
The recommendations used rules and calculations. For example, a team might have scaled up for a peak event and left that capacity running afterward. The tool could recommend reducing capacity, calculate the expected improvement in its efficiency score, and rank the action by impact.
I later added an LLM summary to explain the results and call out key trends, risks, and recommended actions. The underlying calculations supplied the recommendations and estimated score changes.
Make the data consistent within each report
The hardest engineering problem was bringing the data together. Sources used different schemas, formats, and kinds of values, and those differences varied by infrastructure type. I had to aggregate them into a consistent view that made sense across services.
Freshness varied too. Some sources were days behind others, and missing records could arrive later. I aligned the data within each report to the same reporting date and displayed that date clearly in the email. That kept the figures consistent within a report and made the time period explicit to the reader.
Simplify the report after listening to users
Early reports had long, verbose recommendation lists and too many numbers in the preview table. Users asked me to cut them down and surface the most important information.
That feedback exposed a familiar problem: I was still asking people to filter information themselves. I shortened the recommendations, removed unnecessary numbers, and focused the report on the highest-priority actions.
Users also wanted to know what was going well. They were making changes and wanted to see whether their initiatives had an impact. I added a section showing positive developments alongside the remaining opportunities.
Grow through direct outreach
I recruited the first teams through internal messages and office conversations, starting in my organization and expanding to sister organizations. My manager and skip-level manager helped with introductions. I stayed involved in support and feedback as the product grew.
More than 20 teams subscribed to regular reports. Teams acted on the recommendations to reduce excess capacity and adjust infrastructure configurations, resulting in approximately $750K in estimated savings.
What I'd do differently
As a software engineer, I found it harder to push for user interviews than to keep building. I'd advocate for those conversations much earlier now. The feedback that led me to simplify the reports could have saved development effort if I'd sought it sooner.
I'd also plan usage and impact measurement from the beginning. I spent too much time estimating impact later; building measurement into the product earlier would have made it easier to understand how people used the reports and what changed as a result.