Hi I'm Peter. Welcome to 'Back to Basics' there's nothing worse than not
being able to deliver results to your customer due to an outage. I remember when I was unable
to send reports to New York City Hall right before a press conference. So how do you protect
your teams and your business against this without breaking the bank? Using AWS for Disaster Recovery
or DR, is a common hybrid pattern when you use AWS as your backup site. This pattern has you
continuously replicating your on-prem applications and databases into AWS to have business continuity.
This creates a DR strategy with low recovery time and recovery point objectives. This means you can
quickly recover from a failure and minimize data loss. If we had used this strategy it would have
saved me from having to manually create those reports, which we all know can be error prone and
very stressful. So let's see how we can do this using AWS Elastic Disaster Recovery or DRS.
With DRS you choose an AWS Region as your disaster recovery target. DRS will continuously replicate
your on-prem application servers, including databases into a staging area within an Amazon VPC
using block level replication. This staging area only retains a copy of your data. Nothing is turned
on, which means you're not paying for anything other than storage. When you experience a failure
DRS uses the staged resources to automatically create a full capacity environment in a target VPC.
You can launch recovery instances on AWS in minutes using a desired point in time.
When your primary site is up and running again you can use DRS to fail back to your primary site and
stop paying for the resources in AWS. We're not breaking the bank here because we're only paying
for the resources when we need them, instead of committing to a long-term contract for another
site. Even with a solid DR strategy, you should make sure you have the right business reasons.
One anti-pattern I see with customers is not quantifying the business impact of a disaster.
You can use something like a risk analysis to help you measure not only the financial cost
of a disaster, but in my case the loss of public trust toward New York City Government because
of lack of transparency. A risk analysis like you see here will help formulate the right DR strategy
for your business. Regardless of what DR strategy you use remember to test your DR plans. Running
drills can help minimize the number of unknowns during a failure. When conducting disaster recovery
drills, test things like isolating your recovery subnets to prevent potential conflicts with the
source location. You can do this using route table rules, network access control lists, or restrictive
security groups. If you use DRS, you can run disaster recovery drills with the service. You can
test and see how your applications run natively on AWS. Drills are non-distruptive and do not
impact your source servers. Plus they're free. But what about backups? Isn't backing up data enough?
Backing up data can protect you to some extent, but what happens when your data is corrupted? There's
a difference between backup and disaster recovery. While backup is primarily a means to protect your
data, DR refers to the plans and processes for quickly re-establishing access to applications,
data, and it resources after an outage. Both backup and DR maintain copies of historical
data, but simply having copies of data doesn't mean that will help keep your business running.
DR ensures business continuity by providing a robust tested solution that enables normal
business operation until the disaster is resolved. In this episode, we talked about patterns to ensure
business continuity of your on-prem applications by using AWS as your disaster recovery site.
Check out the links below to learn more about disaster recovery strategies on AWS.
Thanks for watching 'Back to Basics' and see you next time.