Highly Available and Fault-Tolerant Architectures

1. How do you achieve AWS’s definition of high availability when designing applications?
Achieving high availability at AWS is carried out by using multiple availability zones, two at a minimum, to host your EC2 instances or containers. This means using multiple physical data centers in different locations. It is unlikely that two data centers in separate physical locations within an AWS region will fail at the same time; in fact, it has never happened. Remember that high availability means the application remains available even when problems occur.

2. What AWS service is not initially designed with fault tolerance or high availability?
When you order a single EC2 instance, there is zero fault tolerance at the customer level. A single instance also does not offer high availability. You increase fault tolerance for applications by placing applications on multiple servers hosted behind load balancers. In addition, the servers are in different availability zones. By designing for fault tolerance, you also create a level of availability that is typically referred to as high availability.

3. What is the easiest way to remove single points of failure when operating in the AWS cloud?
The easiest method of removing single points of failure when operating in the AWS cloud is to use managed services for your solutions. For example, you can store your data records on an EBS volume. Each EBS volume is replicated for redundancy purposes within the availability zone where it is created. You could increase the redundancy and availability of your storage solution by using EFS for Linux or FSx for Windows. Both of these shared storage solutions store data records across multiple availability zones automatically. You can further increase the redundancy and availability of your data records by storing your files in an S3 bucket. An S3 bucket is replicated to at least three physical locations within an AWS region. You could follow the same logic when deploying EC2 instances, using multiple availability zones and so on.

4. What is the difference between a pilot light solution and a warm standby solution?    
A pilot light solution involves a database solution that is on and synchronized with the primary database but is operating at a smaller scale than the production database. The application or web servers are ready to go but are not turned on and scaled until a disaster happens. In comparison, a warm standby solution has all resources on and operating, but all resources are not at production scale and have to be upsized when disaster strikes.

5. What is the difference between RPO and RTO?
Both RPO and RTO are estimates of acceptable downtime and the acceptable amount of data loss and application availability when disaster strikes. RPO stands for recovery point objective and is the point to which you have to roll back in order to have valid data records. RTO stands for recovery time objective and indicates how long it is acceptable for an application to be out of service. The reality is that data loss might mean that you are out of operation even though your application is up.

6. What two AWS database services allow you to deploy globally across multiple AWS regions?
Amazon Aurora and DynamoDB can both be deployed across multiple AWS regions.

7. How can you build a self-serve portal for developers at AWS and control what architecture is deployed?
To create a self-serve portal for developers, you can create several CloudFormation templates and then create a portfolio using Service Catalog to organize your templates based on groups of developers. A portfolio can be controlled using IAM permissions and other controls.

8. What service allows you to deploy an architectural solution for an application that you have already written?
Elastic Beanstalk allows you to deploy the required infrastructure to host an application that you have coded. Both the infrastructure and the hosting of the application can be carried out automatically, including future application and infrastructure updates.