Example implementations for availability goals
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. See Appendix A: Designed-For Availability for Select AWS Services for the design goals for the respective AWS services.
