Skip to content

High Availability

Warning

Missing video.

When we design infrastructure, whether it's in the Cloud or not, we need to build it in a way that allows it to survive failure. That failure can be related to power, networking, human error or malice, and a whole list of other things. The way we do this usually boils down to doubling up on everything and then using certain technologies to work with the extra "stuff". Technologies like load balancers, Auto Scaling Groups, AWS Availability Zones, and more, are technologies we will need to understand if we're going to build things that are highly available and offer redundancy.

Subjects

Here's what we're going to cover:

  • AWS Regions & Availability Zones
  • Application and Network Load Balancers
  • Auto Scaling Groups
  • RDS Multi-AZ
  • S3 cross region replication

Curated Materials

These materials will get you to a strong understanding of what it takes to build highly available architectures. Ultimately, delivering software isn't just about making it available, but it's about making it available and resistent to failure. Even when a major component fails, the solution should still be live.

AWS Regions & Availability Zones

AWS Regions are where you begin when you're looking at AWS' global network for the first time. They're also the largest "unit" in AWS' network, except for the whole network itself, of course. Understanding where you're able to deploy AWS resources can be important because, generally speaking, you'll want to build things that are operating as close to the end user as possible.

And this article on AWS CloudFront's Points Of Presence (POP), which are a big part of AWS' infrastructure and make it possible to get static assets like images and HTML very close to the end user, but also some compute functionality via Lambda Functions on "the edge", which is very exciting and has some incredible future prospects.

Application and Network Load Balancers

When it comes to building real-world, Enterprise solutions, a load balancer is a must. They're the most common way of making an application highly redundant. Running two instances of an application behind a load balacner means one copy of it can fail, due to networking, hardware, etc., and the second will continue to serve traffic/demand. It's not a perfect solution, but it's industry best practice to at least have some redundancy in your architecture.

Load balancers come in some various types. We're going to look at AWS' application and network load balancers. These operate at different layers of the TCP/IP networking stack.

Before getting into each variant, let's review some top level details about ALBs and NLBs in general:

And let's review a comparison of between all the options:

The most popular options are ALBs and then NLBs. But primarily ALBs.

Application Load Balancers (ALB)

We use ALBs when we want to load balacner traffic at the "Application" layer of the TCP/IP networking model. For an ALB, this means only HTTP. Every application operates, eventually, at the "Application" layer (SSH, FTP, NFS, etc.), but ALBs are designed to specifically load balancer HTTP.

Here's a high level overview:

But you're going to need to get into the specifics:

An ALB also has two additional components you have to know about: Listeners and Target Groups.

A Listener literally listens for network connections, either on a private network (internally, for example), or the public Internet. It receives and processes them, and uses rules to determine where the traffic should then go. Once it's made this decision, it passes the traffic through a Target Group (below). That's the first part of an ELB/ALB/NLB's implementation.

Checkout the documentation on ALB Listeners:

The Target Group is then responsible for tracking the health of the targets that the traffic will eventually be sent to. If it sees that a target is not healthy, based on some health checks and/or metrics, it will not send traffic to it. This is part of the redundancy that's being implemented by load balancers.

Read up on Target Groups here:

Combined, all of these concepts bring us the ability to create a component that can take inbound traffic, determine where it should go, then find a working system to send it to. Coupled with two or more running instances of your application, you get high availability.

Network Load Balancers (NLB)

What if you don't want to load balance HTTP, but any traffic? Well, you lose the ability to do a lot of the appliaction specific stuff you can do with an ALB< like inspect the URI for a particular pattern in the path, but you gain a lot of speed and other cool features, like being able to load balance UDP.

We won't go into too many specifics about NLBs. You know enough at this point after going through our networking section earlier, ALBs, above, and so on.

You won't use NLBs as much as you will ALBs. Most business host web based applications, so a lot of HTTP.

Auto Scaling Groups

One of the greatest advantages of using Cloud technologies is the ability to start with a small, possibly under-powered, server configuration and simply scale it up. You can scale it vertically (more CPU/RAM) or horizontally (more copies of the server) in near real-time. This is how you correctly use Cloud compute.

But what if you're not around to scale the server(s) based on a (sudden) rise in demand? That's what we use AutoScaling Groups for. They're capable of using metrics to monitor the usage of your existing compute resources and then make decisions that result in a horizontal scaling event (more servers get created.)

Auto Scaling Groups - or ASG - are a core AWS service.

Here are the resources we recommend you explore with regards to ASGs.

Pay special attention to the following concepts explored on that page:

  1. Launch Templates
  2. Launch Configurations
  3. Auto Scaling Groups (of course)
  4. Monitor
  5. Security

Auto Scaling is very powerful, and a great way to take big advantage of the Cloud's "utility billing", because you scale up (and pay more) when you need it because of demand, then scale down (and pay less) when it's not required.

RDS Multi-AZ

At this point on your journey, you've used AWS RDS.

  • RDS Multi-AZ
    • About: https://aws.amazon.com/rds/features/multi-az/
    • Docs: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html
    • Terraform resources:
    • https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance

S3 cross region replication

Warning

Missing content.

  • S3 cross region replication
    • About: https://aws.amazon.com/s3/features/replication/?nc=sn&loc=2&dn=5
    • Terraform:
    • https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_replication_configuration

Project(s)

Warning

Missing content.

Challenges

Warning

Missing content.