Example implementations for availability goals
Note
The example scenarios presented in this section do not represent actual availability for real-world workloads on AWS. These sections are intended to illustrate architectural considerations and guide high-level thinking when designing for different availability goals. Actual workload availability depends on specific business requirements, workload design, and operational constraints that extend beyond AWS services and infrastructure.
Tailor your architecture to the unique demands of your workload and thoroughly assess availability requirements for your environment.
In this section, we’ll review workload designs using the deployment of a typical web application that consists of a reverse proxy, static content on Amazon S3, an application server, and a SQL database for persistent storage of data. For each availability target, we provide an example implementation. This workload could instead use containers or AWS Lambda for compute and NoSQL (such as Amazon DynamoDB) for the database, but the approaches are similar. In each scenario, we demonstrate how to meet availability goals through workload design for these topics:
| Topic | For more information, see this section |
|---|---|
| Monitor resources | Monitor workload resources |
| Adapt to changes in demand | Design your workload to adapt to changes in demand |
| Implement change | Implement change |
| Back up data | Back up data |
| Architect for resiliency | |
| Test reliability | Test reliability |
| Plan for disaster recovery (DR) | Plan for Disaster Recovery (DR) |
Dependency selection
We have chosen to use Amazon EC2 for our applications. We will show how using Amazon RDS and multiple Availability Zones improves the availability of our applications. We will use Amazon Route 53 for DNS. When we use multiple Availability Zones, we will use Elastic Load Balancing. Amazon S3 is used for backups and static content. As we design for higher reliability, we must use services with higher availability themselves.
