Uptime is the time a website or application remains available to its users. High availability aims to keep interruptions short when components fail; it does not mean that every request survives a failure. A WordPress blog with several outages per month might set a target of 99.99% uptime, but that target must be checked against the availability of the whole system. section 2.0 section 16.0
Build for the failures each component can experience:
- Run multiple web servers in different data centers, with a load balancer checking their health and sending requests to healthy servers. A single virtual machine is not highly available by default. section 1.2.3
- For a production database, consider RDS Multi-AZ: a primary and standby run in different availability zones. RDS replicates data synchronously and automatically promotes the standby if the primary fails. section 10.5 section 10.5.1
- Check each service’s resilience rather than assuming all services behave alike. A single-node Redis cluster, for example, remains a single point of failure even though it supports backup and restore. section 13.3.2 section 11.2.2
Figure 1.5 Building a highly available system on AWS by using a load balancer, multiple virtual machines, and a database with primary-standby replication
The diagram connects the three main defenses: a health-checking load balancer, multiple virtual machines, and primary–standby database replication. section 1.2.3
Enable database high availability
For an existing WordPress RDS deployment managed by CloudFormation, set `MultiAZ: true` on the `AWS::RDS::DBInstance` resource and update the stack. Deployment takes several minutes. The standby adds cost, but Multi-AZ can also reduce downtime during database maintenance. Failover can still interrupt requests briefly. section 10.5.1 section 10.5
Monitor availability from outside the application, too. One health check runs a Lambda function every five minutes using an EventBridge rule. The function requests the website and checks its response; a CloudWatch alarm emails an operator when checks fail. Monitoring reveals an outage—it does not itself prevent one. When setting an uptime target, inspect the SLA and resilience documentation for every AWS service the application depends on. section 6.2 section 13.3.2
