Resiliency

Resiliency means designing a system to handle disruption without unacceptable loss of service or data. Disruptions include hardware failures, network interruptions, software defects, traffic spikes, and operator mistakes. A resilient system may continue operating normally, provide reduced functionality, or recover within an agreed time. The appropriate behavior depends on business requirements rather than an assumption that every component must remain available continuously.

A central cloud design principle is to distribute resources across independent failure domains. In AWS, a Region contains multiple Availability Zones. Each Availability Zone consists of one or more discrete data centers with redundant power, networking, and connectivity. Availability Zones within a Region are physically separated and designed to avoid shared infrastructure single points of failure, so a power or facility failure in one zone should not disable the others. They are connected through low-latency networking that supports applications spanning multiple zones.

This isolation is the key distinction tested in foundational certification questions: multiple servers in one Availability Zone do not provide the same protection as servers distributed across multiple Availability Zones. However, zone isolation does not guarantee that an application has no shared dependencies. A database deployed only in one zone, a shared external dependency, or a defective deployment applied everywhere can still disrupt the entire workload.

For example, an online store can run stateless application servers across two or more zones behind a load balancer. If servers in one zone become unreachable, health checks allow traffic to move to healthy targets. The remaining servers need enough capacity to carry the load, and the database and session storage must also support the intended failure scenario. Merely adding servers in another zone is insufficient when all requests depend on a single-zone database.

Recovery design must address both service restoration and data protection. A recovery time objective defines the target time to restore service, while a recovery point objective defines the acceptable amount of data loss measured in time. Replication can support rapid failover, but it may also propagate accidental deletion or corruption. Backups provide a separate recovery mechanism, and restore tests establish whether those backups can meet recovery objectives.

Resiliency has costs and operational trade-offs. Redundant capacity, replication, monitoring, and testing increase spending and complexity. Cross-zone communication can introduce data-transfer charges, while cross-Region designs add latency and data-consistency considerations. Multi-zone deployment addresses zonal failures; protection against a regional disruption requires a separate regional recovery strategy appropriate to the workload.

Resiliency is broader than high availability or fault tolerance alone: it also includes recovery and adaptation after disruption. Engineers should test failover, verify capacity after losing a zone, and practice restoration procedures. Bounded retries, timeouts, and graceful degradation help prevent a failing dependency from exhausting otherwise healthy components. Provider infrastructure supplies isolation mechanisms, but application configuration and operational practices determine whether the workload benefits from them.