Let us start by designing a generic high-availability architecture for an Amazon region. High availability can be architected in many different ways depending on the services used and the requirements. Here, we present a very generic architecture. The key to achieving high availability is to avoid single point of failures (SPOF) or application failures resulting from any one of the components or services fails. This implies that we have to account for all the Amazon services that can fail in a region; in our case, these are as follows:

• Availability zone (AZ)
• EC2 instances (EC2)
• Elastic load balancer (ELB)
• Relational Database Service (RDS)

Out of these, ELB and RDS are already designed for high availability and just need to be configured to support high availability as per the architecture. The application is hosted in the US West Region, and the architecture is designed to handle failures within a Region and not across regions.

• Availability Zones: An Availability Zone is equivalent to a data center. They are in distinct physical locations and are engineered to isolate failure from each other. The application is hosted in more than one availability zone to isolate them from these failures. The decision on how many Availability Zones to use for an application depends on how critical the application is and the costs involved. Using multiple AZs removes the SPOF for applications using a single AZ.
• Elastic Load Balancer: All the traffic is routed via the elastic load balancer to the applications. This piece of infrastructure is fault tolerant by design. ELB needs to be configured for routing traffic to the application hosted in different AZs. In addition, the ELB also performs health check on all the EC2 instances registered with it and only routes traffic to healthy EC2 instances. AWS replaces an unhealthy ELB; hence, the SPOF at the load balancer tier is no longer a problem.
• EC2 Instances: An EC2 instance is the most vulnerable component in the chain. It is the most complex in terms of the deployment of your software application and the supporting software stack. Any failure in the software stack or the application can potentially render the application to be unavailable. To cover this, an Auto Scaling group (ASG) is used that monitors and launches EC2 instances based on the configuration of alarms and the configured number of maximum, minimum, and desired EC2 instances per availability zone. This addresses the SPOF at web server/application tier.
• Relation Database Service: The last in the chain is the database. The RDS service provides high availability and failover using Multi-AZ deployments. The RDS creates a database instance in two AZs with one of them designated as the master and the other a standby replica or slave instance. The master and standby databases are synchronized via synchronous data replication. All the EC2 instances write to the database via a FQDN or an endpoint. Behind the scenes, the RDS service routes the writes to the current master database instance. With Multi-AZ, you can’t access the inactive secondary database until the primary fails. If the primary RDS instance fails, the DNS CNAME record is updated to point to the new master. If the standby fails, a new instance is launched and instantiated from the primary as the new standby. Once failover is detected, it takes less than a minute to switch to the slave RDS instance. Multi-AZ deployment is designed for 99.95% availability. In addition, RDS can be configured to snapshot the database at regular intervals that helps during disaster recovery. This addresses the SPOF in the database tier.
• Simple Storage Service (S3): S3 is a highly available service in order to store static assets. Amazon S3 is designed for 99.99% availability. All the files uploaded to the application should be stored in S3 so that even if the EC2 instances fail, the uploaded file is not lost, and another EC2 instance can process the workload, if required. It is a good practice to store all the static assets such as images and scripts of an application to S3, as it takes the load off your EC2 instances.
• Virtual Private Cloud (VPC): Amazon automatically creates a VPC in a region for all the accounts created after 2013-03-18. By default, subnets are created for all the availability zones in a given region. You can have up to 200 subnets per region that can be increased further upon request. For enabling high availability, the previously configured AWS services setup needs to adjusted to support high availability.
• HA support for Auto Scaling groups.

To launch the EC2 application instances in different availability zones, the subnets within the Auto Scaling group need to be reconfigured (as subnets are associated with specific Availability Zones).

We can follow the steps listed here to launch the EC2 application: 

1. From the EC2 dashboard navigation pane, click on Auto Scaling Groups. Select the A1EcommerceASG Auto Scaling group and then select the Edit option in the Actions drop-down menu or click on the Edit button in the Details tab.

2. The second Availability Zone selected is us-west-2c where the new EC2 instances will be launched. Select the subnet associated with the us-west-2c Availability Zone from the Subnet(s) dropdown list. This step configures the ASG for high availability.

For high availability, the minimum number of instances running in Auto Scaling group needs to be two, that is, one EC2 instance per availability zone. Modify the Desired and the Min number of instances to 2 and the Max to a number greater or equal to 4.

Click on the Save button to save these changes:

3. As soon as you save the changes, the Auto Scaling group will start a new EC2 instance in the us-west-2c Availability Zone as shown: