Easy · 8 steps · ~30 min

Protect a public API from a traffic surge

Absorb a viral spike at the edge so your quotas hold, and throttle the right clients.

A public API gets featured on a popular site and traffic jumps twentyfold. Its backend is API Gateway, Lambda and DynamoDB, each with quotas. You will keep the backend inside its limits with an edge cache, and learn how throttling signals overload to clients.

Same problem as Public developer APIsLaunch-day pagesTicket drops

This lab uses real AWS services. Limits are AWS's documented default quotas; figures AWS does not publish are marked as assumptions on each component. See every source and assumption.

How it works

• API Gateway uses a token bucket: once request submissions exceed the steady-state rate and burst limits, clients receive HTTP 429 Too Many Requests and should retry with backoff.
• Throttling can be set lower than the account limit per stage, per method, or per client through a usage plan. AWS describes these as best-effort targets, not guaranteed ceilings.
• CloudFront caches only GET responses. Writes and uncacheable requests always reach the origin.
• Limits come from AWS documentation (default quotas in us-east-1). Where AWS publishes no figure, such as how many requests a container or database handles, the lab states its assumption on the component.

What you'll build

1. A serverless backend at 2,000 requests a second
2. CloudFront in front for a 40,000 requests a second surge
3. What clients see when the throttle is exceeded
4. How to limit one noisy client without limiting everyone
5. A write-heavy surge
6. An empty edge cache
7. What CloudFront may cache
8. Throttling per stage or method

Steps

1. 1Serve 2,000 requests/s
2. 2Survive a 40,000 requests/s surge
3. 3What does a throttled client see?
4. 4One noisy client
5. 5A write-heavy surge
6. 6Survive an empty edge cache
7. 7What may CloudFront cache?
8. 8Throttle one stage, not the account