A Region is a geographic deployment area, while an Availability Zone is an isolated location within a Region. High availability comes from placing redundant service capacity across independent zones, routing around unhealthy capacity, and ensuring that state, dependencies, and operational procedures do not reintroduce a single point of failure.
Who this is for: Developers and operations teams choosing deployment locations and designing services that must tolerate infrastructure failures.
- Choose Regions from user latency, legal, service-availability, and recovery requirements rather than proximity alone.
- Spread replaceable capacity across zones and examine every shared dependency for hidden concentration.
- Prove availability with controlled failure tests and measured recovery, not an architecture diagram by itself.
Understand the failure boundaries
Cloud providers divide infrastructure into Regions and zones so customers can make deliberate placement choices. A Region contains multiple Availability Zones connected by provider networks. A zone is intended to isolate many local failures, but it is not a guarantee against every correlated event. Service definitions, zone counts, and feature availability vary, so current provider documentation belongs in the design review.
Treat these labels as architectural boundaries, not decorative location names. Two servers in one zone can survive a process crash but not a zone loss. Two zones in one Region improve local resilience but do not cover a regional disruption. Multi-Region operation adds another recovery boundary, along with significant data, routing, deployment, testing, and cost responsibilities.
Translate business needs into topology
Begin with an availability objective and a catalog of important user journeys. Ask how much interruption and data loss each journey can accept. Then select a topology that meets those requirements. A stateless web tier commonly runs in at least two zones behind health-aware routing. A development preview may accept one zone because recovery speed matters less than simplicity and expense.
Region choice also depends on customer location, data residency, required managed services, support constraints, and dependency locations. A second Region is useful only if the application can actually start there with current code, configuration, identity, networking, and data. Document which failures the design covers and which events still require restoration or manual decisions.
Remove single points of failure
Trace one request through DNS, edge services, load balancing, compute, queues, databases, caches, identity, and external providers. For each component, identify its zone placement, health signal, replacement method, and behavior when a peer disappears. Redundant application instances do little if all outbound traffic uses one zone-bound appliance or every worker depends on one manually managed host.
State needs special care. Use a data service whose replication and failover behavior matches the objective, then understand what consistency and recovery guarantees it provides. Keep backups separate from live replicas because replication can copy accidental changes. Capacity planning must leave enough healthy-zone headroom to handle traffic after one zone is unavailable.
Test graceful degradation and recovery
Use non-destructive exercises in a controlled environment before production experiments. Remove a test instance from service, block test traffic to one zone, or scale a zone's test capacity to zero through approved tooling. Observe health-check timing, connection behavior, queue growth, error rates, and operator alerts. Define stop conditions and a rollback path before the exercise begins.
A successful test shows that critical journeys remain within their objective and that the team can restore normal placement without guesswork. Record detection time, failover time, lost work, customer impact, and manual steps. Feed the findings into capacity limits, runbooks, and future tests. Recheck after architectural, dependency, or traffic-pattern changes.
Design a two-zone order API
A retailer has a stateless API in one zone and needs checkout to continue during a single-zone failure.
- Place identical API capacity in two zones behind a load balancer with an application-level health endpoint.
- Confirm the managed database deployment, cache, queue, network egress, and secret access each have suitable cross-zone behavior.
- Reserve enough capacity so one healthy zone can serve critical checkout traffic at an intentionally degraded level.
- Run a staged test that withdraws the test targets in one zone, observes service indicators, and restores them through the normal deployment path.
Availability boundary review
Complete one row for every component on a critical request path.
- Component, owner, critical user journey, and maximum acceptable interruption.
- Region and zone placement, redundancy model, health signal, and failover trigger.
- State behavior, replication scope, backup boundary, and acceptable data loss.
- Surviving capacity, degraded mode, dependency concentration, and scaling limit.
- Test method, stop condition, restoration steps, evidence, and next review date.
Common mistakes
- Calling two instances highly available when both run inside the same zone.
- Adding a second Region without automating current data, configuration, identity, and deployment there.
- Running a failure exercise without a defined blast radius, stop condition, or restoration owner.
Try one
A service runs six application instances across three zones, but every instance writes through one self-managed proxy in a single zone. Evaluate the design and propose a safe next step.
The application count does not remove the proxy as a single point of failure. A strong answer maps the write path, confirms whether the proxy holds state, evaluates a zone-redundant managed or replicated design, and tests failover with non-production traffic first. It also checks surviving capacity and avoids changing production before rollback and ownership are clear.
Sources
- AWS Regions and Availability ZonesOfficial AWS reference for the geographic and failure-isolation structure of Regions and Availability Zones.
- AWS Well-Architected Reliability PillarOfficial AWS design principles and practices for reliable workloads and recovery planning.