Prime Day: AWS stress-testing itself

The meter readings

Prime Day is the rare case where a hyperscale operator tells you exactly how hard its systems were pushed. After each event the AWS News Blog publishes the per-service peaks, and the numbers have grown into a yearly time series. For Prime Day 2024 (a 48-hour event Amazon itself called its biggest ever), DynamoDB peaked at 146 million requests per second while still delivering single-digit millisecond responses; the callers included Alexa, the Amazon.com sites, and all Amazon fulfillment centers, which together made tens of trillions of DynamoDB API calls over the event. Aurora ran 6,311 database instances that processed more than 376 billion transactions. Amazon ECS launched 77.24 million tasks for the event, CloudFront served over 1.3 trillion HTTP requests with peaks above 500 million requests per minute, Lambda handled over 1.3 trillion invocations, and ElastiCache served more than a quadrillion requests with a peak above 1 trillion requests per minute.

The queue numbers tell the same story from the messaging side. SQS peaked at 86 million messages per second in 2023, up 22 percent from 70.5 million in 2022, and set a new record of 166 million messages per second during Prime Day 2025, an event where DynamoDB reached 151 million requests per second and Kinesis Data Streams ingested a peak of 807 million records per second. None of these are marketing round numbers; they are specific enough to reason about, and the ratios between them are where the architecture lessons live.

The part that matters most for an architect is what happens before the event. AWS states plainly that rigorous preparation is the key to Prime Day, and for 2024 it quantifies one piece of it: teams ran 733 AWS Fault Injection Service experiments to test resilience and confirm Amazon.com would stay available under failure. Capacity is scaled up and rehearsed ahead of time rather than discovered during the spike; the blog posts point external customers at the same playbook through the newly-branded AWS Countdown support program. Prime Day is not survived by heroics on the day. It is survived by provisioning, load testing, and breaking things on purpose in the weeks before.

Before the spike: load testing, fault injection, and pre-warmed capacityFullscreen

TraceRehearse: inject failure into the fleetLoad test: replay traffic, read the meterPre-warm capacity ahead of the spike

Following a request through peak

AWS does not publish a wiring diagram of amazon.com. What it publishes are per-service peaks, and those peaks fix the shape of the traffic path. Walk a shopper's request through the canonical version of that path, and pin each hop to a published number.

Step one is the edge. A product-page request terminates at CloudFront, which absorbed peaks above 500 million requests per minute in 2024 and served 1.3 trillion requests over the two days (over 3 trillion by 2025). Static assets, images, and cacheable page fragments never travel farther than an edge location, so the origin fleet only sees what the CDN cannot answer.

Step two is the horizontally scaled app tier. Requests that pass the edge land on load balancers fronting an enormous, disposable fleet: 77.24 million ECS tasks launched for Prime Day 2024, with more than 250,000 Graviton chips powering over 5,800 distinct Amazon.com services. Nothing in this tier is precious. Scale comes from adding interchangeable tasks, not from growing any single box.

Step three is the read path, and it is cache-first. ElastiCache peaked above 1 trillion requests per minute, roughly 16 billion per second, while DynamoDB behind it peaked at 146 million requests per second. Read the ratio: the in-memory tier absorbed on the order of a hundred times more traffic than the database it protects. That is the entire job of a cache layer, stated in production numbers. What does reach DynamoDB is the hot key-value workload (sessions, carts, catalog items, fulfillment state), which is exactly the access pattern DynamoDB is built for: horizontal partitioning with single-digit millisecond latency that holds at 146 million requests per second.

Step four is the write path, and it is buffered. A checkout does not need every downstream system to answer synchronously; it needs the order accepted durably and processed reliably. This is where SQS's published peaks (86 million messages per second in 2023, 166 million in 2025) come in. A queue between the front end and the downstream consumers means the web tier enqueues and returns, while consumers (Lambda handled over 1.3 trillion invocations in 2024) drain the queue at their own sustainable rate. A surge becomes queue depth instead of cascading timeouts. Behind the consumers sit the transactional stores: Aurora's 376 billion transactions across 6,311 instances is a huge number, yet averaged over the event it is orders of magnitude below DynamoDB's request rate. The relational tier handles the fewer, richer, multi-row transactions; the NoSQL tier handles the flood.

Following a request through peak: edge, fleet, cache-first reads, queue-buffered writesFullscreen

TraceRead path: product page, cache-firstWrite path: checkout buffered through SQSEvent stream: replayed by multiple readers

What this teaches for the exam

For task 2.1, designing scalable and loosely coupled architectures, Prime Day is the reference answer key. Horizontal scaling: 77 million ECS tasks and a fleet of interchangeable services is what 'scale out, not up' looks like at the limit, and exam answers that grow an instance size where a fleet could grow instead are usually wrong. Loose coupling: the SQS numbers are the proof that queues are not a niche integration tool but the primary shock absorber of the world's largest retail event; when a scenario mentions traffic spikes, producers outpacing consumers, or protecting a downstream system, the answer is a queue (SQS) or a stream (Kinesis, 807 million records per second on Prime Day 2025), chosen by whether messages are consumed once or replayed by multiple readers. Edge acceleration: CloudFront in front of the origin is why the origin math works at all. And event-driven serverless: over a trillion Lambda invocations paired with SQS is the exam's favorite consumer pattern, because the consumer fleet scales with queue depth instead of being provisioned for the worst minute of the year.

For task 3.3, high-performing database solutions, the numbers teach database selection better than any feature table. DynamoDB at 146 to 151 million requests per second with single-digit millisecond latency is the answer shape for massive, key-based, horizontally partitioned workloads; Aurora's 376 to 500 billion transactions is the answer shape for relational integrity at high but far lower request rates. When an exam question gives you a simple access pattern at extreme scale, that is DynamoDB; when it gives you joins, complex transactions, or existing SQL, that is Aurora. The ElastiCache ratio is the third lesson: put an in-memory cache in front of read-heavy workloads and the database only sees misses, which is why 'add ElastiCache' beats 'add read replicas' when the working set is hot and repetitive, and why read replicas are the answer when reads are varied and must hit the engine.

The final lesson is about preparation, and it generalizes past any single service. Amazon ran 733 fault-injection experiments before Prime Day 2024 and scales capacity ahead of the event rather than reacting to it. On the exam, that mindset shows up as pre-warming and scheduled scaling for known events, load testing against production-shaped traffic, and designing so a component failure degrades the experience instead of ending it. The published Prime Day record is what you get when over-provisioning, buffering, and rehearsed failure are treated as the plan rather than the fallback.

The exam answer key: scale out, decouple, cache, and pick the right storeFullscreen

TraceConsumed-once: queue to relational commitReplay: stream fans out to many readersCache the hot set, DynamoDB for misses