How do you design multi-zone autoscaling?

Direct answer

What a strong answer covers

How it works

Availability zones fail independently, so stateless capacity is spread across at least three and the minimum size is set so that losing one zone still leaves enough to serve peak. The load balancer routes only to instances that pass health checks, and health checks test the application rather than the port. Scaling policies use the demand signal that actually constrains the service, such as request count per target or queue depth, with cooldowns and step sizes tuned so the group does not oscillate, and scale-in is protected so a brief dip does not remove capacity that will be needed a minute later. Stateful dependencies such as databases and caches need their own multi-zone story or they become the single point of failure.

Example

An API runs in an autoscaling group across three zones with a minimum of six instances, sized so four can carry peak; target tracking keeps requests per instance near 800, scale-out reacts in one minute and scale-in waits ten. The database is a multi-zone primary with a synchronous standby, and the Redis cluster has replicas in each zone. A zone outage last year removed two instances and the group replaced them in the other zones within three minutes with no user impact.

Common mistakes

• Setting the minimum so that a zone loss drops below the capacity needed for peak.
• Scaling on CPU when the service is bound by database connections.
• Making the web tier multi-zone while the cache lives in one zone.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.