Automating AWS Zonal Shifts, Part 2: Configuration
Now that we've delved into why zonal autoshift is so important, here's how to get up and running in your environment.
In my previous article, I explained the advantages to using zonal autoshift, along with how it works. Now, I want to continue the discussion by explaining how to configure zonal autoshift. Keep in mind that the configuration process is going to vary from one workload to the next, so this is intended as a high-level overview of the configuration process.
So with that said, you can configure zonal autoshift from within the Route 53 console. To do so, open the Route 53 console and then select the Application Recovery Controller tab. When you do, you will be taken to a welcome screen similar to the one shown in Figure 1.
As you look at the figure above, you will notice that there are several different zonal shift options. The default zonal shift option allows you to perform a manual zonal shift. If you want to perform an automatic zonal shift however, you will need to select the Zonal Autoshift option and then click the Configure Zonal Shift button. At this point, you will be taken to the Configure Zonal Autoshift button, shown in Figure 2.
The first thing that you will need to do upon reaching this screen is to select the resource for which you want to enable a zonal autoshift. Typically, the resource is going to be a Web application, although most load balanced resources are supported. Resources are only available for selection if they are tied to a network load balancer or an application load balancer. If you are using an application load balancer however, cross zone load balancing must be disabled.
The next thing that you will have to do is choose whether you want to enable or disable autoshift. When enabled, autoshift will only perform a traffic shift if a problem is detected. If you disable autoshift then you can (and should) perform practice runs as a way of making sure that adequate capacity is available in each zone, but automatic shifting will not occur.
This brings up an important point. Amazon considers practice runs to be essential. Without them, you could conceivably end up in a situation in which an availability zone does not have the resources that it needs to fully host the workload should an automatic shift occur. Given the importance of these practice runs, AWS will automatically perform a weekly practice run (assuming that zonal autoshifts are enabled). These practice runs last for about half an hour.
As important as practice runs may be, there are likely times when you would prefer that practice runs not occur. If for example, you have a mission critical Web application that all of your users need access to in order to do their jobs, then you probably wouldn't want a practice run to occur at 9:00 AM on Monday morning. Otherwise, if a problem were to occur during the practice run then your organization could be left in a predicament.
Because of this, the zonal autoshift interface allows you to create blocked windows during which practice runs will not occur. You can block off specific dates or you can block off certain times. For example, you might prevent practice runs from occurring during business hours by blocking off 9 a.m. to 5 p.m. Monday through Friday.
The last step in the process is to set up one or more alarms. You can see the Alarms interface in Figure 3.
The Alarms section lets you set up a CloudWatch alarm that monitors practice runs. To put it simply, if a practice run does not trigger a CloudWatch alarm, then the practice run is considered to be successful.
There is a second, optional alarm that you can set up. This alarm works by monitoring another alarm of your choosing. If the designated alarm is in Alarm state then AWS won't start a practice run. In other words, if your workload is having problems, then you probably shouldn't perform a practice run until those problems have been corrected.
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.