Practice & Reference · Case Study · Real company

Amazon & "You Build It, You Run It"

This is a real company's story, and it's the exact origin of a phrase already quoted earlier in this course. In the early 2000s Amazon's own website was straining under one shared codebase that every team edited together — and the fix Amazon chose, an internal mandate that no team could reach into another team's code or data except through a published network interface, quietly became a seed event for both the modern microservices pattern and the AWS product line. The team-ownership model that grew out of it — small groups that design, build, deploy, and carry the pager for a single service, with nobody else's name on the on-call schedule — is what Amazon's own engineers named "you build it, you run it." Where the public record runs thin, this page says so: parts of this story survive mainly through a leaked internal memo and a handful of insider retrospectives, not an official company history.

The problem: one shared codebase named Obidos

☺ Like you're 10: Amazon's whole website used to be one giant program every team edited together, so a change meant for checkout could quietly break search.

Through the late 1990s, Amazon.com ran as what later engineering retrospectives — including the widely circulated 2007 "Amazon Architecture" write-up and several engineers' own recollections — describe as a large, tightly coupled application known internally as Obidos. Most of the site's browsing, search, cart, and checkout logic lived in one deployable unit, with broad, direct access to a shared set of databases. At a small scale this wasn't really a problem — one codebase, one release, a team of engineers who mostly knew all of it by heart.

It stopped being fine as Amazon grew. Through 1999–2001 the company added new lines of business that needed the same shared code and the same shared tables at once: third-party sellers (what became Amazon Marketplace, launched 2000), the Associates affiliate program, new international storefronts, and categories well beyond books. A change one team made to serve its own feature could silently alter a table another, unrelated team also depended on — discovered only when something broke in production, days or weeks later. Coupling that was invisible at a small scale became the company's central engineering bottleneck at a large one, and releases got riskier and slower exactly when the business needed them to get faster. Werner Vogels, who became Amazon's CTO in 2005, later described the resulting years-long shift away from that architecture publicly — by the time he was giving interviews about it in 2006, Amazon.com was already running as a large, loosely coupled set of independent services rather than the earlier monolith.

The 2002 mandate: no interface, no service

☺ Like you're 10: Around 2002 Amazon told every team the same thing — nobody reaches into another team's code or database anymore, the only way in is through a labeled front door, or you're fired.

The most detailed public account of how that shift was forced through comes from an unlikely source: a Google employee's internal memo. In October 2011, then-Google engineer Steve Yegge — who had worked at Amazon from 2004 to 2006 — accidentally posted a long internal reflection publicly on Google+, comparing Google's platform strategy unfavorably to Amazon's. In it, he recounted from memory a mandate he attributed to Jeff Bezos, issued company-wide sometime around 2002. Paraphrased, its substance was six rules:

The word "microservices" wouldn't enter common industry use for close to another decade. Amazon had, in effect, forced a company-wide service-oriented decomposition years before the pattern had a name — and it hadn't done so as an architecture recommendation with a rollout plan and a grace period. It had done so as a mandate with a job-ending consequence for ignoring it, which is a very different kind of forcing function than a best-practices document nobody reads.

Two-pizza teams: small enough to own it, measured on one thing

☺ Like you're 10: Bezos also shrank the teams themselves — small enough to share two pizzas — so each little group could actually own one whole service instead of a slice of a shared one.

The interface mandate answered "how do teams talk to each other." A second, related rule answered "how big should a team even be": Bezos's own sizing guideline held that if a team couldn't be fed by two pizzas, it was too big — commonly cited as landing somewhere around five to ten people, depending on who's telling the story and how hungry the team was. Paired with the mandate above, this gave each small team a natural, complete unit to own: one service, end to end, with a boundary a two-pizza group could actually hold in its collective head.

Former Amazon vice president Colin Bryar and Bill Carr's 2021 insider account, Working Backwards, adds a detail that rarely makes it into the shorter, more legendary retellings of this story: each two-pizza team was supposed to be assigned a fitness function — a single measurable outcome, ideally tied to a real customer or business result rather than an internal engineering metric, that told the team and everyone above it whether the team was actually succeeding, not just busy.

Bryar and Carr are also candid that the program, as a company-wide mandated structure, didn't fully work. Good fitness functions turned out to be genuinely hard to define. A proliferation of small, autonomous teams sitting on top of shared dependencies created a coordination overhead of its own — the kind of overhead the mandate had been designed to remove in the first place, now showing up one layer up the org chart. What survived and generalized wasn't the exact headcount rule; it was the underlying discipline of a single, small, accountable group owning one thing completely — which Amazon later formalized further as "single-threaded ownership" for major cross-cutting initiatives, with one named leader accountable end to end even when the work spans more than one two-pizza team.

"You build it, you run it": Vogels' 2006 framing

☺ Like you're 10: Amazon's own CTO explained the payoff in one line in 2006 — the people who write a service also run it in production and hear directly from customers when it breaks.

Werner Vogels put the operational consequence of this model into words in "A Conversation with Werner Vogels," an interview published in ACM Queue in June 2006. He described the traditional split — developers hand finished software to a separate operations team and move on to the next thing — as replaced, inside Amazon, by developers carrying operational responsibility for what they'd built themselves. The four words this course already quotes on what is DevOps are his: "you build it, you run it."

Mechanically, this means each two-pizza team's on-call rotation covers its own service. Nobody pages a separate, unfamiliar operations group when something breaks — the person holding the pager is, almost always, someone who has read that exact code. Vogels tied this directly to quality, not just speed: engineers who personally get paged for their own bugs, and who hear from real customers about the consequences, build differently than engineers who never see what happens after the handoff. That's the same causal chain covered in more depth on culture & collaboration and on-call culture & sustainable operations — ownership changes behavior because it closes a feedback loop that a handoff severs.

From internal plumbing to a product: AWS

☺ Like you're 10: Because every team's service already had to work as a clean, well-documented network interface, Amazon had basically pre-built the parts it needed to rent computing to the outside world.

Rule five of the mandate — every interface must be designed from day one to be externalizable, no exceptions — is the detail that turns this from an org-chart story into an infrastructure one. Amazon Web Services launched its first public services in 2006: Amazon S3 (Simple Storage Service) on March 14, and Amazon EC2 (Elastic Compute Cloud) in limited beta on August 25. Both are widely described, including in retrospectives from Amazon's own engineers, as growing out of infrastructure the company had already been forced to build well and harden internally, years earlier, to run its own retail business.

It's worth being precise about how strong a claim that is. The tidy version — "Amazon built AWS by accident because of an internal memo" — compresses a genuinely more complicated history involving a specific internal proposal from engineers including Chris Pinkham and Benjamin Black for selling raw compute capacity, and a business case built by Andy Jassy's team. The mandate didn't cause AWS on its own. What it did was remove a specific, expensive kind of work AWS would otherwise have needed to do from scratch: by the time anyone proposed selling a service externally, Amazon had already spent several years enforcing the discipline of clean, documented, network-callable interfaces internally, company-wide, with a job-ending consequence for cutting corners on it. That's not nothing — it's the exact discipline external customers need before they'll trust a service with their own production traffic.

What Amazon has said about the outcomes

☺ Like you're 10: A widely repeated deployment number, the memories of people who lived through it, and a public book from insiders years later — treat all of it as evidence the approach worked, not as an audited study.

• Hundreds of services, by Vogels' own account. His 2006 remarks describe Amazon.com as already running on a large number of independent, loosely coupled services rather than the earlier monolith. Exact counts vary across retellings and years, so treat "hundreds of services" as an order-of-magnitude description repeated across several retrospectives, not a single official figure.
• The "every 11.6 seconds" deployment figure. Widely repeated in DevOps literature — including Gene Kim, Jez Humble, Patrick Debois, and John Willis's The DevOps Handbook — this attributes to a 2011 internal Amazon platform report an average production deployment roughly every 11.6 seconds, with over a thousand deployments running concurrently during peak periods. It's the same deployment-frequency metric this course covers formally in measuring success: the DORA metrics. The figure has circulated in conference talks and secondary sources for well over a decade with no newer official Amazon number replacing it — treat it as a widely cited historical data point, not a current one.
• A public, insider-written retrospective. Bryar and Carr's 2021 Working Backwards is the most detailed account available of how the two-pizza-team model actually played out — including its documented shortcomings — from two people who were inside Amazon's leadership when it happened, rather than from outside observers piecing the story together after the fact.

What to steal for your own org

☺ Like you're 10: You don't need Amazon's headcount to copy the two habits underneath this story — force ownership through a real interface, and make the people who build something the same people who get paged for it.

• Force the boundary with a real interface, not a diagram. A service boundary drawn on an architecture slide and never enforced in code decays within a quarter. Amazon's version had teeth because "no direct database access" was a rule with a consequence, not a suggestion — the closest equivalent most teams have is treating a service's API as the only supported entry point and actually removing the back doors, covered in containers & orchestration and configuration management & IaC.
• Put the pager with the people who wrote the code. This is the part of the story that transfers at almost any size: whoever's on-call for a service should be able to read its code, not just its dashboards. See on-call culture & sustainable operations and incident & event response.
• Pick one fitness function per team before you shrink the team. Bryar and Carr's own account says the fitness function was the hard part, not the headcount — decide what a team is actually accountable for, in terms a customer would recognize, before reorganizing around smaller boxes. See SLOs, error budgets & toil for a concrete way to write one.
• Keep teams small enough that "who owns this" has one obvious answer. The number that matters isn't five, eight, or ten — it's whether a new engineer can point to exactly one team and say "they own this service" without a caveat. See scaling CI/CD across teams for what breaks first when that stops being true.
• Invest in the platform underneath ownership, or it's just relocated toil. Amazon paired "you build it, you run it" with years of internal tooling investment; without an equivalent, full-service ownership becomes a burnout generator instead of an incentive fix. See from DevOps to platform engineering and the inner loop & developer experience. For a smaller, fictional walkthrough of sequencing changes like these without Amazon's headcount, see the 90-day transformation case study.

Honest caveats: what doesn't transfer

☺ Like you're 10: A mandate backed by "or you're fired," at a company that could out-hire almost anyone, pieced together mostly after the fact — read the lesson here, not the literal instructions.

• Much of the mandate story is second-hand. Steve Yegge's recounting is a former employee's memory, written five years after he left Amazon and posted by accident, not an official document. Its substance is corroborated by what came after, but the exact wording of "the six rules" as commonly quoted online is a reconstruction, not a verbatim leak.
• The mandate had teeth most orgs don't have — or want. "Comply or be fired" only works as a forcing function alongside a hiring bar high enough that losing an engineer over it is a real, credible threat rather than an empty one. Copying the org-chart shape without the accountability culture underneath it tends to produce disconnected services with unclear ownership, not clean ones.
• Two-pizza teams as a strict headcount rule reportedly didn't fully survive even inside Amazon. Bryar and Carr's own account is candid that defining good fitness functions was hard and that small autonomous teams created their own coordination overhead. Team size alone was never the mechanism that made this work.
• Without real platform investment, "you build it, you run it" becomes "you build it, you suffer." Full-cycle ownership only reduces total pain when it's paired with tooling that removes undifferentiated toil — the same warning this course repeats on on-call culture & sustainable operations. Handing a small team a service and a pager, with nothing else, is not the lesson.
• The published numbers are old, self-reported, and secondary-sourced. The 11.6-second deployment figure comes from a 2011 internal report repeated in later books and talks, not an independently audited study with a current re-run. Treat it as historically informative about the approach, not as a live metric to benchmark against today.

Where this connects in the course

☺ Like you're 10: This one company's story touches several lessons — read whichever matches what you're building next.

This page is the other half of a story this course tells in two places: the 2009 Velocity talk that gave the movement its name lives in Flickr & the origin of DevOps, while this page covers the structural template — small, accountable teams owning a service's full lifecycle — that Flickr's talk assumed already existed as a working pattern somewhere. The service-boundary half of this story continues in containers & orchestration and the DevOps lifecycle; the ownership-and-pager half continues in culture & collaboration and on-call culture & sustainable operations. And the metric this page keeps citing — deployment frequency — gets its full, current treatment in measuring success: the DORA metrics.

Check your answers

1. Obidos was Amazon.com's original, largely monolithic web application, with most site logic in one deployable unit and broad, direct access to shared databases. As Amazon added new lines of business through 1999–2001, more teams needed to touch the same shared code and tables at once, so one team's change could silently break another team's unrelated feature — coupling that was invisible at a small scale became the central bottleneck at a large one.
2. Any three of: every team exposes data/functionality only through a service interface; teams communicate only through those interfaces; no other inter-process communication is allowed (no shared databases, no back doors, network calls only); the technology behind an interface is each team's own choice; every interface must be designed to be externalizable from day one; anyone who doesn't comply gets fired.
3. The "two-pizza team" rule — a team too big to be fed by two pizzas (roughly five to ten people) was too big. A fitness function was supposed to be a single measurable outcome, ideally tied to a real customer or business result, that told the team and everyone above it whether it was actually succeeding.
4. Developers themselves carry operational responsibility for what they build — on-call for a service sits with the same people who wrote its code, instead of being handed to a separate operations team. Vogels tied this to quality, not just speed, because engineers who personally get paged for their own bugs and hear directly from customers build differently than engineers who never see the consequences of a handoff.
5. Because every internal service already had to be a clean, documented, network-callable interface (per the mandate's rule five), Amazon had, by the time it launched AWS in 2006, already spent years building and hardening exactly the kind of infrastructure a public cloud service requires. The mandate didn't cause AWS automatically, though — a specific internal proposal and a deliberate business decision were still required, so the two events shouldn't be retold as one falling directly out of the other.
6. Any of: much of the mandate's exact wording is second-hand, from a former employee's memory posted years later; the mandate's "or you're fired" teeth depended on a hiring bar most orgs don't have; the strict two-pizza headcount rule reportedly didn't fully survive even at Amazon itself; without real platform investment, full-service ownership becomes burnout rather than an incentive fix; the published deployment numbers are old, self-reported, and secondary-sourced.