AWS Step-by-Step

Automating AWS Zonal Shifts, Part 1: Cost and Efficiency

In this two-part series, we'll evaluate whether AWS Zonal Shifts is right for your organization's data and get you up and running with the service.

• By Brien Posey
• 01/22/2024

Over the last year or so, I have been privy to numerous conversations in which an organization is considering repatriating some of its cloud workloads. Early on, the cloud providers did a great job of convincing customers that moving their workloads to the cloud would result in significant cost savings and that they needed to be cloud first in order to avoid being left behind. Often though, the perceived cost savings just didn't materialize and many organizations are now left wondering if they made a mistake by moving everything to the cloud.

While hurrying to move everything to the cloud in the interest of becoming cloud first might have been a mistake, it would probably also be a mistake to move everything back into the datacenter. There are some workloads that probably should be run on premises, but there are other workloads that really need to be hosted in the cloud.

This of course raises the question of which workloads should be hosted in the cloud? If you take cost out of the equation and look solely at what the cloud can do that on premises environments can't, then you will find that the workloads that are best suited to cloud environments are those that require extreme resiliency and availability. Granted, there are plenty of ways to make an on premises workload highly available, but public cloud providers make it possible to fail a workload over to another region, which is something that would be quite costly to do without the cloud. Conversely, Amazon is making it easier and easier to fail workloads over to another datacenter.

One of the main ways that AWS customers make workloads resilient is to take advantage of availability zones. Servers in different availability zones are typically located in separate datacenters so that they do not share power, connectivity or other resources with one another. The idea is that a disaster that impacts one availability zone should have no effect on another.

Transitioning a workload from one availability zone to another involves a process called a zonal shift. A workload that has been designed to take advantage of multiple availability zones is usually tied to a load balancer. This load balancer directs inbound traffic to a particular availability zone. When everything is normal, this load balancer helps to distribute the workload across multiple availability zones so that no one single availability zone has to handle the entire workload by itself. When a problem occurs within an availability zone however, an organization can perform a zonal shift as a way of directing traffic away from the availability zone that is having issues.

As nice as this sounds, it isn't perfect. Until recently, zonal shifts could only be performed manually or programmatically. This means that before an organization could perform a zonal shift away from an availability zone, it first had to recognize that problems were occurring within that availability zone. This was often problematic since key performance indicators are usually monitored at the application level rather than at the availability zone level. That meant that if an application was designed to be load balanced across multiple availability zones, an organization might recognize that the application is having issues, but may have difficulty determining which availability zones are healthy and which are not.

Thankfully, Amazon has recently introduced automatic zonal shifts. That way, AWS can automatically detect problems at the availability zone level and perform a zonal shift on the organization's behalf.

It is worth noting that load balanced applications will not automatically take advantage of zonal autoshift capabilities. An administrator must explicitly enable zonal autoshift for an application from within the Route 53 console.

Additionally, zonal autoshift is not going to be an option for every application. In order to use zonal autoshift, an application must be configured to use either an application load balancer or a network load balancer. Additionally, the load balancer's cross zone load balancing feature must be disabled.

It's worth noting that there is no direct cost associated with using AWS's zonal autoshift capabilities. Even so, you must ensure that each availability zone has sufficient resources available to host a workload all by itself (without having a portion of the load distributed to another availability zone). Otherwise, a zonal autoshift could cause a workload to crash simply because the availability zone does not have the resources that it needs in order to properly run the workload.

One more thing to keep in mind with regard to using the zonal autoshift feature is that you have to consider any application dependencies that might exist. After all, it's pointless to shift an application to a different availability zone if the application's dependencies remain within the availability zone that is having problems. In such a situation, those dependencies would become a single point of failure unless they were also enabled for zonal autoshift.

Now that I have explained the requirements for using zonal autoshift, I want to talk about how to actually implement these capabilities. In Part 2, I will walk you through the configuration process.