The Problem Amazon Built a Business Around: How Andy Jassy Helped Turn AWS Into a Trillion-Dollar Ambition

Amazon now expects to spend approximately $220 billion in cash capital expenditures in 2026, much of it directed toward cloud and AI infrastructure. Its cloud division alone is now generating revenue at a $169 billion annual pace, growing faster than it has in nearly two decades. And on earnings call this year, CEO Andy Jassy told investors he believes that business could eventually generate $1 trillion a year. To understand why Amazon is willing to spend at that scale on a bet about the future, it helps to go back to a much smaller, stranger decision Amazon made twenty years ago — one that had nothing to do with artificial intelligence, and everything to do with a problem the company couldn't stop running into internally.

The Problem Amazon Was Actually Trying to Solve

By the early 2000s, Amazon had a good problem and a bad one tangled together. The good problem was growth: more products, more traffic, more engineers building more features. The bad problem was that growth kept getting slower to execute, not faster. Every team that wanted to launch something new first had to build its own storage, its own database layer, its own computing setup — essentially reinventing the same plumbing every other team at Amazon had already built, slightly differently, from scratch.

Jassy has described the resulting frustration directly. In a 2016 account of AWS's origins, he recalled that engineering leadership expected new projects to take about three months — but teams were spending three months just building the storage or database component before they could start on the actual project. Multiplied across dozens of teams building overlapping infrastructure with no shared standard, it was slowing the entire company down.

Amazon's response, starting around 2000 and accelerating over the next few years, was to force internal teams to build and expose their systems as standardized, API-accessible services rather than tangled, one-off code. As Jassy put it, Amazon "very quietly" became a services company internally, well before anyone outside the company thought of it that way.

The Idea Hiding Inside the Fix

Here the story gets genuinely contested — and it's worth being honest about that rather than flattening it into a clean legend. Amazon's own histories of AWS don't agree on a single origin moment. Some trace it to a set of e-commerce APIs Amazon released in July 2002, opening its product catalog to outside developers. Others point to a paper written internally in late 2003, credited to engineers Benjamin Black and Chris Pinkham, describing what Amazon's computing infrastructure could look like if it were "completely standardized, completely automated" — and floating the idea, almost as an aside, that Amazon could sell access to it. Jassy has said he authored an internal planning document around the same period making a similar case. Notably, when journalists later tried to track down that original document as part of AWS's twentieth-anniversary retrospective, Amazon itself was unable to produce it.

What's not contested is the underlying insight, wherever it first surfaced inside the company: Amazon wasn't just an online retailer that happened to have infrastructure problems. It had, through years of internal necessity, built a genuinely difficult piece of engineering — infrastructure that could scale reliably under unpredictable, retail-level traffic spikes. Multiple people at Amazon, in different parts of the company, arrived at roughly the same realization at roughly the same time: other companies building anything online were hitting the identical wall. Jassy became one of the central executives who pushed that idea from an internal efficiency fix toward an external product, and he went on to lead the business it became.

A Strange Product for a Skeptical Market

Amazon Web Services launched with almost deliberate plainness. Amazon S3 — Simple Storage Service — went live on March 14, 2006, priced at $0.15 per gigabyte of storage per month plus $0.20 per gigabyte for data transferred in or out. Amazon EC2, its computing counterpart, followed that August at $0.10 an hour for a small computing instance. There was no press keynote, no grand unveiling — AWS's own account of the period describes the S3 launch as accompanied by little more than "a press release and a simple blog post."

The pitch was an unusual one for a company known for selling books and electronics: rent computing power and storage the way you'd rent a warehouse shelf, pay only for what you use, and skip building any of it yourself. Amazon had no enterprise sales force, no track record in technology services, and a retail brand that had nothing to do with corporate IT. It was a fair question, one AWS had to answer for years afterward, why any company would trust its data or its servers to a bookseller.

The Market Took Time to Believe It

AWS's growth in its first years was not the immediate phenomenon it's often remembered as. AWS initially attracted startups and individual developers drawn by the low friction of self-service signup, while adoption by larger enterprises and corporate IT departments developed more gradually. Convincing larger organizations, and later governments, to run serious workloads on Amazon's infrastructure took years of building credibility, expanding the range of available services, and demonstrating reliability at a scale nobody had previously had to prove.

That slow build is easy to lose sight of now that AWS is described, without qualification, as the business that invented the modern cloud computing market. At the time, it was an unproven side project at a company still primarily known for something else entirely.

Twenty Years Later, the Same Instinct at a Completely Different Scale

By 2026, AWS was no longer Amazon's side project by any measure. In the second quarter of the year, AWS revenue reached $42.2 billion, up 36.7% year over year — its fastest growth rate in eighteen quarters and its fifth consecutive quarter of acceleration — putting the business at an annualized revenue run rate of $169 billion. Operating margins on that business reached roughly 39%, and its contracted backlog — customer commitments for future revenue — stood at $496 billion.

Driving that acceleration is a version of the same underlying instinct that shaped AWS in 2003: building infrastructure capacity ahead of what current revenue alone would justify, in anticipation of demand Amazon believes is coming. This isn't a blind bet the way the earliest AWS years arguably were — Amazon says it already has substantial customer demand and commitments, reflected in a $496 billion backlog, and Jassy has spoken about capacity constraints rather than a search for buyers. The genuine uncertainty is less about whether demand exists today and more about how large that demand ultimately grows, how the economics hold up, and how durable it proves to be. Amazon raised its 2026 capital expenditure plan to approximately $220 billion, up from an earlier $200 billion estimate, citing rising memory costs and continued AI-driven demand. Jassy told investors that even at that spending level, Amazon would not have enough capacity to meet all of the demand it already has for 2026 — and that the same would likely be true in 2027, with demand for 2028 capacity, in his words, already "striking."

On that same earnings call, Jassy described AWS's long-term potential in terms that would have sounded absurd applied to the $10 billion business AWS was a decade ago: a path toward $1 trillion in annual revenue. That figure is Jassy's stated ambition and Amazon's internal framing of AWS's ceiling — not current revenue, not a formal financial projection, and not yet demonstrated. AWS's current $169 billion run rate would need to grow roughly sixfold to reach it.

The Same Bet, or a Different One?

It's tempting to read AWS's history as proof that Amazon's current AI infrastructure spending will pay off the same way the original cloud bet did. That connection is worth resisting as a guarantee rather than simply repeating it. The core pattern rhymes: Amazon is again building infrastructure capacity ahead of what current revenue alone would justify, betting that the market will grow into the capacity rather than the other way around. In 2006, the downside of that bet, if it had failed, was a moderately expensive side project inside a profitable retail company. In 2026, the scale is different by orders of magnitude — a single year's capital spending plan larger than AWS's entire annual revenue was for most of the 2010s, and free cash flow that has already turned negative on a trailing basis alongside it.

Whether the AI-driven expansion of AWS follows the same arc as the original cloud bet — years of skepticism followed by a market that eventually needed exactly what was built — or whether AI infrastructure economics behave differently at this scale is a genuinely open question, not one the history of AWS's founding can answer on its own.

The Deeper Point

Strip away the specific technology, and the story of AWS is less about cloud computing and more about how Amazon treated a problem it had already solved. Amazon didn't set out to build a trillion-dollar business. It set out to stop wasting months rebuilding the same infrastructure for every internal project. The decision that mattered was recognizing that the fix itself — not just the problem it solved — might be worth something to companies far beyond Amazon.

That habit links 2003 to 2026: Amazon's tendency to treat its own operational capability as a potential business rather than simply a cost to be managed. A similar instinct now underwrites one of the largest capital spending programs in corporate history, aimed at an AI infrastructure market whose eventual size is still, by Amazon's own admission, a matter of ambition rather than fact.

FAQ

How did AWS actually begin? AWS's origins are genuinely contested rather than a single clean story. Different accounts trace it to e-commerce APIs Amazon released in 2002, an internal paper written in late 2003 by engineers Benjamin Black and Chris Pinkham proposing standardized, sellable infrastructure, and planning work Andy Jassy has said he led around the same period. Amazon's own internal mandate to build services as standardized, API-accessible components, starting around 2000, laid the technical groundwork regardless of which account gets primary credit.

What role did Andy Jassy play in AWS? Jassy was one of the central executives who helped shape AWS from its early conception, and he went on to lead the AWS business for over a decade before becoming Amazon's CEO in 2021. He is not accurately described as AWS's sole creator; multiple engineers and executives contributed to the idea and its early execution.

Why did Amazon sell its own internal infrastructure to other companies? Amazon had built infrastructure capable of handling unpredictable, large-scale retail traffic — a genuinely hard engineering problem. Amazon recognized that other companies building anything online faced the same infrastructure challenges Amazon had already solved for itself, and that this internal capability could become a product rather than remaining a purely internal cost.

What made Amazon S3 and EC2 different at launch? Both launched with simple, usage-based pricing rather than the large upfront contracts typical of enterprise IT vendors at the time — $0.15 per gigabyte per month for S3 storage, and $0.10 an hour for a small EC2 computing instance in 2006. That pricing and self-service model targeted startups and individual developers first, rather than the large enterprise customers AWS would need years to win over.

Is AWS really on track to become a $1 trillion business? That figure is Andy Jassy's stated long-term ambition for AWS, expressed on Amazon's Q2 2026 earnings call, not a current financial result or formal company guidance. AWS's annualized revenue run rate was $169 billion at the time he made the comment — meaning the business would need to grow roughly sixfold to reach that scale.