AWS at scaleseven decisions behind $200B a year of infrastructure← → panels  ·  P present  ·  D draw  ·  alt+scroll or +/- zoom  ·  0 reset  ·  F fullscreen  ·  00 / 11
00built, not bought Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent $200B/yr · $500M/day

AWS spends $200 billion a year — and builds most of it itself

AND IT KEEPS GOING
=
Amazon, 2004 · $7B
one day of AWS, 2016
servers ← Dell / HP
chips ← Intel / AMD
switches ← Cisco / Juniper
fiber leased from carriers
its own servers
its own CPUs — Graviton
its own routers
its own fiber and cable stakes
its own protocol, not TCP
buy
build
$200B
a year · $500M a day

Vendor gear is built for thousands of machines. AWS runs millions.

100%
01the agenda Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent 7 techniques

Seven decisions, one recurring idea

the server you can't log into
01
its own network + protocol
02
cells — capped, never grown
03
shuffle sharding
04
constant work
05
Physalia — millions of tiny DBs
06
proofs, not sampling
07
7 things AWS built to scale

who this is for

SREs, platform engineers, architects — anyone building systems that have to survive their own growth.

Each one trades a little waste, or a little hardware, for a failure that stays small.

100%
02why any of this exists Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent millions of servers

Failure stops being an event. It becomes a rate.

MILLIONS OF MACHINES, RIGHT NOW
the myth: spare servers
retail peaks in december
teams rebuilt the same infra, over and over
Bezos: expose it all as hardened services
ran it for years — then sold the skill

failure is a rate

One-in-a-million per machine per day, times millions of machines, fires every single day.

"everything fails, all the time"
werner vogels, cto

You cannot engineer failures away at this size. You can only stop them becoming the customer's problem.

100%
03the virtualization tax Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent millions × a few %

Every cycle spent on Xen is a cycle nobody paid for

ONE HOST
Xen · in software
customer VMs
xen
customer
one server · the overhead looks small
entire datacenters running Xen

the scale rule

At normal size, paying this overhead is obviously right. At AWS's size it grew larger than the cost of building the hardware.

A few percent on one server is nothing. A few percent across millions is buildings, power and cooling.

100%
04nitro Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent $350M · Annapurna 2015

Move the hypervisor off the CPU entirely

NITRO · THE HYPERVISOR, TAKEN APART
cpu — yours now
thin hypervisor · partitioning only
virtual networking
EBS storage
local storage
security chip · verifies every byte before boot
before
after
Offload once, and every server built afterwards reclaims the cycles Xen used to take.

annapurna labs · 2015

A $350M acquisition became a one-time engineering investment. At millions of servers, removing a few percent of overhead is worth far more than designing the silicon costs.

What's left on the CPU is a sliver that only partitions the machine. The rest is yours.

100%
05the server no one can log into Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent no interactive login

Not even AWS can log in

OPS TEAM vs FLEET SIZE
no shell · no interactive login
a customer
an AWS engineer
every incident needs a human
remove the need for humans

a scaling decision, not just security

If every incident needs an SSH session, the ops team grows with the fleet. A server nobody can log into is one nobody can fat-finger.

what this unlocks

Bare metal is the same box with the thin hypervisor switched off. EC2 Mac is a Mac Mini on a Nitro card. Then Graviton.

AWS didn't make humans better at managing servers. It removed the need for humans to touch them.

100%
06its own routers Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent tens of thousands of routers

When it fails, what does the failure look like?

CLOS FABRIC · MANY EQUAL PATHS
a big chassis router
fails in ways that take a week
one commodity chip
working, or dead
one dies · traffic reroutes · capacity grows by adding boxes

simple failure scales

At ten routers the chassis wins. At tens of thousands, diagnosis time becomes the limit on growth.

A sophisticated router fails in sophisticated ways. Simple failure is the thing that scales.

100%
07its own fiber Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent own fiber · cable stakes

Owns the routers. Owns the fiber.

AWS BACKBONE · OWNED FIBER
undersea · ownership stake
the public internet
congestion event

between regions

AWS traffic between regions rides fiber AWS controls, including ownership stakes in the cables under the oceans. Between regions, AWS is not on the public internet at all.

A congestion event out on the public internet mostly cannot touch traffic that never goes there.

100%
08firing TCP Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent µs round trips

Three assumptions that stop being true indoors

THOUSANDS OF EQUAL PATHS
1 · TCP uses exactly one of them
2 · in-order delivery
one late packet holds the queue
RTT · µs
recovery · ms
1000× too slow
3 · millisecond recovery

not a tcp bug

All three assumptions are right for the open internet. None hold inside a datacenter AWS owns end to end.

TCP is doing its job perfectly. The world it was designed for isn't the world inside a datacenter.

100%
09SRD Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent 64 paths per flow

Reverse every assumption TCP made

ONE FLOW, SPRAYED EVERYWHERE
a switch dies
1 · up to 64 paths at once
4
1
6
2
7
3
5
2 · ordering dropped
reassembled by the layer above
3 · microsecond retransmit
A dead link costs one sixty-fourth of the flow. Retransmits land microseconds later on the other sixty-three.

tuned for one network

SRD only has to survive Amazon's own network — never the open internet — so it doesn't pay for that.

The flow was never on one path to begin with, so losing one path is barely an event.

100%
10cells Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent one cell = the cap

Refuse to let the service get bigger

GROW BY ADDING CELLS · NEVER BY GROWING ONE
one system, just bigger
size of the worst failure
size of the load test you'd need
production becomes the first real test
cell
cell
cell
cell
the failure stops here
routing layer · customer → cell
the one thing with no cell wall

why the cap matters

Load one full-size cell to its cap in test. That is the largest unit that will ever exist in production.

The unit never gets bigger. There are just more units.

100%
11the poison request Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent 8 workers · 1 poison

Retries walk the poison through the fleet

STANDARD DEFENCE · SHARDING
load balancer
one tenant · everyone down
the retry carries the poison forward
shard 1
shard 2
shard 3
shard 4
one tenant takes out 25% of customers

Sharding turns total failure into partial failure. Better, and still not good.

100%
12shuffle sharding Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent 75,287,520 combinations

Twenty-eight walls from eight machines

EIGHT WORKERS · UNCHANGED
the poisoned customer
shares one worker — retry lands healthy
28
ways to choose 2 from 8
1 in 28 fully down  ·  under 4%
hardware 8 → 100 = 12.5×
isolation 28 → 75M ≈ 2,700,000×

100 workers, choose 5

75,287,520 distinct combinations from a hundred machines. In practice you have more fault domains than customers.

route 53

The only AWS service with a 100% availability SLA for answering queries — no outage in almost two decades. The technique is open-sourced.

Hardware grows linearly. Isolation grows combinatorially.

100%
13the cost of sending changes Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent work scales with chaos

Efficient on a good day. Worst on a bad one.

AN UPDATE PER CHANGE, TO EVERYONE
a failover — thousands change at once
work scales with the chaos
replica A
replica B
one dropped message · silent drift

Change-based work peaks precisely when you can least afford it — and drifts silently the rest of the time.

100%
14constant work Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent same file, every few seconds

Do the same work whether nothing changed or everything did

SAME POT, ONE CUSTOMER OR A HUNDRED
one fixed-size file in S3
complete state, written every few seconds
every DNS server downloads the whole file
busiest day = quietest day
a barista
a coffee dispenser

deliberately wasteful

Most downloads carry almost no new information. That is the trade: a small predictable cost every few seconds, in exchange for behaviour that does not change under stress.

Waste a little, predictably, so that stress changes nothing.

100%
15the 2011 re-mirror storm Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent April 21, 2011

The degradation lasted days

APRIL 21, 2011 · US-EAST
a routine change reroutes EBS replication
beat 1
connectivity returns — everything re-mirrors at once
beat 2
all of them query the same shared database
beat 3
one database · every volume in the region
crashes under load
recovery stalls
volumes stay stuck
load stays high

the structural lesson

Every volume in the region shared one point of collapse — and every year adds volumes, which means a bigger storm aimed at the same database on the next bad day.

The postmortem lesson was structural, not procedural. One database, one region, one point of collapse.

100%
16physalia Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent millions of 7-node cells

Not a bigger database. Millions of smaller ones.

ONE TINY DATABASE PER VOLUME
the obvious fix
a bigger database — more CPU, more memory, more replicas
7 nodes · Paxos · one volume
was: a whole region
now: one volume

placement is the trick

Consensus needs a majority reachable, so Physalia puts each volume's seven nodes physically and topologically next to that volume's client and replicas.

a CP system

On a partition it chooses consistency — a configuration master has to — then wins it back through smallness and locality.

When a cell fails it takes out one volume's configuration. Not a region's.

100%
17proofs in production Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent 35-step failing trace

At this scale, prove it — don't sample it

THE STATE SPACE · SAMPLED
every test is sampling
Across millions of machines and billions of operations, the one-in-a-billion path runs somewhere on an ordinary afternoon.
a proof covers every execution

TLA+ · design verification

A model checker walks every reachable state. In DynamoDB it found a bug whose shortest failing trace was 35 steps.

Zelkova · IAM policies

The policy becomes a maths problem, and a theorem prover is asked whether any request under any conditions could make the bucket public — the engine behind the "Public" badge in the console.

not the requests someone thought to test

Every time you change a bucket policy, a theorem prover decides whether it can expose your data.

100%
18the journey of one launch Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent one VM launch

Seven decisions, one request

ONE VM LAUNCH, END TO END
04
shuffle sharding picks your combination
01
Nitro verified every byte before boot
02
SRD sprays the flow over 64 paths
06
your volume's own 7-node Physalia cell
05
constant work redistributes health state
07
a prover decided your bucket isn't public
nobody logged into any server — there is no way to

meanwhile

Disks failed, machines rebooted, a rack may have lost power. Your application never noticed.

Not hardware that never fails. Systems designed so those failures rarely become your problem.

100%
19what to steal Builders' Library · MacCárthaigh · Brooker · IEEE Micro · re:Invent 8 lessons

Eight things that port to systems far smaller than this

WHAT TO STEAL FROM ALL OF THIS

01  ·  small costs don't stay small

Multiply one machine's cost by the fleet you will eventually have.

02  ·  don't make humans scale with the system

If every incident needs an SSH session, the ops team becomes the ceiling.

03  ·  many small systems beat one shared giant

Easier to test, easier to reason about, and failures stay put.

04  ·  question your technology's assumptions

TCP was right for the internet and wrong for the datacenter.

05  ·  isolation can be an assignment, not hardware

Shuffle sharding bought 75 million fault domains from 100 machines.

06  ·  if it cannot fail, make its work constant

Waste a little every second so the worst day looks like every other.

07  ·  split the guaranteed bottleneck

Then place the pieces next to what they manage.

08  ·  testing has limits — sometimes prove it

At scale the one-in-a-billion path runs every day.

AWS's advantage isn't scale itself. It's having been forced to take these decisions seriously first.

100%