Pilot light DR on AWS: Rapid recovery with Cutover runbooks

So in the demo today, what I'll be doing is I'll show you how you can recover a three-tier application utilizing the Pilot Light VR pattern in Cutover. So first, what you see here is we have an application that is primarily hosted in US East One region. You will see that we have three availability zones with three instances in each of the auto-scaling groups. And down at the bottom, we also have the Aurora DB cluster. And then on the right hand side, we'll see there is a US West Two, which is a standby region. This is the pilot light strategy where it is ready for the failover when you need it to. But we have not spun up those instances or the infrastructure yet so that you are not incurring that cost. We also see that we have the routing controls, the Route 53 controls on, indicated by the green on the left hand side and red on the right hand side. It also indicates that the traffic is going correctly into the primary US East One region. But when we need to switch over, we will turn on the routing controls in the secondary region where we'll see how it looks when we actually do the failover. So here you can see that on the right hand side, we have provisioned those instances, and the ASGs in the US Two now also have three instances. You can see that the Aura cluster also now has the reader and writer clusters as well. And the routing controls are now green on the US West Two, and we turned them off in US East One. So with that being said, what I'll do first is I'll show you how it would look very quickly without Cutover, and then we'll jump into the Cutover Runbook to orchestrate and automate the failover itself. So let me start sharing the screen. Here we are. You can see that I'm starting actually first in the AWS console just to show you the part of the ASG. So if I go back, I want to show you how we can get from here to here. I'm in US East One region. So what I will have to do is validate what is the provisioning of my auto scanning groups in US East one. I click on here and I can see these numbers that I need to replicate essentially in Oregon. So I will have to now click on Oregon, go to the AutoScan groups and manually provision them here or use CloudFormation templates or Terraform. But essentially, it's a lot of click ops. Similarly, in terms of turning on and off the routing controls in both regions, I would have to go to another AWS service, such as Application Recovery Controller. And in here, you can see if I need to turn off, for example, the control in one of the AZs, what I have to do is, again, essentially a lot of click ops to achieve what I'm trying to do. Think about the scenario of where you don't have time to actually do this very quickly because you are pressed with the RTO and RPO, but you have to still do it manually. Basically, you are counting on the person that they know what they have to do in a certain order. Now that I've shown you this, let's go into Cutover and let's show you how we can do that by accelerating and automating that failover, by bringing all of those services that you've seen into one single place of execution, such as bringing the auto scaling groups integrations in here, creating also the brighter and reader clusters of Aura DBs in the secondary region. And then further down the line, we'll be automatically turning on and turning off the routing controls as well. So without Cutover, again, you would have to switch between accounts, go into the different AWS services and do that. And obviously there's certain dependencies also between the tasks to make sure that you are doing it correctly. And in Cutover, you can do it in a way that you designed so that you are not turning off or turning on something that you shouldn't be doing at the moment. So the nodemap that you see in here is helping you exactly with that because in a nodemap, we are showing you the pictorial representation of how you have constructed the runbook, how the tasks will be executed, which tasks have been completed, and how you should be going about the recovery. And if you need to drill down into particular specifications of the applications, as I said, we have a three tier application. Maybe you just want to see the compute of your task. Then in here, again, you are seeing that first, via the integration. So with the REST API, we are connecting to the auto scaling groups in the primary region, so US East One, to query what are the desired capacity and minimum sizes and maximum sizes of those instances. So we are pulling that information into Cutover. And the reason why we are doing that is because we want to make sure that when we are spinning up those instances in the secondary region, we are spinning them up in the correct number as well. So we want to make sure that we have the latest and greatest information. So with that being said, let me kick off some of the integrations first. So because we have completed the task of querying the number of instances in the primary region, now we are able to scale up the compute in the secondary region. So now what I'm doing is, via REST API, again, I'm connecting to the AWS in the US West Two region and the integrations are running and it's telling AWS, hey, go and spin up the EC2 instances in that particular region. And because I also can go into the instance itself, I can essentially refresh and see if Cutover has been connecting to that. And you can see we have those regions spin up in the US West Two region with one single click in Cutover as well. So we can see integration successful. Now what I will do is, in the failover itself, it's not about just the automation. There's elements of human interaction as well where we might need to also decide, as disaster recovery coordinator, if I want to actually continue with my failover. And in this case, Cutover brings you the opportunity of choosing what you want to do. And in this case, I actually want to start with the failover process. So what I'll be doing is I'll be abandoning any task where I'm saying, Hey, I don't want to do the failover. What is happening here is, the nodemap, if I go to the nodemap, you will see that I abandoned a certain part of the runbook and I'll be continuing with the part of the runbook that I've chosen. And what I'm choosing here is essentially turning off those routing controls in the primary region so that I can automatically turn them on in the secondary region as well. So, again, Cutover is now connecting to AWS in the routing controls. And if I go to the cluster, you will see that we are now turning off the routing controls in US East One and we'll be turning them on in the US West Two. So that is a huge power that Cutover is giving customers in terms of making sure that they are executing the failover with the pilot light in a certain way that is automating the execution of these tasks, but also giving you the ability to input the human element of approvals. And everything that you do in Cutover is also stored in our audit log that you can use it to prove to regulators that you have either tested the failover or that you have executed the failover and you met your RTO or RPO. And because this is an example of one application where we have pre configured these integrations, you might also have a question of how do I get to the stage of having a runbook like this with all those integrations preset? And Cutover can help you with that as well. This runbook essentially was created based on one of our templates. So if I now switch to the template, this is where we have sixteen runbook templates as a skeleton of preconfigured task that you can use for different DR patterns that Leo presented, whether it is your backup and restore, pilot light, ROM standby or active active. Cutover is giving you the best practice runbooks for each scenario and, even more than that, we give you the scenarios for if you have applications on prem to cloud or AZ to AZ, cloud multi region, whatever the scenario is. You can take the runbook template and then you can utilize preconfigured tasks in here and use your CMDB and APM data to then enrich these runbooks so that you can configure those integrations that I showed you. An example of that is, in this instance, a customer has seventeen of our runbook templates and they have used their CMDB data that they connect to application Metastore in Cutover where that information is pulled from the CMDB into Cutover, as you can see from here. And this information is then enriching those runbook templates that you see in here. And it is incredibly powerful because then you can filter on, hey, I just want to test maybe a failover for all the applications in the US East One region, but I only care about the applications which has criticality tier zero. So now I'm actually filtering on the latest information pulled from your CMDB. I know that these are the applications in that region with the tier zero criticality. And if I want to see just the pilot light runbook, I can go inside and see, brilliant. My team has built a robust runbook that is going from pre failover to failback to failover to failback and even cleanup. The integrations have been preset. I can also see that they have set when the RTA should start and when the RTA should end so that we can use that calculation and use it against the RTO and RPO and also provide it to not only our internal stakeholders, but also external. And this is so important right now in Europe with the DORA. So this is a great way on how you can reduce your time of being resilient on cloud, but also reduce the time of proving to regulators that you are resilient. And so with that being said, I think I've shown you everything I planned for today for the demo. Thank you so much.