Not all scalable applications are inherently elastic.for example, an application that only supports vertical scaling.
Not all elastic applications are inherently highly available.for example, a horizontally scalable application in one availability zone.
Not all highly available applications are inherently resilient.for example, an application distributed across two availability zones with each location able to handle only 50 percent of the traffic.
This chapter covers the following official AWS Certified SysOps Administrator – Associate (SOA-C02) exam domains:
Domain 2: Reliability and Business Continuity
Domain 5: Networking and Content Delivery
If you can correctly answer these questions before going through this section, save time by completing the Cram Quiz at the end of the section.
1. You are required to deploy an application with a highly available persistent datastore. In how many availability zones must you deploy your application storage system to achieve this at a minimum?
2. What distinguishes a private subnet from a public one?
Answers
1. Answer: You can use the EBS service to create a highly available persistent volume. The service maintains two replicas in one availability zone. Although you meet the high availability defined in the question, the application is not resilient to availability zone outages.
2. Answer: A public subnet has a route to an Internet gateway that allows inbound and outbound traffic to any instance in that subnet with a public or Elastic IP attached. There is no way to let incoming traffic into a private subnet, but outgoing requests can be forwarded via a NAT instance or gateway to the Internet.
Availability zones are fault isolation environments within AWS regions. We already discussed the basic design where one or more datacenters are grouped in two availability zones and that each region is typically designed to hold two or more availability zones. For more information, refer to the “AWS Global Architecture” section in Chapter 1, “Introduction to AWS.”
When you choose to use managed services, AWS always manages the availability of the service and typically those are deployed across at least three availability zones for full resilience. Most of the time the service also has a defined uptime, and sometimes there is a definition for the durability of data within the service. For example, the S3 standard service has uptime defined as 99.99 percent (four nines) and durability defined as 99.999999999 percent (eleven nines), due to the fact that all objects on S3 standard are replicated to at least three devices in at least three availability zones within a region by default.
In the case of unmanaged services like EC2 and EBS and some managed services that require high network performance, such as Elastic Map Reduce (EMR) and Redshift, you need to handle the high availability and resilience by adopting the AWS design best practices. There are three ways of making the application highly available:
Single AZ high availability: Maintaining two or more replicas in the same availability zone
Multi-AZ high availability: Maintaining two or more replicas across two or more availability zones
Multiregion high availability: Maintaining two or more replicas across two or more AWS regions
Single AZ high availability is built into some services like EBS. Because an EBS volume cannot exist in more than one availability zone at a time, the design ensures the volume is synchronously mirror-replicated on another device within the availability zone. This allows the EBS service to withstand failures of hardware within an availability zone.
However, due to a more widespread power or network issue, whole availability zones can go down, so it is up to you to replicate the data from one EBS volume to another availability zone. This can be done in two ways:
Create another EBS volume in another AZ and use software replication.
Create frequent snapshots of the EBS volume that are stored to S3.
The third option is cross-region replication, which allows the service to survive a regional outage and can also be used to mitigate any disaster situation. Cross-region replication does, however, carry additional cost due to the fact that data will transit the AWS backbone or the Internet to the other region. Transfer out charges always apply when performing cross-region replication.