From the course: AWS: High Availability

Designing for failure - Amazon Web Services (AWS) Tutorial

From the course: AWS: High Availability

Start my 1-month free trial Buy for my team

Designing for failure

"

- To get your creative juices flowing, let's do a quick overview of some high availability tools that exist in AWS. Before we get started, let's recap the AWS global infrastructure. At the highest level, AWS subdivides the world into regions. Regions are geographically separated and located on almost every continent in the world. For example, AP-south-1 is located in Mumbai, India. US-east-2 is located in Ohio, in the United States. Each region contains at least two availability zones or AZs. Each AZ is made up of at least one completely independent data center connected through low latency, high speed network links, independent of region, or availability zone. AWS also has edge locations throughout the world located in places like Chennai, India, Warsaw, Poland, Rio de Janeiro, Brazil, and South Bend, Indiana. These edge locations power cloud front, the AWS content delivery network. The combination of edge locations, availability zones, and regions represent the AWS global infrastructure. Let's start the tour of high-availability tools at the highest most abstract level. Here we are looking at four completely isolated AWS regions. The first stop on the tour of HA tools is Route 53. Route 53 is a service offering from AWS for managing domain name, system, or DNS requests. If you have the need to create an HA system that can tolerate the failure of an AWS region, Route 53 is an important tool to have in your toolbox. Keep in mind that a failure of this magnitude is quite unlikely. Given all the redundancy built into a given region as with all components of your HA design, you'll want to balance the likelihood of failure, solution cost, and availability requirements. The next stop on the HA tour finds us within an AWS region. Suppose you are running an application out of a single availability zone. If there was a catastrophic failure, which took that AZ offline, you'd definitely be having a bad day. Enter the elastic load balancer or ELB. ELBs represent one of the most foundational components of any HA solution within AWS. With the right application design and ELB configuration, you can distribute your application components across additional AZs and use an ELB to distribute traffic. With this design, you will minimize the impact on your users. Suppose you have to operate a purchased application that only runs a monolithic server. As such It can only run in a single AZ on a single elastic compute cloud or easy two instance. If that instance has a problem, your service goes down, and your users experience and outage, and you're having a bad day. Another tool in the HA toolkit is the elastic IP address or EIP. And EIP can be reassigned from one instance to another. Instead of mapping your users directly to the IP of a given easy to instance, you can map them to an elastic IP. In the event of a failure, you could create a new instance based off your most recent snapshot or backup and attach the EIP to it. In the event of a complete AZ outage, you could bring that new instance up in a separate AZ. So far, we've talked about bad things happening. However, what if something good happens. Suppose you've designed your applications to operate seamlessly across three AZs. All of a sudden, you see an increase in load on your application. You can use a tool called an Auto Scaling group or ASG to react to this load. Based on load triggers, you configure an ASG can launch additional instances to handle the increased demand. Even better. When that additional workload dissipates, you can automatically scale in to not waste financial and computing resources. With an understanding of some of the coarse grain tools available, let's look a little deeper into additional service offerings that make them work.

Inhalt