Amazon wasn't born wanting to build the cloud. Its engineering teams spent 70% of their time managing infrastructure, and only 30% building products. Andy Jassy, the executive who led the creation of AWS, explained it: the goal was to flip that equation. The solution was to treat infrastructure as what it was, an internal service with real customers, delivery metrics, and a team responsible for making it work.
The result was AWS. The most profitable division in the history of the internet.
This is not an article about the cloud. It's about the question Amazon asked itself first and that most teams managing a Data Center still haven't clearly considered: Who does your Data Center really serve?
The customer no one has identified
At Amazon, everything has a customer. Before designing anything, the team answers who that customer is and what they need. Not vaguely, but concretely: what do they expect to receive and how do they know when something isn't working?
In most Data Centers, that question has no clear answer. IT infrastructure serves everyone in general and no one in particular. Teams use it because they have no other option. The business depends on it without fully understanding it. And the real impact of a failure on other people's work doesn't always reach the person managing the infrastructure with clarity.
Amazon would start with the customer. Not with the racks, energy efficiency, or SLAs.
Who depends on your Data Center to do their job? What do they need the infrastructure to deliver, and how do they know when something has failed? If you can answer this concretely, you're managing a service. If you can't, you're managing a cost.
Writing the outcome first, not the solution
Amazon has a working method known as "Working Backwards." Before building anything, the team writes the press release that would announce the finished product. The idea is simple. If you can't describe the outcome you're going to generate, you probably don't have a clear idea of what you're doing.
Applied to Data Center management, the exercise looks like this: write the headline that whoever depends on your infrastructure would read if everything worked exactly as it should. A real outcome, not a technical percentage.
Something like: the development team deploys new environments in minutes instead of waiting weeks, the finance department closes the month without interruptions or last-minute escalations, or the compliance audit found no surprises because everything was documented and traceable.
If that headline is hard to formulate, if what comes up are capacity or energy consumption indicators instead of concrete benefits for someone, Amazon would say you still don't know who you serve. And that until you do, any investment in the Data Center is hard to justify beyond the expense it represents.
Measuring what those who depend on you see
Amazon has an obsession with data, but with a specific type: data that reflects the experience of those who use the service. Data that says whether those who depend on the system are getting what they need, not just data that describes the internal state of the infrastructure.
In most Data Centers, the dashboard looks inward: PUE, available capacity, number of incidents. These are operational indicators, necessary and useful for day-to-day operations. The problem is they don't always indicate whether those who depend on IT infrastructure are being well served.
Amazon would add another layer on top. Things like how long it takes from when capacity is requested until it's available (measured from the perspective of whoever needs it, not whoever provisions it), or how long it takes to resolve an incident counting from when the application fails, not from when the internal alert fires. Also the percentage of service commitments met on time, and the cost per unit of service delivered instead of just total spending.
This connects to something we've already explored on this blog: data exists, but it doesn't always generate decisions. The question isn't whether your Data Center produces information. It's whether that information tells you something about how you're serving those who depend on you.
Acting as if it were the first day
Jeff Bezos had an obsession: avoiding what he called Day 2. Day 1 is when a team builds and learns. Day 2 is when processes become automatic, decisions slow down, and people start managing what already exists without questioning whether it still makes sense.
"Day 2 is stagnation. Followed by irrelevance. Followed by decline." — Jeff Bezos
Many Data Centers have been in that Day 2 for years without knowing it. Processes were designed when the business had different needs. Tools were chosen a decade ago. Metrics haven't changed since the last audit. No one questions them because they haven't visibly failed yet, and as long as they don't fail, no one touches them.
When was the last time someone on your team asked why Data Center management works the way it does? Not to solve a specific problem, but to see if the model still makes sense.
That's the difference between operating infrastructure and taking reponsibility for a service. Services get reviewed. Costs get approved.
Amazon didn't start out wanting to build the cloud. It started by refusing to treat its own infrastructure as a black box that just had to stay on.
The Data Center you operate today has the same potential — or the same risk. The difference isn't in the Data Center automation you've achieved. It's in whether those who manage it ask technical questions or questions about the service they provide.
Manage or serve. The answer defines whether your Data Center is a cost or an asset.
Links to the Amazon references
Andy Jassy: https://twitter.com/ajassy/status/1785293612835823716
Working Backwards. https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processes
Jeff Bezos: https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders