CloudArcade

Guided architecture tour · 6–8 min

Keep serving when one location has trouble — Regions and Availability Zones

Plan an app that can tolerate a failure in one Availability Zone.

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

Your goal

Plan an app that can tolerate a failure in one Availability Zone.

Why this matters

A single-location app has a single-location outage risk. You will place app copies across zones, check the supporting data path, and test whether the remaining capacity can serve users.

Words you will use

A Region is a geographic AWS area. Availability Zones are separate locations within a Region. Redundancy means having another usable copy when one component fails.

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. Choose the failure boundary

Two app servers run in the same Availability Zone. They protect against some server failures but share a larger location risk.

What improves zone-level resilience?

Placing suitable app capacity in multiple Availability Zones.

Spread suitable resources across zones to reduce dependence on one location. Availability Zones are distinct locations within a Region. This design addresses a different failure scope from a separate-Region recovery plan.

The app is less dependent on one zone.

App copies in multiple zones → reduced location dependency

2. Check the whole request path

The web servers span two zones, but both depend on one database with no planned failover. The app can still lose its essential data service.

What should you review?

Load balancing, data availability, and every critical dependency.

Resilience is limited by the full path a request needs. Review traffic routing, stateful services, and shared dependencies. Multiple app copies do not help when the only required dependency is unavailable.

The design addresses critical dependencies as well as app copies.

Request path → dependency review → appropriate resilience

3. Test the remaining capacity

The team has two zones but each normally runs near its capacity limit. Losing one could overwhelm the other.

What should be tested?

Failure behavior and whether healthy capacity can carry the needed load.

Test a controlled failure scenario and observe routing, error rates, and remaining capacity. Plan the acceptable level of service during disruption. Redundant placement is useful only when the surviving path can do the required work.

The resilience claim is backed by a meaningful capacity test.

Controlled failure → healthy routing → measured service level

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