Skip to Content

The Types of Availability in the AWS Cloud (and Why They Matter)

Moving to the cloud means organizations no longer need to manage as much infrastructure as they did before. While they do need to manage workloads and applications, they are out of the day to day operational game of managing things like compute, network, and storage hardware when they move to the cloud. However, this doesn’t mean customers no longer need to worry about core infrastructure qualities like availability.

Types of Cloud Availability

When we think about the cloud, especially a provider like AWS, we have two different interpretations of the word availability to think about.

  • AWS’ availability to our applications

and

  • The availability of our applications to our customers

As cloud architects, we must keep both types of availability in our minds. Let’s start by thinking about how some organizations consume the cloud, and how consumption models can impact different types of availability.

The Cloud Journey

The cloud journey is different for many organizations, however we can talk generally about two different use cases:

  • Bursting to the cloud for particular applications, or using the cloud for intense data processing

and

  • Re-architecting applications with a cloud native architecture in mind

The Cloud Native Future

Let’s start with the second use case. In this case, we are fundamentally building availability into our application, we may not care if we have a cloud instance fail, because we’ve ensured another instance will be spawned or take over. We have also ensure the data the instance has is taken care of, whether it be through a database or a replica. In this case, many may not be concerned with backing up or restoring a particular cloud instance. They have designed their environment to be able to withstand a failure of a component, and not really care about it. The business and applications will keep on running. When we look at the two different types of availability in this situation, we are covered on both ends, provided we have architected our application to run in multiple AWS availability zones.

This is a good place to be, but many organizations are not here yet. There are many who are still dipping their toes into the cloud, so to speak.

Cloud as an Enabler

Now, let’s look at the first use case. These cloud journeys begin with the desire to to manage less infrastructure on premises. They may not need extra compute power all of the time, but when they do, they use the cloud instead of letting hardware collect dust in the datacenter. In this case, the cloud is enabling them to do things they could not before. This is one of the most common cloud use cases, and how many organizations begin to consume a service like AWS.

In this case, we do often care about our cloud instances. The applications may not have yet been re-architected to take advantage of all the resiliency features AWS can provide. We are leveraging the cloud because we need power, and we need it now. We are not working about the availability of our infrastructure in this case, because it is provided by AWS. We are however, worried about the availability of our applications and workloads in case something happens.

So now what? How do we protect our cloud instances? How do we train our staff on yet another tool? Wasn’t training them on the cloud hard enough?

Enter Veeam. More specifically, Veeam Availability for AWS. This is one upcoming solution for this problem. This will allow organizations to leverage AWS snapshots, similar to the way they backup and recover their traditional virtualization environments of today.

Consume the Cloud Responsibly

It is important to remember the cloud is just someone else’s server. While you are getting out out of infrastructure availability, you still need to be concerned with the availability of your applications to your customers. Would you build a virtualization environment on premises and not back up your virtual machines? Of course not. It is important to remember design still matters, even in the cloud.