3.2High Availability and Self-Healing

The rule of HA is to eliminate single points of failure. Add redundancy across AZs, and contain faults with decoupling and self-healing.

3.2.1Means of HA and self-healing

• Multi-AZ: redundancy across AZs to survive a single-AZ failure (e.g., RDS Multi-AZ).
• Decoupling: separate components with SQS/SNS to contain faults.
• Self-healing: Auto Scaling auto-replaces instances failing health checks.
• Route 53 failover: switch to another region on regional failure (health-check driven).

DOP-C02 availability design asks "against which failure domain, and how far you automate recovery." Multi-AZ is the basis for surviving a single-AZ failure: RDS Multi-AZ auto-fails over to a standby via synchronous replication, and Aurora spreads storage across 3 AZs / 6 copies. For decoupling, chains of synchronous calls cause cascading failures, so buffer with SQS to absorb consumer-side failures and fan out with SNS/EventBridge to separate publishers from subscribers; queue + Auto Scaling (scaling on queue depth) also follows backpressure. Self-healing adds, beyond auto-replacing health-check failures, EventBridge + Lambda/SSM Automation to automate "alarm → isolate → run recovery runbook." For region-scale failures, use Route 53 health checks + failover routing (active/passive) or latency/weighted routing for distribution, and keep the data tier in step with cross-region replication (S3 CRR, Aurora Global Database, DynamoDB global tables). To validate the design, evaluate RTO/RPO attainment against policy with AWS Resilience Hub and run chaos experiments with the Fault Injection Service (FIS) to confirm it self-heals as expected. Going stateless (state in DynamoDB/ElastiCache/external stores) is the prerequisite that makes all this automated recovery work.

3.2.2AWS Resilience Hub — resilience assessment and continuous tracking

Resilience Hub evaluates, visualizes, and continuously tracks your application's resilience—how well it meets its RTO/RPO objectives. First, register the application's resources (CloudFormation stacks, Terraform state, AppRegistry, etc.) and define a resiliency policy (target RTO and RPO). The service then analyzes the configuration to identify single points of failure, gaps, and improvement recommendations (e.g., make a component Multi-AZ). Recommendations are concrete actions ("distribute this target group across multiple AZs") that can be re-evaluated after remediation to confirm improvement. In continuous-assessment mode (CI/CD pipeline integration), the service automatically re-evaluates on every infrastructure change, detecting early when a change breaks the RTO/RPO target. Integration with AWS Fault Injection Service (FIS) allows combining chaos experiments with quantitative resilience assessment. In a DevOps context the typical use is "embed Resilience Hub in CI/CD as a quantitative gate instead of a design review"—continuous drift monitoring is what distinguishes it from a static architecture review.

• Policy definition: set target RTO/RPO, analyze configuration statically, surface single points of failure.
• Improvement recommendations: propose concrete actions (Multi-AZ, add backup, etc.) and re-evaluate after fixes.
• Continuous assessment (CI/CD): re-evaluate automatically on each deploy to detect policy-violation drift early.
• FIS integration: combine with chaos experiment results to empirically validate resilience.

3.2.3Network connectivity — HA for multi-account and hybrid architectures

In multi-account and hybrid-cloud configurations, network connectivity design is the foundation of high availability. Transit Gateway centrally connects many VPCs and on-premises networks in a hub-and-spoke topology. VPC peering is point-to-point, so the wiring becomes a full mesh as account count grows, causing management cost to explode; aggregating into Transit Gateway centralizes route management and maintains redundancy without a single point of failure. PrivateLink connects privately from an endpoint (interface endpoint) inside a VPC to AWS or third-party services without traversing the internet. Traffic bypasses public IPs and internet gateways, establishing service connectivity while maintaining the security boundary. Client VPN establishes a TLS-based VPN from individual clients (laptops, etc.) to an AWS VPC—used for employee remote access in combination with client certificates or SAML authentication. Site-to-Site VPN IPsec-encrypts the connection between an on-premises site and an AWS VPC. Two tunnels are provisioned automatically, providing redundancy if one fails. When bandwidth requirements are high it is often combined with dedicated Direct Connect, with the VPN used for failover or supplemental connectivity.

3.2.4Section summary

• HA = Multi-AZ + decoupling (SQS/SNS)
• Self-healing = health checks + auto-replace / failover = Route 53
• Resilience assessment = Resilience Hub (continuous RTO/RPO tracking; CI/CD integration)
• Network HA = Transit Gateway (multi-VPC hub) + PrivateLink (private connectivity) + Client/Site-to-Site VPN (hybrid)