Inside AWS At 20: Werner Vogels On The Moment Everything Changed

I'm Werner Vogels. I'm the chief technology officer of Amazon.com. And the role of a chief technology officer can have different ways. You can look at that in different ways. You know, some CTOs are just a data center manager. When I joined Amazon, I came out of academia when the role of CTO was really as sort of the big thinker. Until 2004 more or less, when I joined Amazon, engineers were really good at scaling, but from a practical point of view, they'd gotten their hands dirty. And by getting an academic on board, they hoped to sort of more structure the way that we were building our systems because we were building systems at a scale that nobody else had done before, and absolutely not, and you know, no commercial software operated at the scale of Amazon. And so, but when we started AWS, the role as a CTO changes. It changes much more as what I think Scott called it an external-facing technologist: someone that talks to your customers, understands your customers, and takes that information back and what's the next set of tools that we need to build. What are the kind of things are we doing well or not? Like in my last keynote at re:Invent, I didn't talk about tools at all, but how do we change as developers? And so the chief technology officer is not only the one that actually runs technology. There's a lot of other parts to that that are, in my view, really fun.

It is because it's really true. I almost didn't take that call. So in the US, it's pretty normal for academics to actually do some consulting for companies and give them advice and things like that. And I've done things for Sun Microsystems and Microsoft and DEC and others. And when Amazon called to actually say like, hey, can you come and give a talk about your work? And I go like, really? Amazon? It's a bookshop, a web server, and a database. How hard can it be? But I was curious, so I did go. And one glimpse in their technology kitchen, and I was completely blown away. Commercial software doesn't work at all. And so they had to build everything themselves. That's an opportunity you couldn't let go.

Well, first and foremost, the scale at which they needed to operate at. I didn't, maybe I didn't really understand because I'd always think about Amazon as you push this button, I want to buy this, and then a package arrives. What sits in between there is just massive. And whether that is recommendations or forecasting or how to run our fulfillment centers and all these kind of things were at a scale that I had never thought about in academia at all. And scale was really important because they couldn't use commercial technology because commercial technology wasn't it. Remember, this is when Amazon was created, this is 1994. The word e-commerce doesn't exist. And almost everything that has happened in e-commerce has been pioneered by Amazon. Think about recommendations. Every site these days, whether it's an e-commerce site or anything else, has a recommendation engine. But Amazon needed to build those first themselves. They needed to come up with the idea. We've been using AI technology, what we, well, in the past we called AI, from day one. Why? Because the data sets that Amazon need to operate at are so large that no human can actually hold this in their head. And you know, this is a great example, I think, of really building things yourself to solve your own hard problems. For example, was when we built Dynamo. This is the first key-value store. So what had happened is in the early days of Amazon, there was something called $25 free shipping. That meant that if it was more than $25, we would ship it for free. But it was a put-off date before Christmas. This is December 12th. If you bought before that more than $25, we would ship it to you before Christmas for free. So December 12, biggest day of the year. And our customer management database runs on a cluster of a very well-known commercial database vendor. There's a bug in there that only shows up on the massive scale. Of course, we're pushing that. We hit the bug December 12, most busy day of the year, with dead in the water. Of course, representative of this company all the way up to the C-suite comes and visits us because we were not happy. And they looked at me and said, 'You should have tested better.' Now, that wasn't the right answer for me, of course, but they were right because we were using commercial technology completely out of bounds of what it was designed for. So, one of the first things I did after that is actually send an intern into that head. So, go figure out how are we actually using relational databases. By the way, that intern is Swami Sivasubramanian who now runs our AI group. But he came back to me and said 70% of the database operations are key-value. They're not relational at all. And so we go like, but wait, but we know how to build that. The predecessor of DynamoDB was really our desire to not use this one hammer. It's just a relational database for a problem that it was absolutely not built for. Look at the shopping cart. Nobody goes to the shopping cart service and says, 'Give me all shopping carts that have Harry Potter in it.' No, it is you go to the shopping cart service with this customer ID and you want the shopping cart. That's all you want and then you get a blob. So, this was a good example of sort of the kind of things how we do that at Amazon. Reinvent ourselves out of a tight spot. And instead of going to look for a vendor that has this, because we know already that commercial operations don't work at the level of Amazon. And so we also went through a number of architectural changes over time where at the same time, if you think about going switching over to AWS from Amazon retail to AWS, something that was really popular in the early 2000s was to put an API on some of your internal processes. So in the case of Amazon retail, that was the catalog, the shopping carts, and lots of young businesses were being built around that: comparison shopping, complete new visual interfaces of bookshelves and things. As soon as one became popular, they all started to stutter in the execution because now suddenly they needed to get investment because they needed to buy hardware because they became popular. They needed to hire IT people because they needed to babysit the hardware and things like that. All of those companies failed because of that. And we were looking at that going like, but we solve this for ourselves. You know, can't we start taking, can we start building technology based on what we've experienced within Amazon and actually offer this to companies? And that was how we were looking at it in the early days, that also need to reach internet scale just like Amazon. And we only originally focused probably more on younger businesses. Yeah, I think so, because the internet was young in 2000. Yeah, we just gone through the bubble. Yeah, and so that was how things, how we were thinking about it. Can we build technology that any other company that would like to be like Amazon can actually do this without having to make massive investments into hardware and related things. And there was one other thing, and if I think about the technology that we built, S3 and EC2, I'm immensely proud of that. But what I'm most proud of is something else that we did at the same time. Namely, when I was the CTO of Amazon, I have written some big checks to vendors. And the only way to get your cost down was to make a very long-term commitment at Amazon scale. I have no idea how many databases I need 5 years from now. So you massively over-scale and over-provision. Then you write this check and then the vendor doesn't care anymore because he's been paid. I hated that. I hated the fact that I felt I was being sort of, there was the vendor was always in charge. I was never in charge. So when we started AWS, we also decided to radically change the economic model, namely going from a prepaid model to a pay-as-you-go model. And remember, this is what we do in everywhere in our lives. I don't go to the gas station at the beginning of the month and deposit what is it, 500 euros and say like, and now I'm going to come and get gas for the rest of the month whenever I need it. No, you pay for what you've used. Or what you acquired. Or electricity. I mean our electricity bill at home is from what you've used. And so it is a natural way, but it's not how all technology, every technology company requires you to pay up front. And so I think our switch to actually to pay-as-you-go model completely revolutionized the whole IT industry because now suddenly customers knew that they could get actually bang for their buck. But they could also experiment, you know, and because they would know exactly, oh, if I do it this way, this is how much this is going to cost me. And bringing that to today, you know, where AI of course is on the forefront of everybody's mind, is one of those environments where we have all of these models, all sizes of each of these models as well, but with that comes a cost picture. If you use this particular model, you know, it's going to cost you five cents per million, what is it, tokens, and maybe if you use that model, it costs you $5 per million tokens. Is that answer so much better? Is the quality better? You know, as such, Bedrock is an amazing environment, I think, for most of people that are building things with AI to first of all experiment to figure out maybe this DeepSeek small model is just good enough for what we're trying to do here at this particular price point. But maybe, you know, you're in a heavily regulated industry and your requirements are different and you need a different quality answer for which you may be willing to pay more. But all of these things are suddenly up in the air. The customer decides. I don't force my customers how much they need to use and what they need to use.

First of all, the stuff that people were doing in the past, the enterprise software and things like that, is not going to change. It's not the world's not changing overnight suddenly, where everything has suddenly be is based on AI. If you, you know, really play a very important role in areas where, for example, there's a lot of paperwork. Absolutely. I just heard this story. This is the Department of, what is it, Work and Pensions here in the UK. They get 25,000 letters a day. What? Yeah. How many humans do you need to actually do this? So, they built an AI system where they're scanning all these letters and then figure out which should have the highest priority in being addressed. Because there are certain, some of these letters are just pensioners having a beef about something, but some may be of very vulnerable people needing immediate assistance. So using AI to sort of reprioritize sort of the answering of these letters and addressing the issue is important. Now is our development still driven purely by customers? Absolutely. But not necessarily always what your customers tells you. You need to observe it and you need to look at multiple customers. Now often a good example is Amazon WorkSpaces, which is our virtual desktop environment. We would never have built that if it wasn't that when the 20th CIO I talked to also said and say, don't you know, isn't there a better solution than the virtual desktops that we have at this moment because everybody wants to bring their own laptops to work and things like that. So sometimes it is also observing the kind of things that are happening in the industry or where the big, big open gaps are and then filling them. I want to make a distinction between the things that we do by customer feedback and whether that is direct or indirect feedback and the things that we do under the covers, which I call invisible engineering. So if you think about cost, reliability, availability, security, all these things under the covers that we do under the covers is continuously innovating there and you'll never see a press release about that. Suddenly customers realize that their Lambda functions don't take 300 milliseconds to start. Actually, it's now only 200 microseconds. And so there's a lot of engineering that we do under the covers to continuously improve over these six different pillars that we have. Sustainability, for example, being one of them. Well, there are kind of innovations that we can do in our data center to actually be a better steward. And for example, it's very important for us in the innovation in our data centers to, for example, be to manage water responsibly or to manage energy responsibly. By the way, all the energy, 100% of the energy that we're using, we are matching that with investments in renewable energy. Do we do that purely for our shareholders? No. Because we do that because it's better for the world. And better for our kids. And so also now with the dashboards that we give our customers where exactly milligram CO2 for your particular application is being shown, it allows our customers to actually start taking that into account when they design their applications. Oh, we want to reduce the amount of CO2 that we're using. Or that we create. So there are so many different areas that we are continuously innovating in. Is it only the customer? Yeah, for a very large part. After all, we are building products for customers, but we also continuously improve the quality of those products under the covers without people seeing it. When we launched Lambda, which is our serverless service, nobody else had done this before. We didn't really know how to implement this, but we did know that customers wanted this. Customers wanted not to run a whole battery of EC2 instances just in case some work came by. A good example there is a company called WeTransfer. So WeTransfer, if you have very large files, you basically, what they allow you to do is upload it to S3 and then someone else can download them. But what they also do is check for virus and compress it. For that they had to run a whole battery of EC2 instances in case a file got uploaded. Now imagine you would not have to worry about those EC2 instances but you know you get an event when this new file arrives and then this particular code gets executed. And many of our customers had these kind of problems where serverless was actually the right answer to that. But when we started that off, we had no idea how to implement this. We knew what we wanted to do. So we had taken our smallest EC2 instance, the T2, as being something underneath the covers. It cost us a lot of money, not the customers, but we at the same time were developing something called Firecracker, which is a microVM management system that would be able to allow us to actually run serverless at maximum scale and at minimum cost for our customers. So under the covers, we do a lot of innovation as well that the customer never sees. And so there's many different areas that drive our level of innovation.

Maybe because I'm a bit older, you know, I've seen many programming languages come by as they come and go. When I went to school, I learned Pascal and COBOL. And now probably kids come out of university probably are all proficient in Python or something like that. So over time we see continuously evolution of tools. And so my first programming was done in VI, and then you started getting all these different IDEs. Visual Studio Code is actually one of the most important ones now, and then Cursor and Kiro come along, and there will be other tools after that. So as a developer, you need to be curious, you need to be willing to learn, because otherwise this is not your job. Because our world is continuously in flux, continuously new. So there are, depending on the newer toolset that arrive, different requirements on developers as well. For example, communication becomes way more important. Understanding, you know, we have a meeting with your customer or whether that's internal or external, and how available does this need to be? Because four nines is more expensive than three nines in a way that you implement. Now your AI can't figure that one out for you. He can't see, they can't have this understanding, the bigger picture really. And owning the tools, realizing that AI is just a tool. It's a better tool than we had in the past, but it's still a tool. I'm still responsible. I'm still the owner. If I'm in a regulatory environment, let's say financial services or healthcare or things like that, and my AI tool has made a mistake, I'm on the hook for it. Not the AI. And as such, you know, you're still the owner of what the tools built for you. So, you better understand what the tool has built. Now, we're getting more and more tools to help us with that. But it is that it's the quality. I mean, it's as humans that has to have the ingenuity. And I think one of the things, but as part of being a Renaissance developer is not to be only be deep on your databases, but if you're a database expert, you also understand some of what your colleagues are building such that everything is a collaboration. And you know, no matter what tools we build, collaboration is still a human interaction.