Easy · 8 steps · ~40 min

Design a site and API on AWS

Serve a growing site with an edge cache, containers and a managed database.

Your product is a website with an API behind it. Most requests read data that rarely changes; a few write. You will build the classic AWS web stack and grow it from hundreds to tens of thousands of requests a second, adding a component only when a number says you need it.

Same problem as Marketing and news sitesE-commerce storefrontsSaaS web apps

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

• Amazon CloudFront caches responses at edge locations, so most reads never reach your servers. Only GET responses are cached; writes always go to the origin.
• An Application Load Balancer spreads requests across ECS tasks and sends traffic only to targets that pass health checks.
• Aurora holds the data. It has one writer and up to 15 readers, so reads scale out but writes do not.
• 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 load balancer, a container service and a database for 600 requests a second
2. A cache or readers that protect the database at 8,000
3. CloudFront in front for 30,000 requests a second
4. A monthly budget: do you still need the cache?
5. A design that survives losing a task
6. How health checks move traffic away from a failed zone

Steps

1. 1Serve 600 requests/s
2. 2Handle 8,000 requests/s
3. 3Put CloudFront in front at 30,000 requests/s
4. 4Invalidate everything at once
5. 5Keep the provisioned bill under $900 a month
6. 6Lose a task
7. 7Survive an empty edge cache
8. 8Health checks decide how long users see errors