CloudArcade

Guided architecture tour · 6–8 min

Grow when the crowd arrives — EC2 Auto Scaling

Plan a group of servers that can grow and shrink with demand.

This tour teaches architecture decisions. Its services are not provisioned in the emulator.

Your goal

Plan a group of servers that can grow and shrink with demand.

Why this matters

A game is quiet in the morning and busy after school. You will set a safe range, choose a demand signal, and keep important data safe when servers leave.

Words you will use

Scaling out adds instances. Scaling in removes them. Desired capacity is the number the group is trying to run.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

Play this architecture tour

1. Set a safe range

The app needs at least two servers and can use up to six in this exercise. Right now you want three. Choose the group settings.

Which settings express that plan?

Minimum 2, desired 3, maximum 6.

The minimum and maximum bound the group. Desired capacity says how many instances it should try to run now. Real quotas and available capacity also affect launches.

The group has a clear starting size and limits.

MinSize: 2
DesiredCapacity: 3
MaxSize: 6

2. Watch useful demand

After school, requests rise and the app slows down. You want capacity to respond to demand instead of a decorative change on the page. Choose a useful signal.

What could drive a scaling policy?

A measured load signal that fits the app, such as average CPU.

A scaling policy needs a measurement related to load. Test your chosen target and allow time for new instances to become ready. More servers do not fix every bottleneck.

The policy responds to measured demand within its configured limits.

Load metric → scaling policy → desired capacity

3. Prepare for servers to leave

When traffic falls, a server may be removed. Its local files contain the only copy of customer uploads. Choose a safer app design before enabling scale-in.

Where should lasting uploads live?

In suitable shared or durable storage outside that disposable server.

Treat replaceable servers as temporary workers. Keep important state in a service designed to outlive them, and let in-flight work finish safely when removing a worker.

Losing one worker does not lose the only copy of customer data.

Temporary workers → durable application storage

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.

Continue with another AWS learning guide