Amazon Web Services: The Idle Server Myth
The Warehouse Was Never Full
The creation myth is appealing because it suggests thrift. For years, the story held that Amazon Web Services began as a way to monetize idle servers, xcess capacity from the holiday rush sitting dormant in warehouses, rented out to developers to improve utilization. It is a tidy narrative about efficiency and waste reduction, the kind of operational virtue that appeals to supply-chain sensibilities. But Werner Vogels, Amazon’s chief technology officer, extinguished this in a 2011 Quora post: “The excess capacity story is a myth. Within two months after launch, AWS would have already burned through the excess amazon.com capacity.” The servers were never spare. The business was born not from abundance, but from desperation.
In 1995, Shel Kaphan designed Amazon’s original codebase as a monolithic application. By 2000, this architecture had become a prison. The system was so tightly coupled that any change risked collapsing the entire edifice. During the fourth quarter, when holiday traffic peaked, engineering instituted mandatory code freezes. No new features. No updates. For months, the technical team merely stood watch, hoping the system wouldn’t buckle under load. The company was growing fast enough to die, nable to deploy innovations because the infrastructure couldn’t tolerate disturbance. The solution was not to rent out spare capacity, but to decompose the monolith into services, creating an internal architecture where components could scale independently. This was service-oriented architecture born of necessity, not strategy. When Tim O’Reilly sat with Jeff Bezos in 2002 to discuss “Web 2.0” and the economic potential of APIs, he found a company already technically conditioned to think in discrete, rentable units. AWS launched that year with eight attendees at a developer conference, initially just exposing the product catalog. The infrastructure was not excess. It was newly liberated.
Thirty Percent Versus One Point Five
The economic engine of AWS operates on a margin structure that barely seems related to Amazon’s retail business. Where Amazon.com generates operating margins of approximately 1.5 percent, spending 98.5 cents to deliver a dollar of merchandise, AWS operates near 30 percent. The unit generates only 15 percent of retail revenue yet produces operating income equal to or greater than the entire consumer business. This is not merely a question of software multiples over physical goods; it reflects a fundamental restructuring of infrastructure economics.
In 2000, facing a cash crisis, Amazon migrated from DEC Alpha servers to Linux running on commodity HP hardware. The DEC machines represented the old model: bundled hardware-software platforms sold by legacy vendors (Digital Equipment Corporation, Oracle, IBM) at 70 to 80 percent gross margins. Amazon’s shift to open-source software and industry-standard servers shattered this cost structure. By building on Linux and commodity components, AWS inherited a cost basis that allowed it to price services 50 to 70 percent below traditional enterprise vendors while still capturing superior profitability. The legacy vendors could not match these prices without annihilating their existing revenue streams; they were trapped by their own margin structures. AWS, carrying no such baggage, could undercut the market and still mint money. The business compounds because each workload that migrates to AWS generates data gravity and architectural lock-in. Moving a database, or a set of integrated applications, becomes prohibitively expensive, creating a retention mechanism that retail, where switching costs are minimal, can never match.
Serving Two Sovereigns
Yet this margin advantage rests upon a structural constraint that remains unresolved. AWS must maintain capacity to serve external customers while guaranteeing absolute priority to Amazon.com retail operations, particularly during the fourth quarter when e-commerce traffic spikes unpredictably. Excess capacity is pure cost until utilized, yet that capacity cannot be reserved exclusively for retail without destroying the reliability guarantees upon which external customers depend. If AWS over-provisions to ensure retail can burst infinitely, utilization rates crater and the 30 percent margin evaporates. If AWS under-provisions to optimize utilization, Amazon.com faces outage risk during its highest-revenue period. The only resolution is genuine architectural separation, ndependent scaling mechanisms that treat the two masters as separate sovereignties requiring equal fidelity.
This partition requires technical and organizational discipline that most conglomerates fail to achieve. But it creates a deeper tension: AWS has grown so profitable that it now overshadows its parent. The business unit that began as a solution to retail’s technical crisis now generates more operating income than the entire retail operation. This creates an incentive misalignment that cannot be optimized. If Amazon starves AWS of capital to fund retail expansion, new fulfillment centers, logistics networks, grocery experiments, the higher-margin business atrophies. If Amazon prioritizes AWS, retail infrastructure becomes secondary, risking the very traffic spikes that originally necessitated the infrastructure. The parent company is structurally unable to maximize both simultaneously. The architecture must serve two sovereigns with equal urgency, even as the economics suggest favoring one.
The Architecture of Crisis
Most analyses of AWS’s durability focus on scale, ata centers, fiber miles, market share. They miss the specific nature of the advantage. Amazon faced the monolithic codebase crisis in 2000, three to five years before Google or Microsoft encountered similar scale pressures. By the time competitors recognized the necessity of distributed, service-oriented architecture, Amazon had already spent half a decade operating such a system under live fire. Every retail transaction, every holiday spike, every new feature launch became a stress test for the infrastructure that would become AWS. Competitors had to learn these lessons in isolation or through acquisition; Amazon learned them while drowning, with the company’s survival at stake.
This head start in architectural learning created a moat deeper than capital expenditure. By the time AWS launched S3 and EC2 in 2006, the company had already internalized the operational patterns of multi-tenant infrastructure, failure domains, noisy neighbor mitigation, API design for external consumption, that others were only beginning to theorize. The 39 percent market share AWS now commands reflects not just first-mover advantage in the commercial sense, but first-mover advantage in the specific intellectual discipline of running distributed systems at scale. Competitors cannot replicate this without experiencing a similar existential crisis, and by the time they did, AWS had already trained millions of developers on its APIs, embedding switching costs into the technical workforce itself.
Lock-in Without the Handcuffs
The business model depends on a precarious balance between openness and enclosure. AWS grew by embracing the Web 2.0 vision, PI-driven interoperability, developer freedom, the platform as a blank canvas upon which customers could build. Bezos mandated the mission to “let developers surprise us with what they build.” Yet the economics require lock-in. Data gravity ensures that once workloads accumulate, migration costs become prohibitive. The more integrated a customer becomes with AWS’s higher-order services, Lambda, Redshift, the proprietary management console, the more they are bound to the platform.
Too much openness, and AWS becomes a commodity utility, competing solely on price against undifferentiated compute. Too much enclosure, and regulators intervene, or customers actively architect around the platform to avoid perceived captivity. The equilibrium shifts with political winds. The company must innovate fast enough that customers perceive the platform as continuously advancing, worth the premium and the commitment, without moving so fast that the underlying technology becomes indistinguishable from a standard that could be replicated elsewhere. It is a performance of permanence: the infrastructure must seem inevitable, yet never so proprietary that it invites antitrust scrutiny.
The Efficiency Trap
The 30 percent margin leaves no room for error. Unlike retail, where thin margins are expected and forgiven as the cost of doing business in physical goods, AWS’s profitability assumes operational perfection. A major security breach, a prolonged outage, a cost overrun in data center construction, ny significant operational failure erases the margin advantage and makes the business model unviable. The company has engineered itself into a position of zero tolerance.
This explains the peculiar intensity of AWS’s operational culture. The business cannot absorb slack. Every percentage point of utilization matters. Every security protocol must hold under nation-state attack. Every price reduction, announced with regularity as scale efficiencies compound, must be funded by equivalent cost discipline elsewhere. The model has no margin for slack, literally and figuratively. Competitors like Microsoft or Google might subsidize cloud losses with profits from software licensing or advertising; AWS must sustain its economics through pure operational execution, because it is the profit engine of its parent, not a loss-leading venture.
The Generalist’s Edge
The leadership structure of AWS reflects these economic imperatives. Andy Jassy, who led the division from its inception through his elevation to Amazon CEO, came to the role without a technical background. A Harvard MBA who had launched the company’s music category, Jassy served as Jeff Bezos’s technical assistant during the dot-com crash. He understood the business as a platform problem and a pricing problem before he understood it as an engineering problem.
This was not a deficit but a specification. A technical founder might have optimized for architectural purity; Jassy optimized for the margin structure. He recognized that AWS was not a server rental business but a permissioning business, ranting developers access to capabilities previously reserved for corporations with mainframe budgets. The economic variable was not the hardware, but the contract: pay-as-you-go rather than capital expenditure, API access rather than procurement cycles. Jassy’s lack of engineering orthodoxy allowed him to see the DEC Alpha migration not as a technical migration but as a business model assassination, eplacing 80 percent margin vendors with 30 percent margin Amazon, still vastly profitable while being radically cheaper.
When the Walls Fall
The entire edifice rests on a fragile assumption: that infrastructure will remain complex enough to prevent commoditization, yet standardized enough to prevent fragmentation. If Kubernetes, OpenStack, or edge computing architectures make workloads truly portable, if multi-cloud strategies become operationally trivial rather than technically heroic, then AWS’s switching costs dissolve. The data gravity weakens. The business becomes a race to the bottom on price alone.
This is the bear case. The open-source abstraction layers that AWS itself helped popularize could eventually make the underlying cloud provider interchangeable. If customers can run identical workloads on AWS, Microsoft Azure, and Google Cloud without architectural friction, then the 30 percent margin compresses toward the cost of capital. The assumption that customers will consolidate on a single provider, that the complexity of managing multiple clouds outweighs the benefits of diversification, must hold. If it breaks, AWS becomes a utility like electricity or bandwidth: necessary, ubiquitous, and poorly remunerated.
The business survives as long as it maintains the architectural separation between its two sovereigns, retail and external, while exploiting a learning advantage that competitors cannot purchase, predicated on a crisis they did not survive. It is a bet that infrastructure complexity persists, that operational perfection is sustainable, and that the lock-in can remain tight enough to retain customers but loose enough to avoid regulatory fracture. The warehouse was never full, but the architecture must remain hungry, onsuming workloads faster than the market can simplify them away.
The architectural separation between Amazon retail and AWS is not merely a technical partition but an organizational fiction that must be maintained at enormous cost. During the forty-eight hours of Prime Day, when Amazon.com processes hundreds of millions of transactions, the infrastructure does not politely pause for external customers. Nor does it borrow capacity from the cloud to serve retail spikes. Instead, both systems must draw from the same physical substrate, fiber, power, silicon, while maintaining the illusion of infinite, independent elasticity. This requires what engineers call “blast radius containment”: the failure of a retail recommendation engine cannot cascade into an AWS region outage, and a DDoS attack on a startup’s EC2 instance cannot touch the checkout flow of the parent company.
Achieving this separation demanded the creation of entirely independent control planes, network isolation at the hardware level, and capacity buffers that sit deliberately underutilized. The economic waste is the price of political survival. If AWS customers suspected that Amazon.com traffic took precedence, if they perceived that their production databases sat in queue behind a surge in dog food purchases, the business would hemorrhage enterprise clients who require contractual guarantees of resource availability. Yet maintaining these buffers means that during non-peak periods, substantial capacity sits idle, depreciating. The 30 percent margin absorbs this inefficiency as a cost of doing business, but it remains a structural tax that pure-play cloud competitors do not pay. Microsoft does not operate a retail leviathan that might suddenly demand half of Azure’s US-East region on six hours’ notice. Google does not fear that Search traffic will suddenly spike by 400 percent on the fourth Thursday of November. Only Amazon carries the dual-sovereignty burden, and only Amazon must architect its way out of a conflict of interest that is embedded in its corporate DNA.
This tension manifests most acutely in the physical geography of the data centers. When Amazon selects a site for a new region, Northern Virginia, Frankfurt, Singapore, it must provision not for the expected demand of AWS customers alone, but for the potential demand of both masters simultaneously. The company cannot simply scale retail infrastructure separately and “burst” into the cloud during peaks, because the latency requirements of modern e-commerce (sub-100 millisecond response times) make cross-facility failover impractical during true spikes. The inventory must remain local to the user, and the compute must remain local to the inventory. This forces AWS to overbuild every region by the safety margin required to accommodate hypothetical retail surge, even in markets where Amazon.com has minimal presence. It is as if a hotel chain had to maintain empty rooms in every city not for its own guests, but for a parallel government that might need them without warning.
The price reduction mechanism operates within these constraints, functioning as both market expansion and competitive moat. AWS has reduced prices more than fifty times since launch, often without immediate competitive pressure, announcing cuts to S3 storage or EC2 compute with the regularity of seasonal weather. These reductions are not charitable; they are mathematical necessities of the utilization curve. As AWS fills its deliberately overbuilt capacity with customer workloads, marginal costs decline. The fixed cost of the data center is already sunk; every additional server utilized spreads that depreciation across more revenue hours. The company can therefore reduce prices while expanding margins, provided that utilization continues to climb.
Legacy vendors faced the inverse calculation. When Oracle sold a database license bundled with SPARC hardware, the margin was front-loaded and absolute. A price cut of fifty percent would have destroyed their profit structure without any compensating utilization gain, because the customer owned the hardware. The vendor could not benefit from the customer’s increasing usage. AWS, retaining ownership of the infrastructure, turns customer growth into cost efficiency, which it then converts into price reductions, which accelerates customer growth. It is a flywheel that spins in one direction only, and it has left competitors like IBM and Oracle stranded on pricing models that now look like historical artifacts. When Larry Ellison mocked cloud computing as “water vapor” and “complete gibberish” in the early 2000s, he was defending a margin structure that could not survive the transition to utility pricing. By the time Oracle built a credible cloud offering, AWS had established price points that made Oracle’s traditional licensing revenue impossible to sustain without cannibalization.
Yet this mechanism depends on continuous growth in utilization. If growth stalls, if enterprises pause migration, if startups stop launching, the fixed costs of the overbuilt architecture crush the margin. The fifty price reductions represent a bet that the market will expand fast enough to fill every data hall before the depreciation schedule demands replacement. It is a high-wire act performed without a net, where the only safety is speed.
The lock-in that protects this model operates at levels deeper than contractual obligation. When critics discuss switching costs, they typically reference egress fees: he charges AWS levies for moving data out of its facilities, which can amount to tens of thousands of dollars for petabyte-scale workloads. But these are merely the visible barriers. The true moat is architectural gravity. A company that builds on AWS does not merely rent servers; it composes applications from managed services that have no exact equivalent elsewhere. Lambda’s serverless execution model, DynamoDB’s consistency guarantees, and the IAM permissioning system create a dialect of infrastructure that cannot be directly translated to Azure or Google Cloud without semantic loss.
Developers speak of “multi-cloud strategies” with the same optimism that investors once applied to “diversified portfolios”: theoretical hedge against concentration risk. In practice, multi-cloud implementations for production workloads remain rare, not merely because of expense, but because of the cognitive load required to maintain architectural parity across platforms. A database tuned for AWS Aurora behaves differently when migrated to Google Cloud SQL; the performance characteristics shift, the failure modes change, the monitoring assumptions fail. The cost of maintaining expertise in two cloud dialects simultaneously exceeds the savings from competitive bidding. Most enterprises therefore choose a primary provider and treat the others as disaster recovery options, maintaining standby capacity that is never used, effectively paying insurance premiums to avoid the very portability that open standards promised.
This is why Kubernetes, despite its technical merit, represents an existential threat rather than an opportunity. When Google donated the container orchestration system to the Cloud Native Computing Foundation, it created a potential abstraction layer that could, theoretically, make workloads truly portable. If an application runs in containers scheduled by Kubernetes, the underlying infrastructure becomes interchangeable, AWS, Azure, on-premise hardware, all merely substrate. The economic implication is horrifying for AWS: commoditization of the compute layer, competition purely on price per vCPU and gigabyte, margins compressing toward those of the wholesale bandwidth market.
AWS has responded by embedding Kubernetes into its own control structures, ffering EKS (Elastic Kubernetes Service) rather than fighting the standard. But this is containment, not surrender. By offering managed Kubernetes, AWS ensures that while the containers may be portable, the surrounding services, load balancing, monitoring, security, networking, remain proprietary. The strategy is to embrace the standard while extending it, ensuring that Kubernetes runs best on AWS, with the tightest integration, the deepest tooling, the fewest compatibility headaches. It is the same maneuver Microsoft executed with open standards in the 1990s: support them sufficiently to prevent revolt, but embed them deeply enough that migration remains painful.
Whether this containment holds depends on whether Kubernetes matures into a true platform abstraction or remains merely a deployment tool. If the ecosystem develops standardized interfaces for storage, identity, and networking that function identically across clouds, then AWS’s dialect becomes merely one accent among many, and price competition becomes inevitable. The clock is running. Every year that Kubernetes adoption increases without achieving full portability is a year AWS wins. Every year that the ecosystem fragments into cloud-specific distributions, EKS, AKS, GKE, is a year the lock-in persists.
The operational culture that maintains this precarious advantage functions as an economic variable precisely because it prevents the margin slack that would destroy the model. Amazon’s famous “two-pizza teams”, groups small enough to be fed by two pizzas, are not merely managerial fashion. They are a cost control mechanism. Small teams cannot afford to carry passengers; every member must produce or the project fails. The six-page narrative memo that replaces PowerPoint in product reviews forces rigorous thinking because prose cannot hide logical gaps in the way bullet points can. These cultural artifacts enforce the operational discipline that the 30 percent margin demands.
When AWS suffered the S3 outage of February 2017, a four-hour disruption of the US-East-1 region that broke large portions of the internet, it revealed the fragility of the efficiency trap. The outage was caused by a single typo in a command entered during debugging. A technician intended to remove a small number of servers from service; the command removed more. The cascade that followed demonstrated how thoroughly AWS had become critical infrastructure, ot just for startups, but for enterprises that had migrated their core systems. The economic damage was not merely AWS’s lost revenue, but the reputational capital expended as customers realized their “cloud-native” architectures were, in fact, single points of failure.
The response was telling. AWS did not merely fix the technical flaw; it accelerated the architectural separation of its own internal systems. It implemented stricter change management protocols, more aggressive automation of safety checks, and expanded redundancy in ways that increased cost. The margin absorbed the hit, but the margin had no choice. A second such failure would have triggered migration discussions in boardrooms where AWS was previously considered the only logical choice. The business model permits no repetition of such errors.
This zero-defect requirement extends to security. When Capital One suffered a breach in 2019 due to a misconfigured AWS firewall, the financial damage fell on the bank, but the reputational shadow touched AWS. The company responded by developing increasingly granular permission systems, automated compliance checking, and “blast radius” containment for credentials. These are not product features; they are insurance premiums paid against the total collapse of trust. The cost of perfect security in a multi-tenant environment approaches infinity as the threat model expands to include nation-states and advanced persistent threats. Yet AWS must approach that asymptote without crossing into unprofitability.
The leadership transition from Jassy to Adam Selipsky, and subsequently to Matt Garman in 2024, tests whether the cultural-economic alignment can survive its architects. Jassy understood the business as a margin problem; his successors must understand it as a sustainability problem. The original team built AWS during a period when Amazon.com was merely large; they now inherit a situation where AWS is the profit engine of a conglomerate that includes healthcare, entertainment, logistics, and artificial intelligence. Each of these new frontiers demands infrastructure priority. The two-sovereign problem has become a multi-sovereign crisis.
Garman faces a landscape where Microsoft Azure has achieved functional parity on core compute and storage, where Google’s AI infrastructure offers genuine differentiation, and where regulation in Europe and potentially the United States threatens to mandate interoperability, orcing AWS to open its APIs in ways that would erode the architectural lock-in. The margin structure that allowed fifty price cuts may be approaching its asymptote. Power and cooling costs are rising; chips are becoming more expensive as Moore’s Law decelerates; and the shift to AI workloads requires entirely different infrastructure architectures, xpensive GPU clusters that sit idle between training runs, violating the utilization economics that made AWS profitable.
The bet remains that complexity will outrun standardization, that the integration of thousands of microservices will create sufficient friction to prevent mass migration, and that the operational culture can maintain the perfection required to sustain trust. The warehouse was never full, but the architecture must remain hungry, ot merely consuming workloads, but consuming the complexity itself, metabolizing it into the next layer of abstraction before competitors can simplify it away. If the market ever decides that infrastructure should be truly interchangeable, if Kubernetes or its successors finally breach the walls, then the thirty percent margin collapses into three, and the business that saved Amazon becomes merely another utility, notable only for its scale and its silence.
The AI transition exposes the fragility of the utilization model. Machine learning workloads violate the fundamental economics that made AWS profitable. Traditional cloud computing monetizes variable demand, spikes in web traffic, batch processing jobs, seasonal retail, that can be multiplexed across shared infrastructure. A server running e-commerce analytics at midnight can pivot to database queries at dawn. But large language model training requires dedicated GPU clusters that sit dark between training runs, consuming power and depreciation without generating revenue. The utilization curve flatlines. When Amazon announced Tranium and Inferentia chips, its proprietary AI accelerators, the move was not merely technological independence from Nvidia; it was an attempt to restore the margin structure that GPU scarcity threatened to destroy. Custom silicon allows AWS to amortize hardware costs across its entire customer base rather than purchasing scarce Nvidia H100s at monopoly prices for single-tenant allocation. Yet the economics remain hostile. The customer who rents a thousand GPUs for six weeks to train a model represents the inverse of the AWS ideal: concentrated, lumpy demand that cannot be smoothed across a multi-tenant substrate. The business is learning to sell time on silicon the way airlines sell seats, but the overbooking algorithm fails when every passenger weighs three hundred pounds.
This resource competition extends beyond silicon into the body of Amazon itself. When Project Kuiper, the satellite constellation intended to rival SpaceX’s Starlink, requires launch windows and ground station coordination, it draws upon the same operational talent that maintains AWS availability zones. When Amazon Health navigates HIPAA compliance for One Medical, it leverages the same compliance infrastructure built for AWS GovCloud. When Alexa’s inference demands spike during holiday gift-giving, the same network fabric that carries S3 traffic carries voice packets. The two-sovereign problem has metastasized into a hydra of competing priorities, each with legitimate claim to the “customer obsession” that serves as the company’s constitutional principle. The technical assistant role that Jassy occupied, translating between the business units and the infrastructure layer, has become impossible to scale. There is no longer a single interface between retail and cloud; there are a dozen divisions, each with the theoretical veto power to freeze code deployments or demand capacity reservations.
The regulatory architecture of the European Union’s Digital Markets Act represents a specific threat to the lock-in mechanism. The legislation designates AWS as a “gatekeeper” platform, mandating interoperability and data portability with the explicit goal of reducing switching costs. If enforced to its logical conclusion, the DMA would require AWS to expose its proprietary APIs in ways that allow competitors to replicate services functionally identical to S3 or DynamoDB. The architectural gravity that binds customers to the platform would weaken. Egress fees, already under regulatory scrutiny, might be capped or eliminated, removing the financial barrier to migration. The assumption that customers consolidate on a single provider because the complexity of managing multiple clouds is prohibitive would be challenged by legal mandate rather than technical innovation. AWS would face the unenviable position of being forced to commoditize itself, to assist in its own disaggregation.
This bears directly on the margin structure. If interoperability mandates prevent AWS from offering differentiated higher-order services, if Lambda must run identically on Azure, if IAM must federate seamlessly with Google’s identity systems, then the business returns to pure infrastructure arbitrage: the renting of disk space and CPU cycles, a business with margins that trend toward those of the fiber carriers and data center REITs that form the substrate beneath the cloud. The thirty percent becomes three percent not through competitive failure but through regulatory success in opening markets. Amazon has responded by slow-walking compliance, arguing that security and reliability require controlled architectures, but the political trajectory in Brussels and Washington suggests that the isolation of cloud ecosystems will be treated with the same suspicion once reserved for Microsoft’s browser bundling.
The specific mechanism of the price reduction flywheel also faces exhaustion. Each cut announced with fanfare, “lowering prices is our legacy,” as the marketing materials suggest, assumes that utilization gains will offset revenue per unit declines. But there are physical limits to utilization. Once a data center reaches eighty percent sustained occupancy, the remaining capacity must be reserved for failure recovery and traffic spikes. The marginal gain from each additional customer diminishes as the facility approaches thermal and power constraints. Simultaneously, the shift toward specialized silicon for AI, the rising cost of energy in European and Asian markets, and the increasing physical security requirements for data centers in an era of geopolitical tension all push unit costs upward. The fifty price cuts may have exhausted the easy efficiencies of the transition from DEC Alpha to commodity Linux. Future cuts would require genuine margin sacrifice rather than the gift of scale economics.
The culture of operational perfection that guards these margins shows signs of strain in the specifics. The “COE”, Correction of Error, documents that Amazon requires after every significant incident have grown from terse technical postmortems into elaborate legal defenses, anticipating regulatory inquiry and shareholder litigation. The discipline that Vogels instilled, where engineers would publicly dissect their own failures in detail sufficient to prevent recurrence, now competes with the caution of a company that knows every word may be subpoenaed. The technical freedom to “fail fast” that characterized the early AWS, launching services like SimpleDB that were later deprecated, experimenting with pricing models that were abandoned, assumed a smaller stage and more forgiving economics. At current scale, a failed service launch does not merely waste engineering hours; it consumes capacity that could have been monetized, and it risks the outage that cannot be afforded.
The excess capacity story persists as myth because it serves a psychological function: it suggests that AWS emerged from abundance, from the luxury of spare resources waiting to be utilized. The reality was scarcity. The reality remains scarcity. The company now manages not excess but precarity, uggling the sovereign demands of retail, entertainment, healthcare, and AI on infrastructure that must appear infinite while being finitely expensive. The warehouses are full, packed to the thermal limit with silicon and fiber, and every square meter must generate returns sufficient to justify the next facility, the next submarine cable, the next custom chip. The architecture that began as an escape from the monolithic prison of Shel Kaphan’s codebase has become a prison of its own design: distributed, resilient, and inexorably hungry.