Amazon CEO Jassy: AWS's AI business has an annualized revenue of over $25 billion, and $220 billion in capital expenditure for 2026 is still not enough

Recently, Amazon CEO Andy Jassy appeared on the podcast of the well-known venture capital firm a16z for an in-depth conversation with a16z co-founder Ben Horowitz. In this interview, Jassy comprehensively revealed Amazon's strategic panorama amid the generative AI wave.

Faced with Wall Street's concerns over the tech giants' bottomless capital expenditures, Jassy gave the most direct market feedback: demand has not only not slowed, but is rapidly outstripping future capacity. At the same time, he broke down in detail the current "barbell-shaped" demand structure of the AI market, and made clear that to truly unlock enterprise-grade AI applications, inference compute costs must fall by another order of magnitude.

"Even after spending $220 billion, we are still leaving a great deal of demand on the table"

The core issue the market is most focused on right now is whether the giants' capital expenditures, often in the hundreds of billions, will turn into excess sunk costs. Jassy responded directly to market doubts with a set of striking order data.

"Even if we spend $220 billion this year, we are still leaving a great deal of meaningful demand on the table." Jassy pointed bluntly in the interview to the current extreme shortage of compute supply: "We always reserve a certain percentage of capacity for on-demand service, but 2026 capacity is clearly already sold out, 2027 is basically sold out, and even a large portion of 2028 has already been sold."

In terms of business growth, the growth curve brought by AI is extremely steep. Jassy compared AWS's early days with its current pace of development: "In the first three years of AWS, we thought we were growing fast, with an annualized revenue run rate of about $60 million at the time. But in the first three years of this generative AI wave, our AI business at AWS has already surpassed $25 billion in annualized revenue run rate. It is hundreds of times faster than back then, and we have never seen anything like it."

Addressing capital market concerns, Jassy explained the cash flow cycle logic of data center investment. He said investment in data center buildings needs to be made two years in advance, but their useful life is as long as 30 years; while servers and networking equipment only need to be purchased a few months ahead. This means the company has very clear visibility into customer demand. "If you find that you actually don't need to fill those data centers, you won't buy servers and networking equipment. Most server agreements are five-year terms, and typically break even in three years. Because of this cash cycle, when you are growing at such a rapid pace, early free cash flow does face headwinds, but once everything is online, the returns will be very substantial."

Rebuking data center controversy: "A golf course uses in two days the water we use in a year"

In the United States, the energy consumption and environmental issues of data centers are turning into a political controversy. Jassy pushed back forcefully and elevated it to the macro level of national competitiveness.

"The infrastructure buildout we are undergoing is comparable in scale to the U.S. building highways and bridges in the 1950s. The country and indeed the whole world cannot afford the cost of not building data centers, otherwise we will find that countries like China will establish all the leadership and standards, which is unacceptable to us both domestically and globally."

On environmental accusations, Jassy offered highly impactful data facts: "There are a lot of claims spreading now that sit somewhere between myth and lie, because politicians and speculators like to find a simple 'villain.' In fact, golf courses or almond farming consume far more water than data centers. As one data point: golf courses consume 200 times the water we do; they use more water in two days than our data centers use in a year."

He also added that pollution from backup generators has been seriously exaggerated: "You have to register and report emissions as if running at full load around the clock, but in reality we only run backup generators 0.1% of the time each year (about 10 hours) for maintenance."

"One end of the barbell is AI labs, which are consuming the massive compute I have ever seen; the other end is enterprises, mainly using AI to reduce costs and improve productivity, such as automating customer service or business processes. And in the middle of the barbell is enterprises' current production workloads. The vast majority of enterprises have not yet popularized (AI inference), but I think in five to seven years, almost all existing enterprise applications will deeply use inference technology."

However, to activate the huge market "in the middle of the barbell," price is the biggest stumbling block.

"Over the past few years, inference costs have come down a lot, but in my view, it is still an order of magnitude too expensive." Jassy stressed, "If you ask enterprises to rewrite their existing CPU applications with AI accelerators, and the cost difference is huge, the threshold for them to rewrite will be very high. But if you can bring inference costs down, the threshold will drop substantially. That is why we are pushing hard in our custom chip business."

Jassy spoke highly of the 2015 acquisition of chip design company Annapurna Labs, calling it "the most successful acquisition in Amazon's history, perhaps without exception." He revealed that through its custom Graviton processors (40% better price-performance than other x86) and Trainium AI accelerators (30-40% better price-performance), Amazon is forcibly driving down compute costs.

Organizational reshaping: 6 engineers did a year's work of 40 people, and all products must be rebuilt from the ground up

Jassy shared a shocking internal case: the Bedrock (Amazon's AI inference service platform) team rebuilt the inference engine with just 6 engineers in 76 days, whereas in the past this would have required 40 people working for a full year.

"This opened everyone's eyes," Jassy said bluntly. "In the future, the same work will require fewer humans than today. I'm not saying people aren't needed, but as the business scales, we won't invest as much manpower as in the past. Teams will get smaller, and people will need to work cross-functionally, because models can help you complete 80% of the work."

At the product level, Jassy believes incremental improvement is no longer viable, and that one must have the courage to "rebuild from scratch."

"For a product like Alexa, its 'brain' was very innovative when it was developed, but because of the emergence of generative AI, the boundaries of what's possible are completely different. If you want to have a winning customer experience, you must rewire Alexa's brain."

Not just Alexa—Jassy pointed out that all of Amazon's core consumer experiences, including retail, Prime Video, and music, must be thoroughly reimagined with AI in the coming years. "Teams often resist out of pride and historical baggage, saying 'we tried that, it didn't work.' But this (rebuilding) is necessary pain; if you only think about incremental improvement, you'll be eliminated in three to five years."

The following is a full translation of the podcast:

Andy Jassy 00:00

Even with $220 billion in capital expenditure this year, we are still leaving a considerable portion of demand on the table. We always keep some capacity for on-demand use, but 2026 is clearly sold out, 2027 is basically sold out, and a substantial portion of 2028 is also sold out.

Andy Jassy 00:14

The financial markets are saying, oh, there isn't that much money in the world to finance these things. But everything we do in the world today—stock markets, banks, healthcare—they all use data centers. Our job is to figure out how to have as much capacity as possible; we have this opportunity to reach far more customer experiences and make their lives better and easier every day. Those large labs are willing to pay almost any price for power, cooling, and chips. Hmm, maybe we should buy out old customers and sell to new ones, because they'll pay whatever we ask.

a16z 00:48

Andy, welcome to the show. Great to have you. Thanks for having me. So, you've been running Amazon for five years and done a lot. Just being here is not easy, and as CEO there are many things in motion—you now have $220 billion in capital expenditure, AWS growing 20%, 28%. Hmm, hmm, you've really done a lot.

Andy Jassy 01:09

You've achieved so much, so how do you view Amazon's ambitions for 2026—relative to when you officially took over as CEO in 2021? Oh, 2021 feels like a long time ago, feels like, you know, ten years ago. But, you know, the world changes so fast. And, you know, it's just...

Andy Jassy 01:30

If you compare with 2021, our overall revenue is about 80% higher, the AWS business is nearly three times as large, and advertising revenue is about two and a half times. So this business, you know, has grown quite a lot.

Andy Jassy 01:47

I think a few things did happen. Shortly after I took over—right at the tail end of the pandemic—our retail business ran into a real fulfillment cost problem: we basically doubled the size of our fulfillment network. We built a network in 25 years and doubled it in about 18 months; then, in about 20 months, we built a last-mile delivery and transportation network the size of UPS. And when you build that fast, you're bound to leave all sorts of things unoptimized. Our fulfillment costs in the fulfillment network were not what we wanted them to be. Um, you know, that created a lot of challenges and a lot of anxiety at the time. I remember about a year, less than a year into the job, everyone was saying: oh man, what a terrible time to take over, what bad luck. But looking back now, I think it was actually a very good time to start, really a blessing—because it forced us to think about a whole bunch of things we probably wouldn't have thought about for years, and those things were great ideas for our customers and for our business. The biggest one was our fulfillment network: we regionalized what had been a flat national fulfillment network in the U.S. Through regionalization, we put products much closer to customers, and as a result we not only lowered fulfillment costs because shipping distances were shorter, but we also got products to customers much faster. Um. In that period when we were struggling with fulfillment costs, reexamining our most deeply held beliefs really unlocked delivery speed and a lot of demand in the retail business, and it was a big reason we were able to grow so fast there. And then, of course, you know, right after that came how AI further set everything on fire. It's not that AI is anything new—we've all been doing machine learning for a long time, and there had been several waves of AI that were seen as "the real turning point." But when you get to 2023, you really see the enormous difference that generative AI makes. What I'd say is that at the time our AWS business was already growing very fast. We had, you know, clearly the broadest set of capabilities, stronger operational performance and security, and I think a different kind of partner ecosystem. We were the clear leader, and at the time we thought this business could, over a long period—let's say ten-plus years—reach hundreds of billions of dollars in revenue. Now, looking at everything happening with AI, and at how every customer experience we know of will be reinvented because of inference and AI, we actually believe the AWS business is not only growing very fast—last quarter we grew 36.7% year over year, and that's on a $169 billion annualized revenue base—but the opportunity in front of us today is truly remarkable. And you know, I think if you layer on top of that, we have the seeds of those new businesses: whether it's what the team has made of Prime Video—it's now a very large and profitable business; or the low Earth orbit satellites we're building with Amazon Leo; or the autonomous ride-hailing service with Zoox; and also the health business, and what we're doing in robotics. You know, we really have an opportunity to help far more customers, cover far more customer experiences, and make their lives better and easier every day. And that mission—working to make customers' lives better and easier every day—really unifies what we do across the company. So I have a few follow-ups on that. First, you just mentioned that when you expand the fulfillment network so fast, it's bound to be a bit inefficient. You know, when you move that fast, there are bound to be rough edges. So how do you—and you also mentioned there was some anxiety internally about this—from a CEO's perspective, how do you communicate what you're doing without lowering the cultural bar? I mean, Amazon is known for excellence, for operational efficiency, for frugality, all of those things. But now you're saying: we're going to build a UPS-like thing, and so on. So how do you reconcile the two? Um, the interesting thing is that we have this set of leadership principles that many people know about, 16 of them. Many of the principles are supposed to, and do, govern how we think about operations and culture as a team. But several of them are in tension with each other, and sometimes people get confused by that. But the reality is that this actually reflects how the real world works—nothing is ever truly clean and neat, and you're always making trade-offs. So going back to that moment, when we decided to expand the fulfillment network and the last-mile delivery and transportation network at such an aggressive, fast pace, the question the team faced was: we know that if we move this fast, it will be very hard; costs will likely be higher than if we did it more slowly; and we probably won't be able to optimize everything the way we would if we did it more slowly. But customers and sellers really needed it. So should we lean toward "get it built first"? Remember, that was early in the pandemic, and all the physical stores were closed. I mean, if you look at the role Amazon played in everyone's lives during the pandemic, it was truly groundbreaking. So we had to ask ourselves: are we going to build fast, maybe not as optimized, in exchange for serving those customers and sellers—sellers who at the time were also trying to keep their businesses alive? That's the first decision you have to make. And we decided, as we almost always do, to lean toward the customer. You know, and then, as we built, it quickly became obvious—not everything we planned went perfectly. We had, you know, our fulfillment team was in the office more than most other parts of the company. But even so, there were still a huge number of people who needed to be involved in a huge amount of design, planning, and evaluation. People were scattered everywhere, working remotely, and then you have to balance the combination or tension between "bias for action," or speed, and "insist on the highest standards"—the latter meaning you deliver at the cost structure, delivery approach, and design you'd normally plan for. So you have to make trade-offs again. Our trade-off was to stand on the customer's side and move fast, so we could serve sellers and consumers well, and we knew at the time there would be a certain amount of cleanup work later. So did we know exactly that it would turn out the way it did? No. There were also things we didn't optimize well, and I'm not sure we foresaw that they wouldn't be optimized. But if you have good metrics, and if your culture is a truth-telling culture—which is another very important part of our culture—we, you know, put the data on the table, put the problems on the table, communicate directly with each other, and we don't let people gloss over problems. If you have that kind of culture, it will be pretty obvious in the metrics and pretty obvious in the discussions. Then you just have to figure out how to improve it, and distinguish which are just small efficiency issues and which are architectural issues. After we got that capacity installed, we went back and really re-architected key parts of the network—that was probably number eight or nine on that team's priority list at the time, but it became a much more important priority because it could really deliver the combination of speed and cost. Yeah, interesting. You know, it's a bit like the very beginning, when you started AWS—you started AWS, and the playbook at the time was a bit like "build it and they will come," right? You're building this whole infrastructure, and then you operate it. So they have to come, otherwise you're in big trouble. But now this is playing out at a much larger scale: you and some other companies—though I have to say, mainly you, at least you're certainly one of the biggest players—are building data centers and chip capacity so fast that the financial markets are starting to say: oh boy, there isn't enough money in the world to finance all this. And then, we saw that kind of tension recently in CoreWeave's debt market and equity market and so on. So how do you judge—given demand is so steep and you're growing so fast—how much is too much in this buildout? And there's also competition across the supply chain; you have to fight for your cooling, power, chips, all of it. Yeah, that's a really good question. I really wish there were a formula that made it simple; that would save our team a ton of time. Well, I guess I'd say this: in the first wave of cloud, when we started AWS, there was indeed a bit of a "we don't know if people will use it, so build it and they will come" flavor. But we had good signals inside the company. At the time, you know, around the early 2000s, we had quite a few teams moving far slower than we expected—even though relatively speaking we already felt we were fast enough. But we just couldn't figure out why it took so long. The reason was actually that our product teams were spending 70% to 80% of their time on the infrastructure part of the work, and that part didn't let them differentiate; only about 20% of the time went to the part that actually made the product different. So we, you know, realized every team was doing this repeatedly and reinventing the wheel. So we originally conceived AWS so that we ourselves could move faster internally. Our judgment at the time was: if we build a set of large-scale, highly available, low-cost, highly flexible primitive services—like compute, storage, database, content delivery, messaging, and so on—we can build much faster in the consumer business. And then we just said, we're relatively good at technology, and other companies probably have the same problem. But even before we launched externally, so many teams inside the company were interested that we knew we were onto something. I don't think any of us expected it to grow that fast externally. On the AI side, you know, as you know, there had been wave after wave of people saying: this is it, AI is finally here. Even about six or seven years before the generative AI wave, people felt that was the era of AI. We built a bunch of AI services, and on the AWS side it was actually a pretty good business. But it's nothing compared to what we're seeing now. In AWS's early days, we, we felt we were already growing very fast, and we felt good about it—three years in, we hit about $60 million in annualized revenue. And in the first three years of the generative AI wave, our AI business within AWS alone exceeded $25 billion in annualized revenue. So it's hundreds of times faster. This—we've truly never seen anything like this. So the question becomes: how much capital expenditure do you want to put in to chase this opportunity? What I can tell you is that we've said we expect to spend about $220 billion in capital expenditure in 2026. By the way, I remember about 15 years ago at a leadership team breakfast, we couldn't believe a telecom company would spend $50 billion on capital expenditure, and we said: how can they spend so much money on capital expenditure? So these numbers, you know, are truly mind-numbing numbers. And even with $220 billion in capital expenditure this year, we're still leaving a considerable portion of demand on the table. What really helps us here is that we have good visibility into customer demand. So if you look at AWS's capital expenditure investments and how the cash cycle works, there are two major pieces: one is data center investment, and the other is server and networking investment. For the data center piece, you have to, you know, invest about two years in advance before you can put servers in the data center and start monetizing. The good news is you only have to make this investment once; it's a long-lived asset, about 30 years. But you have to make this investment several years in advance. Servers and networking equipment only require a few months of lead time, depending on the specific component. So before you actually pull the trigger, you have good visibility into customer demand. If it turns out you don't actually need that capacity to fill these data centers, you won't buy the servers and networking equipment. On average, they, you know, pay back in about three years, and currently their useful life is about five to six years. Most of the deals we do are around five years. So when you're building so many data centers at once and so quickly like we are, you spend a lot of capital, and your free cash flow takes a headwind in those years—until a few years later when you reach that later stage: all these data centers are online, monetizing, and you're earning back the money from your server and networking investments. But because of how the cash cycle works, in the first few years when you're growing this fast, it does create a headwind. So along those lines, you know, going back to when you founded AWS, a data center was probably the last thing in the world you'd believe would become a political issue. Yet here we are, especially in the United States. You know, it's quite interesting—I'm sure you've experienced this too—nowhere in the world are people more anti-data-center than in American political circles, for whatever reason. So you, you know, how does this ultimately affect this? What I want to ask is, is there any merit to the anti-data-center arguments? And then, how does that in turn affect your strategy—what you build here versus what you build in other regions? Well, okay, I can give you some context that I have, or at least that I believe. Think about it: everything we do in the world today—stock markets, banking, healthcare, entertainment, shopping, education, commerce, ride-hailing—everything we do is digitally driven, and they all use data centers. It's really that simple. No, everyone is; I'm against myself, I don't want to use my phone anymore. But they all use data centers. And this is even before AI. AI is the biggest technological transformation of our time—and that's saying something given that we've been through the internet, the cloud, and mobile internet. So the reality is that to support the kind of high-speed growth on the AI side that we just talked about, the kind of infrastructure buildout we need has probably not been seen in this world, in this country, since we built highways and bridges in the 1950s. I mean, what we're going through right now is construction on that scale. And this country—I think the whole world broadly, but I'll specifically say the United States—cannot afford not to build data centers, or we'll find that another country like China will establish all the leadership and all the rules there. I think none of us would like that, whether domestically or globally. So we have to build data centers now. Now, do I think that as an industry we can do better than we currently are? Of course. I think things are moving very fast and everyone is learning together. But right now there's a set of—I'd call it somewhere between myths and untruths—being spread, because this is the kind of issue where everyone can find a ready-made villain. In politics, sometimes opportunists like to identify that villain and point fingers. I can give you some examples. The golf industry or the almond farming industry consumes far more water than data centers. Just to give one data point: facilities like golf courses use 200 times more water than all our data centers; they use more water in two days than our data centers use in a year. So there are many such examples, and this is a good one. Or you can talk about pollution. The reality is that when you register a new site and install backup generators, you have to register and report: what would the emissions be if you ran all these generators at full load, around the clock. But of course, that never happens. Backup generators run only one-thousandth of the time per year, say 10 hours a year for maintenance. So, you know, or you talk about electricity prices—if you look at different regions where we have large-scale data center footprints, in some places electricity prices have gone up, and in some places they've gone down. But the real issue is this: as a country, we haven't invested in our grid infrastructure the way we should. There's bound to be substantial growth here, so something was always going to push it to the tipping point where investment becomes necessary. And it turned out to be AI—because it's growing so fast and is so large—that became the thing that pushed it over. But once you actually build the capacity, you'll find that in most regions, electricity prices will eventually flatten or even decline, as has happened in Indiana, Georgia, or Mississippi. So there are things we can do better. Another thing people tend to forget: in these regions, large data center providers pay a lot of taxes. Take St. Joseph County, Indiana, for example—we've already paid about $3 billion in taxes. The community gets that money and can spend it on the things that really matter to those communities. So the community gets a return too. We've built programs like Built Together, and we've just committed another $1 billion over the next five years to the communities where we have data centers. So I think we have to keep working on this together with communities. It has to be a public-private partnership. But this buildout is too important to this country's future—imagine if we hadn't built the interstate highways.

a16z 20:44

And the bridges—that would determine this country's economic prosperity and the limits of its capabilities. So we need to put it in a reasonable perspective, and we have to be a partner to the communities we build in. Let's go back to the capex question. That $220 billion, which is $600 million a day. I just want to, you know, put it in a frame of reference. I'm curious how you see AI demand right now—when we talked privately, you described it as a...

Andy Jassy 21:10

Barbell structure. Maybe you could walk through, or frame, the current state of AI demand. Yeah, I'd say the first piece of context is what I said earlier—I can hardly believe how big and how fast AI has grown. You know, it's hundreds of times faster than AWS's early days; in the first three years, we did $25 billion in annualized AI revenue alone in AWS. So it really is very large. But at the same time, if you look at the structure of demand, it really is a barbell. On one end of the barbell are the AI labs, which are consuming massive, massive amounts of compute, at a scale I've never seen. And then there are a handful of hit applications, ChatGPT, Claude Code, and the like.

Andy Jassy 21:59

On the other end of the barbell are enterprises, which are mainly using AI for cost avoidance and efficiency gains, like automating customer service, fraud prevention, or business process automation. In the middle of the barbell are enterprises' current production workloads, many of which run on AWS and are already using inference today. But I'd say the vast majority of them haven't yet adopted it in any pervasive way—you know, and I think that will become the largest absolute chunk of AI usage. I think you'll see that.

Andy Jassy 22:38

It's hard for me to predict how fast that will happen. It, you know, happens to a greater extent every year. But I think if you zoom out—five years, five to seven years—and look at what that will look like; and I don't think it will wait five to seven years to happen, it never happens all at once. But if you can zoom out five to seven years, I think a substantial number, maybe most, of the enterprise applications we use and that exist today will use inference in a pervasive way. So there's a lot of growth ahead of us. So how do you think about this? Because we're facing an impending shortage of data centers, chips, memory—everything—and really in 2027, because everyone is building now, but it may not be ready by the end of this year, and demand isn't slowing down at all. So how do you think about this—when those large labs are willing to pay perhaps any price, almost any price, for power, cooling, chips; that environment; and you have these long-standing customers who are paying standard rates to run their businesses. Is there a business pressure that makes you think: hmm, maybe we should buy out the old customers and sell to the new ones, because they'll pay whatever we ask? And the old customers—I can't just double their prices, that wouldn't be fair. Or, how do you think about this? Because it's really strange—you have a group of people who've been with you for 20 years, doing something that, as you said, will probably move toward inference; and then you have these new customers who are insatiable and willing to buy anything.

Andy Jassy 24:35

Yes, it's a good question. You know, the way we look at this is a little different from what you're describing, but I completely understand it. If you think about it, there's only so much data center and power today, only so much memory, and I don't think that shortage ends in 2027. I think, I believe—going back to the capital investment topic, one of the reasons I feel we can invest much more and that it wouldn't be bad capital use is: 2026 is clearly sold out at this point, and 2027 is basically sold out. We always keep some for on-demand use, whether in our inference service Bedrock or in EC2—but it's basically all sold out, all the big blocks are sold out. A substantial portion of 2028 is already sold out too. That's how big the demand is, you can't... we have, if you look at the AI business and what we call our core business—core can be understood as the non-AI part—they're both growing at a very fast rate right now. And you know, if you only have so much memory on hand, you have to decide how much memory to allocate to HBM, that is, to AI accelerators, and how much to DRAM, that is, to your core business. So these are real trade-offs you have to make. But what I'd say is that our starting point on this is customer obsession. For us, we have deep relationships and partnerships with customers in AWS. Like during the pandemic—when our competitors, I think, were thinking about how to optimize within a quarter to push revenue as high as possible in a world where everyone had to do cost optimization; and we took a different approach. We proactively sent our teams out to help customers figure out how to optimize costs, even though we knew it would weaken our short- and medium-term revenue. But you know, we want to help customers succeed, because we strongly believe: if we help customers over the long term, our business will follow. The same logic applies to the core business. I guess you could indeed do some math and conclude that, because of scarcity and customers' willingness to pay, you could squeeze more money out of core customers. But they run their businesses on top of AWS, all their core applications run on it. We won't squeeze our customers; we'll make sure they can scale. And then our job is to figure out how to have as much capacity as possible, so that not only our core customers, but also all the customers who want to use AI with us, and those who want to use us to do AI, can get access, and in a way that is economically sustainable for us. So, I really wish I could tell you that tight supply will only be a 2027 problem; I think we'll see it for several years running, across different components. We've been aggressive, and I think we're probably putting more capacity in place than anyone, because we're really committed and very focused on continuing to be an important leader in infrastructure and AI, as we always have been. But as I said, we're going to spend $220 billion this year, and we could have spent much more. That wouldn't be bad capital use. And over the medium to long term, I think we probably still won't be able to meet all the demand. The demand right now is just staggering. So following on from that, you did something in 2015—you acquired Annapurna Labs. At that time you probably weren't thinking there would be huge AI demand in 2015, because there wasn't much AI demand in 2015. So what drove the decision to make that acquisition? And then how has it paid off in this new world? Yeah, I think the Annapurna team is one of the most talented teams and groups of people I've had the privilege to work with, and it's one of the best acquisitions we've made in Amazon's history, if not the best. Yeah, we anticipated some of it, but I don't think we acquired Annapurna specifically for AI chips. Here's how it was: when you reach a certain scale, you get exposure to and see patterns of customer behavior at massive scale, and you realize that if you can do vertical integration and build certain capabilities yourself, you can deliver more value to customers and also bring better economics to the business itself. So Annapurna's starting point with us was just around the core EC2 servers: we felt we were spending too many server resources on virtualization, networking, security, and storage, and we wanted to be able to use almost 100% of server resources to deliver compute to customers. So before we acquired them, we were already working with Annapurna on this network card (NIC)—offloading these components to the NIC so we could leave as much of the server as possible for compute. We really liked the team, and we really liked the product we built together. We realized that the thing we were going to buy would eventually go into almost every EC2 server—and it did end up in all of our servers. So we initially acquired it because that would become a core capability of our compute; and because the team was so talented at building chips, we thought they could probably build other chips too. At that time, we had a very deep partnership with Intel—and we still maintain a deep partnership with the company today. But the problem was that Intel at the time held nearly all of the CPU share; and when you have a partner that holds nearly all the share, they often don't think about how to improve price-performance—they think about other features that can win them more share and bring in more revenue. And by the way, that's completely understandable; it's part of the dynamics of how markets work, and part of why the "innovator's dilemma" happens. So we wanted to push on price-performance at the time, but it was hard to get their attention. But we had customers who wanted to move more and more on-premises workloads to the cloud, and they wanted better price-performance. So the next thing we had the Annapurna team do was build a CPU chip. They built Graviton—and today, 99% of our top thousand EC2 customers are using it very extensively. Its price-performance is about 40% better than other x86 processors, and that has had a huge impact on our customers and on our business. Then, a few years ago, we saw the same "movie" play out again in AI: there really was a very strong dominant supplier there. We have a deep partnership with them—we still have a deep partnership, and will for the foreseeable future. But they have a huge market, and many different products and different priorities they're working on. And we knew our customers needed better price-performance, which is why we started another team within Annapurna to build an AI accelerator, which we call Trainium, and its price-performance is also about 30% to 40% better than comparable processors. And you know, when we talk about the middle of the barbell—the part we were just discussing—if you ask: what are the things that would change the middle of the barbell and get more of today's enterprise production applications to use inference? There are a few things. Part of it is talent: some people are already used to doing post-training and fine-tuning, and you also need the kind of organizational capability that knows how to prioritize, knows what to attack, and knows how to do it. But a big part is this: inference costs have come down a lot over the past few years, but in my view they're still an order of magnitude too expensive—not yet cheap enough for it to be used as widely as possible. Because if you want enterprises to rewrite the applications they run on CPUs today to run on AI accelerators, and the cost difference between the two is very significant, then for them to be willing to rewrite those applications, they have to get very high incremental returns from the AI accelerators—that's a much higher bar. But if you can bring inference costs down, that bar is much lower, and every application becomes better, smarter, and more powerful because of AI accelerators and inference. So for customers to be able to use AI widely, a very critical piece is bringing inference costs down, and our chip business is a big part of that. Yes, absolutely. I can tell you from our own company—it really does get very expensive. We had one employee who spent $2 million over the past few years—doing valuable work. But yes, the feeling at the time was: okay, this inference thing really isn't cheap. Now, one of the things you've done is make some investments, particularly in Anthropic and OpenAI—very large investments. I believe it was $18 billion for Anthropic and something like $50 billion for OpenAI. So what made you want to do these? And these kinds of investments, along with similar ones from Nvidia and others, have made Wall Street a bit nervous, because they remind people of the bad old days of the dot-com bubble. How do you think about this—especially given that they're also your customers? Why does it make sense to do this? Both companies are outstanding teams and outstanding companies; the rate at which they're growing their business—at least on the revenue side—I don't know if we've ever seen anything like it. Really, it's incredible. So for us, it's a combination of factors: what kind of teams these are, the technology and models they've built, and some of the applications they've created; how transformative we believe AI will be; and our belief that they will be two of the most successful companies in this space for a long time—of course not everyone in this space will be a winner, but many very successful companies will emerge, and we believe they'll be two of them. And then, we work so closely together. Let me start with Anthropic—we've partnered with them longer. We have a huge number of customers running Anthropic in our inference service, Bedrock. And I think customers running Anthropic in Bedrock is the most successful. We work deeply with them on chips—they've been building on Trainium for a while. I think that's been very good for Anthropic and very good for our Trainium team, and I think both sides have learned a lot from each other. So we have a deep partnership with them—whether it's our belief in the future of AI, our belief in these companies, or the partnership itself, all of it makes us feel that investing as part of the partnership makes sense. And then on the OpenAI side, we simply had too many customers who wanted to use OpenAI on AWS but couldn't because of the prior commercial arrangement. And for a long time, I believed that both companies had a great deal of respect and willingness to cooperate with each other. So that was also the kind of situation where, after a series of conversations over several months—being able to run OpenAI in Bedrock; we built a unique product together, that stateful runtime environment, and I think all agents in the future will be built this way—you'll need state; and they, like Anthropic, made multi-year, multi-gigawatt commitments to Trainium. And we just believe it will be one of the most successful companies in this space for a long time. All of that made us feel that deepening the partnership and the investment was justified. Changing topics, let's talk about how you use AI to build a company. I remember you said the Bedrock team rebuilt your inference engine with 6 engineers in 76 days, and that would have taken 40 people a year. That's quite a difference. And you know, Amazon is known for "two-pizza teams." So now, what's your approach to organizational design? Considering this technology—it really seems to have changed everything. Over the years we became extremely specialized: there are designers, product managers, front-end engineers, back-end engineers, this and that, and so on. And now it seems everyone has become a generalist again. So from an organizational design perspective, how do you see this? Yes, I agree with what you said. I think that Bedrock experience you mentioned was very eye-opening for everyone here. We've also spent a lot of time sharing that story internally, to inspire people and remind them what's possible. Because over time, this is eventually what happens—I joined the company 29 years ago. I started as an assistant product manager, and at the time I was solely responsible for, I don't know, five products. And today, as the company succeeds and gets bigger and products get bigger, you reach a state where a product manager does just one product, and only owns one slice of it—for example, they only handle pricing or something. Everyone has become more specialized, and everyone accepts that if you want to go big and succeed, this is the necessary way to do things. But it isn't, and when you look at everything happening with AI, it definitely isn't. Take just this past week: we're doing some things around agents in our consumer business. We have a lot of investment there, but we had an idea we really liked, and on Thursday we decided to try it and see if we could build a truly working prototype. And what happened? Four or five of us worked on it over the weekend, and by Sunday we already had it running at 80% ready to ship. It's true—those are two completely different worlds. So I think what this means for the future of organizations is: first, I think there will be fewer humans doing today's work in the future. Just look at how much coding is now done by agents, how much customer service, business intelligence, and research work is being done. Yes, and fast-forward: how spreadsheets will be made, how many lawyers you'll need—I just think you won't go to zero people, but you won't need as many humans as before; in the past, as the business grew, we all kept piling on people, and that won't be the case in the future. Different jobs and new jobs will emerge, some we know and some we don't yet. As AI, robotics, and space develop, they will emerge. There will be all kinds of new jobs, but there will be fewer humans doing today's work. I think teams will be much smaller than they are now. You'll have smaller teams, and the people on those teams will be able to work cross-functionally; you won't just have one person owning one tiny slice, because models can get you to 80%. Across many of these different functions, I think every team will start from a much higher baseline than before, so I think you'll be able to invent more broadly and more quickly. I do think a great many things have to change. Most startups founded today start out agent-native or AI-native from the very beginning. And all the established companies that have been operating for a while must figure out how to build at the same speed. I think some of them will figure it out. And you always have this situation: when you have a big business with a lot of capabilities and a loyal customer base, some companies will figure it out very slowly, and in my view they'll be more vulnerable when facing startups. And I think, my prediction is, companies will have to rewrite almost all their code to make it agent-capable; they'll have to allow agents to update different pieces of code, and you'll have to establish constraints there. I think security alone is interesting. If you look at the various tensions around models over the past month or two, they're all focused on the more fantastical scenarios. By the way, those scenarios are possible: is it possible for a malicious botnet to take over everything? I mean, I suppose it's possible; is it possible to inject malicious intent into robots? All possible. Personally, I think, as an industry, together with the public and private sectors, we'll solve this together. But you have to start by focusing on certain things. Yes, but the interesting part is that I think there hasn't been enough discussion about the nearer-term risks—those risks are really mainly around cybersecurity. These models are so powerful that they can find far more vulnerabilities than humans ever did in the past. You could maybe argue about whether humans could have found them, but the fact is they didn't. So fast-forward, I think the way applications respond to urgent security threats has to be measured in minutes. Today it's like this: you find a vulnerability, someone classifies it, someone develops a patch; and then even if that part is done quickly, it takes most companies a long time to deploy, because of all the dependencies. In the future you'll have to complete deployment in minutes. So if you haven't truly rewritten your applications into a form that agents can update, you'll have no chance in that new world. So I think every organization will be reinvented, and the companies that prioritize this will be in a far better position than those that don't. Yes, and it seems that, as an industry, when we architect everything—from large systems to embedded devices—we haven't done a good job of security architecture. And the day of reckoning has arrived. But I think the good news is that this is a huge opportunity for new companies, new attempts, and people building things. But yes, as we said, this threat—the theoretical, thought-experiment-style threats, well, maybe they'll happen, maybe not. But this one is clear and real. Yes, almost all the partners and customers we talk about on the AWS side, regardless of size, every company is worried about security. You know, we have a professional services business helping customers with this, and we've also built a service called Continuum that can identify a large number of these vulnerabilities and generate patches. But this, you know, is easier said than done. In fact, because many companies and many engineers sometimes feel that focusing on security isn't that exciting, it's easy to just wait until something goes wrong. But if you're protecting important data, that's a bad idea. And I think in most companies—going back to our earlier conversation—specialization is probably the worst case in security: you have these very esoteric security engineers who don't like working with other engineers, they're a scarce resource, and so on. As a result, in most companies, most software companies, their security practices when writing software just aren't very good. I think that clearly has to change. The good news is we have tools that can help solve this problem. Following on what you said, the good news is: you have to hire penetration testers, but you can only hire so many security people, and they can only cover so many applications. Models plus automation will let you do a better job of penetration testing across the entire attack surface, and you'll find things you might not have found if you hadn't been lucky. So one thing that's interesting when we look at this market: with AI you can do a lot of things. One is you use it to cut costs, reduce the number of accountants or lawyers you need, and so on. There are indeed quite a few venture capital firms now saying: okay, let's go buy those old companies and cut their costs. That has never been that interesting to us, because we'd think: okay, if that's your idea, then your idea is too small. Another is: okay, we're going to build something the world has never seen. That's very exciting. But there's a third, which is what you did with Alexa: you have a product—a successful product—and you say, okay, let's rethink this whole thing from scratch, because we have this new platform. How did you get to that point? Under what circumstances does it make sense? Yes, I think you've drawn an interesting three-part distinction. And I think, as we just discussed, organizations will really change and become leaner. If you do it right, it will let your truly great builders and these small teams produce the second category you mentioned—things people have never seen—and you can do it. And when you have the kind of experience I described earlier—getting a new idea to 80% within four days—it's so motivating for people that they'll really spend more of their spare time and more of their idle thinking cycles on new ideas. For me, that's one of the most exciting parts of what's happening with AI. But I also think that for established companies that already have successful customer experiences at scale, if they mainly understand AI as just incrementally improving the experience, then in three to five years they probably won't own the winning experiences. Because I think every experience we know—even those that seem most unimaginable to change—will be significantly different a few years from now because of AI. So that means if you want more than incremental improvement, you have to figure out how to get teams to reimagine from scratch what these applications should look like—assuming you were building it today with all the new technology available. In some cases, take Alexa, I think it was fairly obvious we had to do this. Alexa's "brain" was genuinely creative at the time it was built. But because of generative AI, the capabilities that "brain" can have are completely different, so if you want to deliver a great customer experience and stay relevant in the long term, you have to rewire Alexa's brain. So that one was fairly obvious. By the way, though it's fairly obvious, it's actually hard to do—because teams have an emotional connection to what they build, they're proud of what they've built, and they have hard-earned scar tissue about what works and what doesn't. Getting them to completely start from scratch and reimagine takes time, because teams will say: well, we don't do it that way; we tried that, it didn't work. Or something like that. But I think what's harder is this: take our other consumer experiences—take our retail business, or the Prime Video business, the Fire TV business, Prime Music—in those experiences, it's not as obvious that technology today already has a much better solution. But I actually believe that in each of these businesses, we need to reinvent; and we already have teams working on thoroughly reimagined versions of these businesses. So, do I think we'll get it right on the first try? Probably not. We'll figure out how to iterate our way into it, but it's already generating all kinds of new ideas and customer experiences that we think are very compelling. And then what will be interesting is the race: do you want a completely different experience—almost like a new app—or do the new things move fast enough that you add them into the existing experience and, bit by bit over the next two or three years, substantially change the overall customer experience? As you find the elements that work. But I do think that if you want to be a successful leader, every one of these experiences has to become different in the coming years. Yes, it's a very tricky leadership problem. It reminds me of when I first became an engineer. I got into an argument with someone about something. My boss said: listen, Ben, you have to understand one thing—before the first line of code is written, everything is up for discussion; after that, it becomes religion. I guess you went through this with Alexa too. But what's interesting is: all that knowledge, all that experience, all the things used to build the original thing—now you're saying, okay, we're willing to give up a big part of that and move to this new world. And by the way, it's the same for customers: you'll have a large group of customers who love the current experience, right? Yes, every big transformation—at least in my experience, though maybe you can cite examples where it wasn't like this—but almost every big transformation requires a huge change: the technology, the product, the customer experience, and the business elements all have to be compelling enough to make people want to change. But even then, it doesn't happen automatically. It's a huge change management effort—like moving from on-premises to the cloud, it's the same kind of transformation: a lot of infrastructure leaders are very proud of what they've built, they know it inside and out, they're at the center of the action, and they don't want to learn something new. It's going to be the same thing, the kind of experience I just mentioned. It'll be the same for reinventing all your customer experiences. We're all proud of what we've built in these experiences over the past decade, we all have 100 things that could make it better, we're all excited about it, and we spend all our waking hours on it. To think about "how do I completely start from scratch," you know, that's hard intellectually and emotionally. Yes, without a doubt.

a16z 53:06

Also, Andy, a few weeks ago we just incubated Harwood's and Jason Academy to help young people prepare for this transformation we're talking about. You said AI makes building easier, but young people still need to learn, you know, real expertise. I'm curious: if you were an 18-year-old in 2026, what advice would you give yourself to prepare for this transformation we're entering?

Andy Jassy 53:29

Well, I have a 25-year-old and a 22-year-old. So I guess the 22-year-old was 19 when he really started taking off. I quickly realized: you can't tell them not to use AI in their education. That ship has sailed, or that train has left the station. And I think the smart thing for universities is not to fight it. I think it's just a tool people are going to use.

Andy Jassy 53:54

But at the same time, I think all young people—and I'd say the same for us, we have a lot of people, we have a writing culture, people use AI to write things—you can tell what's written by AI: it's just, it's not quite right, the pieces aren't stitched together. And you know, so the advice I'd give young people—and the advice I give my kids—is.

Andy Jassy 54:18

You can't escape it, you know, and you can't expect it to go away. It's going to have a huge impact on your life, on every experience you try to use, on your work; and it's going to let you invent in ways we never could before. So you really need to learn about it, you need to teach yourself, you need to use it a lot. You need to experiment. Try doing something outside your comfort zone.

Andy Jassy 54:48

Neither of my kids are developers, but they've, you know, built apps with AI. Make it the focal point of how you organize your day and the tools you use at work. But I don't think it replaces critical reasoning and thinking. And I think that's true for universities too. I think about it in many ways—I'll use business school as an example. You get three cases to analyze, you do a lot of reading, take notes, figure out what the key issues are. Then you get a bunch of supporting materials, and you take notes on those too. Then you have to put together the approach you think the company should take. And you know, often there are a bunch of people who don't do any of that work at all—they don't read, they don't research, they don't take notes. And AI can do all of that for you, and it gets everyone to that higher starting point faster.

Andy Jassy 55:52

But I'd also say that actually connecting those dots, those pieces—whether it's forming a strategy, an idea, a plan, a new product, or a new customer experience—I don't think AI will do that most of the time, for most people. I'm not saying it will never happen.

Andy Jassy 56:10

I still think you need human judgment, creativity, inventiveness, a spirit of experimentation, and thinking about how all the pieces fit together to ultimately create amazing experiences and businesses. So I think you should use these tools, they'll be a huge help, but I still think critical reasoning and thinking will be very important in everything we do. We're nearing the end. The business you all are in is like...

a16z 56:43

From satellite connectivity to robotics to healthcare, so diverse. I mean, that ambition is incredible. Think about how this business started, you know, selling books on the internet, and now it's this. How do you think about, um, what ties these different...

Andy Jassy 57:00

business lines together? Or how do you decide which business lines are worth investing years in? Or how do you make sure you don't spread yourself too thin? Or how do you make sense of this incredibly broad landscape?

Andy Jassy 57:11

Well, I'd say a few things. First, I think we're in the middle of the three biggest transformations of our lifetimes—maybe of all time: AI, robotics, and space development. They're all enormous, and they'll all fundamentally change many of the customer experiences all of us will encounter. And we're right in the middle of these three big transformations.

Andy Jassy 57:40

If you look at what we're doing in our retail business, and how we use robotics, what we're doing on the AI side—both making it easier for internal and external builders to create successful AI applications and agents, and reinventing all of our consumer experiences.

Andy Jassy 57:58

If you think about Amazon Leo—the low Earth orbit satellite constellation we're building for the 500 million households around the world that don't yet have broadband connectivity—there's an incredible set of transformations happening there, and we have an opportunity to help customers take advantage of them and make their lives better. And we do it in a way that both helps customers and creates a long-term sustainable business for us. And we, you know, I think we have an opportunity to become more relevant to customers in more areas. That's not even counting what we're doing in grocery, what we're doing in autonomous ride-hailing and healthcare, and, you know, these.

Andy Jassy 58:47

Risk Disclosure and Disclaimer

Markets carry risk, and investing requires caution. This article does not constitute personal investment advice and does not take into account the specific investment objectives, financial situation, or needs of individual users. Users should consider whether any opinions, views, or conclusions in this article are suitable for their particular circumstances. Invest accordingly at your own risk.