High availability and fault tolerance are related AWS architecture goals, but they are not synonyms. Availability is the proportion of time a workload performs its agreed function when required. Resilience is the ability to recover from disruptions and continue meeting demand. Fault tolerance is a stronger design posture in which failures are absorbed with little or no interruption because healthy resources continue serving the workload.<\/p>\n
AWS Well-Architected reliability guidance frames the problem around expected function, component failure, recovery, multi-location design, automation, and operational readiness. The correct architecture depends on the business target; maximum redundancy is not automatically the best design.<\/p>\n
Architecture should begin with required service level rather than a preferred AWS pattern. A noncritical internal tool and a payment platform do not need the same resilience investment.<\/p>\n
Define availability expectations, maximum acceptable outage, data-loss tolerance, geographic requirements, and the business impact of failure.<\/p>\n
Those requirements drive whether the design needs multi-AZ availability, cross-region recovery, active-active traffic, or a simpler backup-and-restore approach.<\/p>\n
Translate availability percentage into tolerated downtime over a relevant period so stakeholders understand the practical consequence of the target.<\/p>\n
Identify peak business periods where downtime has unusually high impact; a uniform monthly target may hide critical windows.<\/p>\n
Include dependency SLAs because the application cannot be more available than critical third-party or internal services without compensating design.<\/p>\n
Document maintenance expectations separately from unplanned downtime. Some businesses tolerate planned windows while others require continuous service through upgrades.<\/p>\n
Define which user journeys are critical. A workload can be partially available while one important transaction is failing, so availability should reflect the function users actually need.<\/p>\n
Review the target periodically as the product changes; a service that was once noncritical can become a revenue or regulatory dependency that justifies a stronger resilience design.<\/p>\n
High availability commonly uses redundant components, health checks, load balancing, multi-AZ deployment, managed failover, and capacity that can continue serving requests after a component fails.<\/p>\n
AWS recommends distributing production workloads across multiple Availability Zones where appropriate. Separate AZ infrastructure reduces correlated failure compared with a single location.<\/p>\n
High availability does not mean zero downtime. It means the system is designed to meet an availability objective through redundancy and recovery.<\/p>\n
Use health checks that reflect service usefulness, not only process existence. A server can respond to TCP while the application is unable to complete a transaction.<\/p>\n
Capacity should survive the designed failure. If losing one AZ leaves insufficient capacity in the remaining zones, the topology is redundant but not highly available under that scenario.<\/p>\n
Test deployment and maintenance so planned changes do not remove all redundancy at once.<\/p>\n
Load balancing needs healthy targets and sensible health checks. A failed dependency can make all instances unhealthy simultaneously even when compute redundancy is high.<\/p>\n
State and session design matter. Sticky sessions or local state can prevent traffic from moving cleanly to healthy instances.<\/p>\n
Fault-tolerant systems aim to absorb failures without a visible service interruption or with very small impact. That often requires spare capacity, replicated state, redundant paths, and automated failover.<\/p>\n
The architecture must eliminate single points of failure across compute, data, network, identity, and other critical dependencies.<\/p>\n
Fault tolerance can cost more and create more operating complexity, so it should be reserved for workloads whose business requirement justifies it.<\/p>\n
Stateful systems make fault tolerance harder because data consistency and write authority must be preserved while components fail.<\/p>\n
Use quorum, replication, managed failover, or application design appropriate to the datastore rather than assuming active-active is always possible.<\/p>\n
Consider dependency fault tolerance as well: DNS, identity, network egress, secrets, and queues can become single points of failure even when compute is redundant.<\/p>\n
Fault-tolerant systems should degrade gracefully when full functionality cannot be preserved. Read-only mode or delayed processing may be better than complete outage for some workloads.<\/p>\n
Design bulkheads so failure in one customer, queue, region, or dependency does not exhaust shared resources for everyone.<\/p>\n
Document which failures the system is designed to tolerate and which remain accepted risks so stakeholders do not assume fault tolerant means invulnerable.<\/p>\n
AWS Regions contain multiple Availability Zones with isolated physical infrastructure and low-latency connectivity. Many managed services can replicate or fail over across AZs.<\/p>\n
Multi-AZ resilience<\/a> should be designed end to end. A web tier in three AZs is not enough if the database, NAT path, or another critical service remains single-AZ.<\/p>\n Review every dependency against the same failure model.<\/p>\n Distribute independent resources rather than duplicating a shared dependency across zones while keeping one central failure point.<\/p>\n Review NAT, load balancer, database, cache, storage, and control dependencies against AZ loss.<\/p>\n Use AWS managed services where their regional multi-AZ design fits the requirement, but understand the service\u2019s actual failure and recovery model.<\/p>\n Use zonal isolation deliberately. If every AZ depends on one shared appliance or one improperly deployed endpoint, the architecture may remain vulnerable to a single failure.<\/p>\n Capacity planning should assume the loss of the largest zone if that is part of the target resilience model.<\/p>\n Cross-region design can address regional impairment, data-residency strategy, global users, or disaster-recovery objectives that a single region cannot meet.<\/p>\n It also adds replication lag, DNS\/traffic management, consistency, deployment coordination, security duplication, observability, testing, and cost.<\/p>\n AWS guidance warns against using multi-region complexity when multi-AZ architecture already satisfies the business requirement.<\/p>\n Decide how data moves between regions and what consistency trade-off is acceptable. Replication can introduce lag or conflict that the business must understand.<\/p>\n Define traffic-steering and failback as well as failover. Returning to the original region after recovery can be as risky as the initial switch.<\/p>\n Exercise regional recovery periodically; documentation written once is not evidence that dependencies still work.<\/p>\n Data sovereignty and regulatory boundaries may constrain which regions can hold or process data.<\/p>\n Keep configuration synchronized through tested deployment pipelines so disaster recovery does not fail because the secondary region drifted from production.<\/p>\n Recovery Time Objective defines how quickly service must return; Recovery Point Objective defines how much data loss is acceptable.<\/p>\n Backup-and-restore, pilot light, warm standby, and active-active\/multi-site patterns offer different cost and recovery characteristics.<\/p>\nMulti-region architecture is for a different class of failure<\/h2>\n
Recovery objectives determine the DR pattern<\/h2>\n