Agentic workflows tend to perform better on AWS than anywhere else. Compute sandboxes, gateways, agent permissions versus people — a lot of those are things that we have built and are building and thinking actively about.
The top frontier labs gobble up every available GPUs. At the same time, you want to promote newer companies that are going to become the enterprises of tomorrow. How are you thinking about balancing?
From the very beginning of when we launched AWS, startups have been the lifeblood of the core of what we do. These are the innovators that are at the edge of technology, understanding what's possible. We're very intentional about keeping capacity available for the startups. We recently announced we're going to be buying 2 million NVIDIA GPUs over the next couple of years.
Your capex is what, 200 or...
$220 billion for '26, and we don't anticipate slowing down anytime soon because the demand is just massive.
With all the debate around AI extinction risk and the Hugging Face attack, what are CEOs asking you about all these things?
Welcome to the pod, Matt. What a time we're living in. So I have a lot of topics to talk to you about.
Awesome. Thanks for having me. I'm excited.
Yeah, absolutely. So let's start actually right from the beginning, right? So you are the first GM for EC2.
And that was 2006, right? And today you guys are what, 160, 170 billion in revenue.
Yeah, about 169, 170 billion. Yep.
There's a ton of... and it's interesting to think about it from, you know, we were there in day one when we had like, you know, the first dollar of revenue, but...
Yeah, and it's, you know, the interesting thing is we're still at the early stages of what the business can be and what the opportunity is for customers. Most workloads still, you know, there's a huge amount of workloads still that live on-prem today, and the amount of compute that people are doing every single day is more than it was the day before. And so you see the tailwind from AI, you see the tailwind from migration into the cloud, and, you know, the business has grown really fast and it's been a super fun thing to be a part of.
Yeah, it is. It is. I mean, they'll be writing history books about this and business books about this for a long time to come. I want to touch on the on-prem that sort of boggles my mind. I obviously did my best to keep them there for a long time.
You built a lot of stuff on-prem back in the day, trying to now get all of that to move into AWS.
Yeah, so we can talk about that later. But so if you think about EC2 in the early days, and you got your start with obviously selling to startups, and today the AWS cloud service — I mean, as you reflect on the evolution, what stands out? Part one, and then part two we'll talk about how the nature of how you serve startups has changed.
Sure. Well, like you said, actually, it's funny. So I actually interned for AWS in 2005 when it was first kind of an internal project. It was my business school internship, and my project was actually to come up with an analysis of who we thought AWS would be most interesting to. And the answer was startups, like probably not surprisingly. And so, you know, from the very beginning of when we launched AWS, startups have been the lifeblood of the core of what we do for a number of reasons. One is the value proposition is just so attractive what AWS provides to startups.
And we spend a lot of time and effort making sure that we're great partners to the startups, helping them not just provide infrastructure but also advice on how to get your company up and running and how to think about your architecture so it'll scale eventually, and a whole bunch of things that we do for the startups. But we also think that for us it's just good business because the startups today are the enterprises of tomorrow. And, you know, it's an imprecise number, but today we estimate that, you know, maybe 30, 40% of AWS revenue comes from companies that were at one time, you know, startups in AWS's lifetime. So it's fun for us to see the companies grow over time and get bigger and become enterprises, effectively.
And so that's why we invest so much in startups and why we pay so much attention to the brand new, you know, two-people-in-a-garage type startups. And not just because of the business outcomes, but also because that's who we learn from. These are the innovators that are at the edge of technology, understanding what's possible, pushing our services to say what they'd want more of, what could help them go faster, what could help them achieve their outcomes. And a lot of times they're pushing more than the banks or the healthcare companies or the governments. The startups are the ones that are pushing that envelope. And it really helps us to be better and make sure that we're ahead of that wave where the banks are going to want some capability five years down the road that startups want today.
Yeah. And compared from then to now, how have the startups changed and what they want from you? Obviously they all want a lot of GPUs, and we can talk about that, but besides that...
Well, I will say there's a couple of things that have changed. One is, you know, startups started at a much smaller size than when we first started, right? They might have gotten $10 million of funding and they had an app idea that they were kind of slowly iterating on. Now it's like, you know, from day one they're valued at a billion dollars, they have $200 million of funding. It's like a team and an idea and all of a sudden they're worth a billion dollars, which... so, you know, I think the...
They just go from our offices to your offices.
That's right. That's right. And, you know, like the size and scale and ambition of the ideas, I think requires more capital. They're bigger to start with. They're obviously more expensive too, right? To go after kind of training a model or doing something that a lot of the folks are doing today. So that's number one, which is just the size that they start from is really big.
But I would say number two is some things haven't changed, right? They actually are still thinking about, okay, once I scale, how do I think about an architecture? How do I think about security? How do I think about performance? How do I think about having all the capabilities that I need? How do I think about setting up my IAM setup so that when I have more than three employees, this thing is going to work and scale, which is a lot of times why they like AWS as opposed to just, you know, going to a neocloud or something like that. They actually need all of those other security and capabilities that come around from training. And so I think that's something that hasn't changed and is exactly the same. I think the scale at which the ramp-up is definitely different today.
I also think increasingly we're seeing teams that want a cloud that is great to work with agents and not just with people. And I think that's where we've spent a lot of time — how do you think about, you know, exactly how do you think about broad scale? How do you think about performance? How do you think about an interface that is, you know, a well-defined API interface that agents can actually easily traverse and work across. And so that's also something that I think we were naturally set up to do well, but that we've actually doubled down on to ensure things like, you know, how can you start a database in three seconds and really get to some capabilities that agents are excited about.
I should have looked, but I haven't lately. Have you introduced any specific new services that are explicitly targeted at agents or people building agents?
I'd say what we've done is we've optimized some existing services so that they can both work for people and agents. And so the answer is, yes, we definitely have some services designed for building agents. So we have things like AgentCore and Bedrock and pieces like that. But when we look at just taking an underlying component like S3, right, which is where the vast majority of companies store their data and have their data lakes, it turns out like a lot of the use cases for people and agents are similar.
But one of the things that we have in preview right now, or in beta, it's called AWS Context, that allows you to build a context layer so that agents can actually more easily find all of the data they want across your various data lakes. And so whether you have your data stored in Aurora or you have it in S3 or you have it somewhere else in AWS, you can kind of build this context layer where people aren't necessarily going to access data in that way, but agents actually are happy to go across lots of those different things.
And so there are some services that we're building like that, but for the most part you also care about what does latency look like, what does throughput look like, how do you make sure that the underlying engine is actually fast, scalable. They actually care a lot about tail latencies, which is interesting, where people don't always care about the P999 S3 latency. Like agents do care and get blocked by that. And so that's the thing that we've cared about for a long time, and from a performance perspective it's one of the things that really popped. That's why agentic workflows tend to perform better on AWS than anywhere else.
Yeah, obviously we see a lot of companies starting out, and the very common refrain, of course, is that agents are writing all the code for them, right? And agents are selecting the databases and the email servers and everything that you can name it, right? So has there been a lot of thinking on that — and obviously they read the documentation — has there been a lot of thinking on the AWS, like your, feels funny to say, quote-unquote legacy services that have been around for a decade, on how do you rearchitect them?
I think there — so yes, I think there are some things that we've thought about. Actually, the core underlying building blocks I think are in really good shape. I think there's a usability layer that we're thinking about of how we make it easier to use for, we'll call it, like the very simplest use case you call out where somebody's just coding up an app really quickly and they ask it to deploy.
We find the vast majority of our customers will go and tell their coding agent — whether it's Cursor, whether it's Claude, whether it's Codex — they'll say like, I want to build on AWS, here's my credentials, here's my stuff, this is how I want to deploy it. And then the agents are great and they go do it. There are use cases though where you're already not on a cloud, you're just trying something, you say deploy. And frankly, a lot of times that'll go to some of our partners that have an easier-to-use layer on top.
Which we love, by the way, too. And we love our partners on those fronts too. But I do think that there are some things that we're doing where if you're brand new, you don't already have an AWS account, you already haven't set up your IAM — today, or we'll say a couple of months ago, it was much harder to start up an account, right? It's been like this for 20 years, but you have to define your VPCs, you have to define your IAM roles, all these kind of things, which are actually super important things once you get to be large.
And what we hear from customers is like it was a hard trade-off because they know that they're going to want those in months or years down the line, but for now they just kind of want to use the services, not worry about that. And so what we've actually launched is if you go create a new AWS account today — and we're slowly rolling this out, I don't know if it's actually fully all the way out yet now — but you don't have to do those things. You don't have to give it a credit card. You can sign up with your Gmail account. You get to just — all of those things are handled in default behind the scenes, and within less than 30 seconds you're up and running and can be operating in a full AWS account, which is, you know, for those type of systems much more what the agents want to be able to do because they don't want to have to go through all that setting up your VPCs and your pieces like that.
So there are some things where we're adding kind of some ease of use to that, which we're quite excited about, and I've seen some really positive feedback from customers on, and we'll keep doing more things like that over time.
And just one more thing on that, which is the great part about that though is it's not like a simplistic account and then you have to migrate. If you basically say, okay, now I actually do want to scale into the — or I want to develop an organization, I want to go and kind of fine-tune some of the things — you can easily come, you're already in a real AWS account and you can actually then go and do all of those things later when you need them. And so there's no migration or move later. And so that's part of the hard work that we really think about, which is how do we make it not a choice for the customer but an easy on-ramp into the depth of features that we know customers and startups are going to want when they start scaling.
Yeah, got it. And what has been some of the hardest things to accommodate as agents have taken over? I mean, you made a name — this is the way you guys became the phenomenon that you became, was serving developers, right? And then infra teams. Now developers are substituted by agents, and pretty soon infra teams are being substituted by agents. What has been some of the hardest things for you, as the largest service provider in the world, to handle that transition?
Well, look, I think, like I said, much of our infrastructure is pretty well set up to handle the scale, which is good. I think there's been a couple of things which are interesting paradigm shifts where you could argue that some of our systems are — I wouldn't say overengineered, but as an example, many agents want to create a database, do a little bit of work, and then have the database go away. You really need that database to have five nines of durability. Exactly, right.
And so there's some things that we rethink there where when you're creating an Aurora database as your production database, like you do want five nines of data, you need durability, you want availability, you want all of those things. And for the agent use case, that's arguably — or maybe not arguably — overengineered for what we need.
And so, you know, it's hard. We kind of have this belief that we don't really want to have like a non-durable option that's going to cause problems either, because you never really quite know if the database that's created wants to stay around for a long time or a short amount of time. And so we're trying to do the hard work to think about how do you accomplish both of those things, where you can create it quickly and throw it away and you don't really waste a lot of resources. But if you do want it and it can be durable and stay for a long time, it can actually grow into a big production database.
So those are some trade-offs that we think about actively as we think about how does the more traditional kind of 'this is going to be my production system' kind of capabilities match with some of the more transient nature of the infrastructure that agents want to use. So that's one, I think, but there's a bunch.
I think the scale and speed and latency of creation of durable resources is another one that's interesting. You know, I think the other one that we actively think about too is just are there new building blocks that agents are going to want that we just didn't really need before. And so compute sandboxes, gateways, agent permissions versus people or service role permissions — a lot of those are things that we have built and are building and thinking actively about because they are just brand-new building blocks.
It's not using the existing building blocks differently, but it's brand-new ones where pretty clearly you want different permissions for agents. You don't just want to give it Ragu's permissions and let it go do whatever you can do. You actually want very time-boxed, short-term permissions to just go do a task. You actually may not want to give permissions to a whole tool at all. You may want to get very fine-grained permissions on what an agent's able to do from a sandbox, right? You actually want a sandbox that...
Virtualization is having its day too.
That's right. Exactly. And they're different. It's similar. It's the same idea, but it's, you know, how do you have that lightweight and think about — fortunately we've done a lot of work with Firecracker, our kind of microVMs.
In fact, a lot of the sandbox company startups use Firecracker.
They all use Firecracker, which we invented 10 years ago maybe or something like that. And it's really purpose-built for — I mean, it wasn't purpose-built for agents, but it's actually quite good for agents because you can spin them up really rapidly. They have a great security boundary, and you don't have a lot of that virtualization overhead that you have from a traditional large VM. So, you know, I think those are some new building blocks that we're thinking about, and more emerge every single day, you know.
Yeah. So I've rattled enough into agents. I'll come back to it later, but it's a fascinating topic.
But let me switch gears a little bit and ask about something that every one of our startups face and we get asked most frequently, which is how can we get GPUs, right? I mean, obviously you guys have running massive GPU farms and increasing it every day, but the top frontier labs gobble up every available GPUs — more power to them. How do you deal with the internal — at the same time you want to promote newer companies that are going to become the enterprises of tomorrow, like you said — how are you thinking about balancing capacity needs and these small companies that don't have a lot of credit and whatnot?
Well, yeah, it's a great question. And a couple of these things make it more challenging. One is the capex expense needed to go deploy kind of all of the compute that everyone needs right now is massive, right? And so we are, I think...
Your capex is the same as what, 200 or something?
$220 billion for '26. At one point I saw that it's, you know, it's a pretty — I mean, that is a larger expense than we've ever had, maybe any company has ever had in a single year. And we don't anticipate slowing down anytime soon because the demand is just massive.
And so at some point you're limited by how fast can you build data centers, how fast can you deploy capital, how fast can you get memory and chips and all of those kind of things. And so all of those are at different points constraints that we're — whether it's power, data centers, capital, memory, chips, they're all kind of constraints at various times. Construction people to build buildings — like, you know, construction people are at a premium today.
And so all of those, we work really hard to make sure happen. And then with the capacity that we are able to deploy, which is still a huge amount and not enough, we know, we really think intentionally about what is that allocation strategy. And so we're great partners with the large frontier labs, the Anthropics and OpenAIs and Meta and other large customers. And so those folks are really good customers of ours.
And we want to make sure that we invest in them. We have large enterprise customers, whether it's Salesforces or JPMCs or, you know, other large companies that have demand for fewer numbers of GPUs or accelerators. Sometimes they want Trainium, sometimes they want NVIDIA GPUs. But we want to make sure that we can support them as well, and we're very intentional about how we make sure that we have capacity for startups.
And so what we do is we actually do allocate, and we basically say, okay, we're going to keep — you're right, we could sell every single GPU or AI accelerator we had to probably just the big frontier labs and call it a day. We choose not to do that because we actually want to keep growing the full ecosystem. They get a large number, but we want to keep supporting a broader set of customers because we actually think that both — the whole ecosystem will be more healthy for us. There's some diversification, but it's also just we know these are going to be big companies over time. And so we try to support them.
I saw recently that we say, you know, yes in some way, shape or form to something like 60% of the requests we eventually get. Sometimes it's a little bit later, sometimes it's in a different region, sometimes it's a slightly different configuration than the customers are looking for. But we really try to lean in and try to allocate as much as we can, and every single startup that you have wants more.
And so, you know, we're working hard to try to make sure that we have all of those. But, you know, it's hard. Like, that's — you know, like this is, as a lot of people say, it's a good problem to have. But it's a problem nonetheless. And we continue to look at — you know, we recently announced we're going to be buying, you know, 2 million NVIDIA GPUs over the next couple of years. Like, we're landing a massive amount of capacity.
2 million. So, you know, it's a lot, and it's over the next couple of years, but — and who knows if that's enough. But that's at some point again we're limited by other components as well. But it is — we're very intentional about keeping capacity available for the startups, and I know it's painful to not have enough, but we keep pushing.
And when did your capex cross — I mean, pure AWS. I mean, Amazon was a bigger company. Cross like, let's call it even 1 billion or 10 billion a year.
Oh, I don't know. I'd have to go back and look. I'm not sure about that. But it's definitely scaled up over the last couple of years in a pretty meaningful way.
The AI buildout has definitely ramped our capex spending. And so I'd say over the last, you know, call it three or four years, our capex has definitely accelerated pretty meaningfully. I don't know when we crossed a billion, but given we're 220 now, it's probably — I mean, we've been spending capex for a while, and the company has been really good about funding that, and obviously the AWS business is a good one that we like to invest in.
And, you know, I think we were for the longest time actually — we were investing ahead of where the demand was. And, you know, I think one of the most painful things is that with the real ramp of GPUs, like a lot of the elasticity has unfortunately kind of gone away. And so hopefully we'll get back to — in our core compute and storage and things, the elasticity is still there. But so we've been spending for quite a bit of time, and we feel really good about the spend that we're making now.
Which is, you know, I think I get lots of questions sometimes about how you feel about that spend and like, are you nervous about a bubble and other things like that. And I will say, you know, because of the position we have, like one, we do take this diversified approach, and so not all of our capacity is bundled up in one customer. And I think you go to some of these, whether they're neoclouds or some of the other providers out there, and you know, you'll see sometimes concentrations of 30, 40, 50, 60% with one or two customers.
We're nowhere near that. Obviously we're, you know, single-digit percentages at the highest, and usually it's less than that. So one, I think we have a lot less risk on one particular customer. But also because we have that rich set of services, like AWS is where people really are coming to launch their production workloads. And so the majority of our usage today actually is either core compute and storage and inference, which is part of that application. And so those are the workloads that I think just aren't going to go away, just because we see enterprises getting positive ROI.
You go talk to the customers and you say, at the capability today and the cost today, are you seeing positive returns to your business? And almost to a person they'll say like, oh yeah. And so you're like, well, that's not going to go away. There's no bubble in which they stop spending on that, you know.
And you know this, like the VC model — like, is every billion-dollar startup going to make it? No, they won't. But, you know, that's kind of the game, and it's been that way for 50 years. They haven't always been billion-dollar start — numbers have changed, but the principles are the same, right? You bet on 10 and one makes it and pays for the other 10 or whatever the percentage is. Hopefully it's higher than one. Right. And so that — there, you know, you saw that with the internet where there was a bubble and a bunch of internet companies didn't make it, and the internet's still a thing, and a lot of the companies that had durable businesses — the Googles, the Amazons, others like that — they did pretty well.
And so for us, we think we'll feel really good about that investment and the continued investment going.
You guys have a view of the demand that's unparalleled, right? Because you're seeing across the globe, you're seeing across every segment — enterprise and the big labs and the AI-native companies and so on and so forth. So if anybody should call it, you should be able to call it first.
That's our plan. And honestly, we spend a lot of time thinking about it. We're very intentional about how we spend, you know, our shareholder capital, and we think that we're making great investments. We have a lot of good protections of how we intentionally invest that money. But yeah, we're very bullish on — and, you know, I think Andy's been public about saying this — the potential for AWS is really, really large, and over the next decade the potential is there. And anytime you have an opportunity that's that big, like you kind of want to make — you want to invest to go after it.
And as the scale of these numbers go larger and larger, right? Has your planning and process dramatically changed in terms of — I mean, you're not writing billion-dollar checks, you're writing like $50 billion checks or $20 million checks or whatever it is.
Yeah. Yes and no. I mean, I think look, a lot of times we're still very bullish about the investments and lean forward, but there — the process. So there's a lot of things that have completely changed. Like, how do you even estimate 2028 demand? And there's things that we have to think about now that we just never had to think about.
And so if you go back 15 years, if we needed more power, we asked the power company to give us another, you know, couple of megawatts or whatever it was, right? Tens of megawatts, and they would just give it to us because 10 megawatts wasn't that much. And that was plenty for us to keep growing. Now we bring our own power. And so we pay for power projects, we pay for renewable projects. We're one of the biggest renewable power purchasers each year for the last 10 years. And so it's, you know, we're regularly bringing on new solar projects, new nuclear projects, new...
So you're talking about behind the meter, or are you talking about working with the operator?
We'll do both. And so both of those things. And so oftentimes with these power projects that we bring on, we'll pay the capital and pay for the project, and then it'll go into the grid, and then we'll get credit for that. So we'll bring those on. Sometimes we'll do behind the meter too. Like it's a mix at the scale that we're doing. You have to think about all of those things.
But, you know, that's planning where you're thinking, you know, 20 years out of how you're going to think about power, how you're going to think about transmission, how you're going to think about that capital. And that's stuff we'd never had to think about before. That's planning we just never had to do.
But, you know, we always had to — it's, you know, the other thing is when we used to think about server demand that we needed, we'd have, you know, multiple-quarter demand things and we'd talk with our suppliers and things. Now we work multiple years out just because the size is so much that we have to think about kind of what do we need for '26, what do we need for '27, what do we need for '28.
And so that's — but, you know, but it's also one of the value that we bring to customers, right? That's a thing that legitimately customers can't do themselves. Like they're not going to do power. They're not going to plan their memory footprint in 2028. Like they just can't do that. And so that's one of the real values that we bring to our broad set of customers is just that's a whole set of things that you don't have to worry about and that we spend a huge amount of time thinking about.
Yeah. You guys are generally, I think for the record, the largest buyers of practically every component of a server. Correct?
I don't know that. I don't... I am sure that we're one of the bigger purchasers of components out there for sure. And who knows about everyone, but it kind of depends on how you think about them and how you measure, but...
So where I was leading to — where do you see the constraints being most severe, let's call it '27, '28, and where do you see the constraints easing up?
Yeah, it's funny. It's — so I'll answer this in a roundabout way, but, you know, I remember that in undergrad we...
Actually, this was a long time ago, and I never thought this would be a useful book that I read, but we read The Goal and have read The Goal, right? And so it turns out there's never one constraint; there's always just the latest constraint. And so you have to think about all of them, and as soon as you hit one, there's another one, right? And so, you know, what is the constraint that's going to happen in 2028? Like, I actually don't think there will be one. I think it's like every month for us, it's, do you have enough power? And then as soon as power is no longer the constraint, you know, it might be memory, it might be TSMC capacity, it might be, you know, HBM, it might be networking components, it could be, you know, there's a blip somewhere in the supply chain, like connectors or whatever it is, right? At some point, you have to think about all of those pieces.
And it's, you know, it's not also the kind of where they happen matters too, you know. So it may be like, hey, we have a ton of power in Indonesia, but we don't have enough in Germany, right? And so you think about kind of where in the world you want that capacity too, because it turns out that not everything is totally fungible. Some is and some's not. But it might be disk drives, it might be SSDs, it might be... we think about every single component, and we have, you know, tens, hundreds of thousands of components all that we track and think about, and some we rely on our suppliers to manage, some we directly manage. And yeah, we have a whole team that does that, and they're fantastic. I think they're industry-leading, and we kind of saw this problem coming probably a decade ago, and really started not just thinking about, okay, how many servers do we need to track, but just thinking all the way through the supply chain, you know, four tiers, five tiers down, what is the component that could cause an issue for us, and making sure that we had kind of guaranteed supply on that.
If you think, if you remember, I don't remember when this was, over a decade ago when there was like the floods in Thailand and no one had disk drives anymore. And so that was...
