Announcing Automated in-Amazon Web Services Failback for Amazon Web Services Elastic Disaster Recovery

{"value":"I first covered [Amazon Web Services Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery) (DRS) in a [2021 blog post](https://aws.amazon.com/blogs/aws/scalable-cost-effective-disaster-recovery-in-the-cloud/). In that post, I described how DRS “enables customers to use Amazon Web Services as an elastic recovery site for their on-premises applications without needing to invest in on-premises DR infrastructure that lies idle until needed. Once enabled, DRS maintains a constant replication posture for your operating systems, applications, and databases.” I’m happy to announce that, today, DRS now also supports in-Amazon Web Services failback, adding to the existing support for non-disruptive recovery drills and on-premises failback included in the original release.\n\nI also wrote in my earlier post that drills are an important part of disaster recovery since, if you don’t test, you simply won’t know for sure that your disaster recovery solution will work properly when you need it to. However, customers rarely like to test because it’s a time-consuming activity and also disruptive. Automation and simplification encourage frequent drills, even at scale, enabling you to be better prepared for disaster, and now you can use them irrespective of whether your applications are on-premises or in Amazon Web Services. Non-disruptive recovery drills provide confidence that you will meet your recovery time objectives (RTOs) and recovery point objectives (RPOs) should you ever need to initiate a recovery or failback. More information on RTOs and RPOs, and why they’re important to define, can be found in the [recovery objectives documentation](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html#recovery-objectives).\n\nThe new automated support provides a simplified and expedited experience to fail back [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) instances to the original Region, and both failover and failback processes (for on-premises or in-Amazon Web Services recovery) can be conveniently started from the Amazon Web Services Management Console. Also, for customers that want to customize the granular steps that make up a recovery workflow, DRS provides three new APIs, linked at the bottom of this post.\n\nFailover vs. Failback\nFailover is switching the running application to another Availability Zone, or even a different Region, should outages or issues occur that threaten the availability of the application. Failback is the process of returning the application to the original on-premises location or Region. For failovers to another Availability Zone, customers who are agnostic to the zone may continue running the application in its new zone indefinitely if so required. In this case, they will reverse the recovery replication, so the recovered instance is protected for future recovery. However, if the failover was to a different Region, its likely customers will want to eventually fail back and return to the original Region when the issues that caused failover have been resolved.\n\nThe below images illustrate architectures for in-Amazon Web Services applications protected by DRS. The architecture in the image below is for cross-Availability Zone scenarios.\n\n\n\nThe architecture diagram below is for cross-Region scenarios.\n\nhttps://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2022/11/17/DRS-Cross-Region-Diagram.jpg\n\nLet’s assume an incident occurs with an in-Amazon Web Services application, so we initiate a failover to another Amazon Web Services Region. When the issue has been resolved, we want to fail back to the original Region. The following animation illustrates the failover and failback processes.\n\n\n\nLearn more about in-Amazon Web Services failback with Elastic Disaster Recovery\nAs I mentioned earlier, three new APIs are also available for customers who want to customize the granular steps involved. The documentation for these can be found using the links below.\n\n- [StartReplication](https://docs.aws.amazon.com/drs/latest/APIReference/API_StartReplication.html)\n- [StopReplication](https://docs.aws.amazon.com/drs/latest/APIReference/API_StopReplication.html)\n- [ReverseReplication](https://docs.aws.amazon.com/drs/latest/APIReference/API_ReverseReplication.html)\n\nThe new in-Amazon Web Services failback support is available in all Regions where [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery) is available. Learn more about Amazon Web Services Elastic Disaster Recovery in the [User Guide](https://docs.aws.amazon.com/drs/latest/userguide/getting-started.html). For specific information on the new failback support I recommend consulting [this topic in the service User Guide](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html). \n\n— [Steve](https://twitter.com/bellevuesteve)\n\n\n\n### **Steve Roberts**\n\nSteve Roberts is a Senior Developer Advocate, focused on .NET and PowerShell development on Amazon Web Services. Based in Seattle, Washington, Steve worked as a Senior Development Engineer on the Amazon Web Services SDKs and tools for .NET and PowerShell developers. He was the development lead for the AWAmazon Web Services S Tools for PowerShell and the Amazon Web Services Tools for Azure DevOps, and also worked on the Amazon Web Services Toolkits for Visual Studio, and Visual Studio Code, plus the Amazon Web Services SDK for .NET. Follow him on Twitter @bellevuesteve.","render":"<p>I first covered <a href=\\"https://aws.amazon.com/disaster-recovery\\" target=\\"_blank\\">Amazon Web Services Elastic Disaster Recovery</a> (DRS) in a <a href=\\"https://aws.amazon.com/blogs/aws/scalable-cost-effective-disaster-recovery-in-the-cloud/\\" target=\\"_blank\\">2021 blog post</a>. In that post, I described how DRS “enables customers to use Amazon Web Services as an elastic recovery site for their on-premises applications without needing to invest in on-premises DR infrastructure that lies idle until needed. Once enabled, DRS maintains a constant replication posture for your operating systems, applications, and databases.” I’m happy to announce that, today, DRS now also supports in-Amazon Web Services failback, adding to the existing support for non-disruptive recovery drills and on-premises failback included in the original release.</p>\\n<p>I also wrote in my earlier post that drills are an important part of disaster recovery since, if you don’t test, you simply won’t know for sure that your disaster recovery solution will work properly when you need it to. However, customers rarely like to test because it’s a time-consuming activity and also disruptive. Automation and simplification encourage frequent drills, even at scale, enabling you to be better prepared for disaster, and now you can use them irrespective of whether your applications are on-premises or in Amazon Web Services. Non-disruptive recovery drills provide confidence that you will meet your recovery time objectives (RTOs) and recovery point objectives (RPOs) should you ever need to initiate a recovery or failback. More information on RTOs and RPOs, and why they’re important to define, can be found in the <a href=\\"https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html#recovery-objectives\\" target=\\"_blank\\">recovery objectives documentation</a>.</p>\\n<p>The new automated support provides a simplified and expedited experience to fail back <a href=\\"https://aws.amazon.com/ec2/\\" target=\\"_blank\\">Amazon Elastic Compute Cloud (Amazon EC2)</a> instances to the original Region, and both failover and failback processes (for on-premises or in-Amazon Web Services recovery) can be conveniently started from the Amazon Web Services Management Console. Also, for customers that want to customize the granular steps that make up a recovery workflow, DRS provides three new APIs, linked at the bottom of this post.</p>\\n<p>Failover vs. Failback<br />\\nFailover is switching the running application to another Availability Zone, or even a different Region, should outages or issues occur that threaten the availability of the application. Failback is the process of returning the application to the original on-premises location or Region. For failovers to another Availability Zone, customers who are agnostic to the zone may continue running the application in its new zone indefinitely if so required. In this case, they will reverse the recovery replication, so the recovered instance is protected for future recovery. However, if the failover was to a different Region, its likely customers will want to eventually fail back and return to the original Region when the issues that caused failover have been resolved.</p>\n<p>The below images illustrate architectures for in-Amazon Web Services applications protected by DRS. The architecture in the image below is for cross-Availability Zone scenarios.</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/e282dc1a15c24be2a5833ec9341c4fef_image.png\\" alt=\\"image.png\\" /></p>\n<p>The architecture diagram below is for cross-Region scenarios.</p>\n<p>https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2022/11/17/DRS-Cross-Region-Diagram.jpg</p>\n<p>Let’s assume an incident occurs with an in-Amazon Web Services application, so we initiate a failover to another Amazon Web Services Region. When the issue has been resolved, we want to fail back to the original Region. The following animation illustrates the failover and failback processes.</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/f6ad3137305c43d69a605b51587771bd_DRS-AWS-Failover-and-Failback.gif\\" alt=\\"DRSAWSFailoverandFailback.gif\\" /></p>\n<p>Learn more about in-Amazon Web Services failback with Elastic Disaster Recovery<br />\\nAs I mentioned earlier, three new APIs are also available for customers who want to customize the granular steps involved. The documentation for these can be found using the links below.</p>\n<ul>\\n<li><a href=\\"https://docs.aws.amazon.com/drs/latest/APIReference/API_StartReplication.html\\" target=\\"_blank\\">StartReplication</a></li>\\n<li><a href=\\"https://docs.aws.amazon.com/drs/latest/APIReference/API_StopReplication.html\\" target=\\"_blank\\">StopReplication</a></li>\\n<li><a href=\\"https://docs.aws.amazon.com/drs/latest/APIReference/API_ReverseReplication.html\\" target=\\"_blank\\">ReverseReplication</a></li>\\n</ul>\n<p>The new in-Amazon Web Services failback support is available in all Regions where <a href=\\"https://aws.amazon.com/disaster-recovery\\" target=\\"_blank\\">AWS Elastic Disaster Recovery</a> is available. Learn more about Amazon Web Services Elastic Disaster Recovery in the <a href=\\"https://docs.aws.amazon.com/drs/latest/userguide/getting-started.html\\" target=\\"_blank\\">User Guide</a>. For specific information on the new failback support I recommend consulting <a href=\\"https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html\\" target=\\"_blank\\">this topic in the service User Guide</a>.</p>\\n<p>— <a href=\\"https://twitter.com/bellevuesteve\\" target=\\"_blank\\">Steve</a></p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/c30d0776444a4c37a4e91b677c7f40f0_image.png\\" alt=\\"image.png\\" /></p>\n<h3><a id=\\"Steve_Roberts_34\\"></a><strong>Steve Roberts</strong></h3>\\n<p>Steve Roberts is a Senior Developer Advocate, focused on .NET and PowerShell development on Amazon Web Services. Based in Seattle, Washington, Steve worked as a Senior Development Engineer on the Amazon Web Services SDKs and tools for .NET and PowerShell developers. He was the development lead for the AWAmazon Web Services S Tools for PowerShell and the Amazon Web Services Tools for Azure DevOps, and also worked on the Amazon Web Services Toolkits for Visual Studio, and Visual Studio Code, plus the Amazon Web Services SDK for .NET. Follow him on Twitter @bellevuesteve.</p>\n"}