Medium · 8 steps · ~35 min

Design an auto-scaling web app on AWS

Let capacity follow the load, and learn why reacting is not the same as being ready.

Daytime traffic is ten times night-time traffic. Paying for daytime capacity all night wastes money; sizing for night fails by day. Auto scaling adds and removes tasks to follow the load, but it reacts after load rises, so the first minutes of a sudden spike are the risk.

Same problem as Consumer apps with daily peaksEvent sitesRetail promotions

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

• Application Auto Scaling can scale an ECS service's task count by target tracking, step scaling, scheduled scaling or predictive scaling.
• Target tracking and step scaling react to a CloudWatch metric, so capacity arrives after the load does. Scheduled and predictive scaling can add capacity ahead of time.
• Every scaling policy has a maximum you set. Beyond it, you need another way to cut load, such as caching.
• 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 fixed-size stack at 1,500 requests a second
2. An auto-scaled service for 5,000
3. An edge cache for a spike that outgrows the task maximum
4. A scaling plan for a predictable daily spike
5. A good scaling metric
6. Why scale-in is slow
7. Slow start
8. Paying for what you use at night

Steps

1. 1Serve 1,500 requests/s
2. 2Follow the load up to 5,000 requests/s
3. 3A spike beyond six tasks
4. 4A spike that arrives every morning
5. 5What should a scaling policy track?
6. 6Why scale-in is slow
7. 7New tasks and cold caches
8. 8Pay for what you use at night