Hello, and welcome to this lecture covering your business continuity in the cloud.

One aspect of your migration strategy should include the changes this makes to any business continuity or disaster recovery plans your organization has. The cloud provides a great platform of building resiliency into your business, which can greatly enhance your recovery plans when it comes to a disaster striking in whatever form that may be. This could be anything from a severe earthquake, potentially taking out entire data centers within a geographic region, to a subset of critical systems becoming unavailable due to a configuration change by human error. Whatever the reason and how you cast a service interruption as a disaster is down to you. However, what is essential is that you have a set of policies and procedures that dictate how to recover from such instances.

Prior to cloud adoption, you would likely have this set of procedures defined, utilizing off-site premises with capacity to implement and run your key production systems, utilizing back-ups to bring your services and business back to an operational state as soon as possible, with as little data loss as feasibly possible. Now with the adoption of the cloud, should a natural disaster occur and your premises become unusable, you will obviously still need new premises for your employees. However the services hosted within the cloud will be unaffected. Should the disaster occur in the cloud vendor's data center, then you'll experience problems unless you have configured high availability within your environment to handle such an event.

The cloud allows you to deploy applications and services in a highly available and resilient way. Any critical system should be architected with failure in mind, allowing it to continue to function should a major outage occur. One of the best ways to do this is by utilizing multiple geographic locations to run the systems. You're trying to ensure it continues to run even if a complete data center within the vendor is made unavailable.

Some of the vendors offer whitepapers on the best way to achieve DR within their cloud, and the following points and methods are detailed in the AWS DR whitepaper, which can be found here. The models and best practices discussed to help with business continuity, are backup and restore, pilot light, warm standby, and multi-site. Each of these models offer a different RTO, recovery time objective, and RPO, recovery point objective.

Before we go on, I just want to explain what each of these are for those unaware.

RTO is defined as the maximum amount of time in which a service can remain unavailable for before it's classed as damaging to the business. For example, if your RTO for a service was two hours, and your outage occurred at 2:00 in the afternoon, then your service must be back up and running by 4:00 in the afternoon, before unacceptable damage to the business was experienced.

RPO is defined as the maximum amount of time for which data could be lost for a service. For example, if you had an RPO of eight hours, and you had an outage at 9:00 p.m., and then resumed your service at 10:00 p.m., you would have to ensure your restore of data was from a backup from 1:00 p.m. or later that day.

OK, so now I want to give you a high-level overview of the different continuity models, starting with backup and restore.

If you're using the cloud to store backups of your on-premise architecture to a highly durable and cost-effective storage solution, then this allows for a rapid access to your backups should a disaster occur. As long as you have an Internet connection, you have the means and ability to perform and restore to any location. However, this is only dependent on the speed of your Internet connection, or any other direct connection that you may have, so bear this in mind. Some providers offer solutions to transport huge datasets physically from the cloud to your data center's door. For example, AWS Import/Export Snowball service. You could also simply restore your backups to some provisioned instances that you may wish to spin up in the cloud to help speed up the recovery process.

OK, the next model is the pilot light method. This essentially requires you to have the minimum number of computing database instances required to operate your core services running separately to your production environment. This core set of services would then be replicating data from your production environment, ensuring that the core data is up to date should it ever be required. If a disaster did occur, then this core would then quickly be able to resume the core services whilst you spent time scaling out to support the demands of the rest of your environment, without taking a huge amount of time to restore data.

The warm standby is an extension of the pilot light method. But it's a fully functional system with an increased fleet size compared to that of the pilot light, therefore reducing your RTO. You could even use this warm standby as a testing environment if need be. Again, should a failure occur, this smaller version of your production environment could take the load in services, and then scale up to the full demand of your production environment very quickly.

Lastly, multi-site. Multi-site is exactly that, whereby you use the cloud to re-create either your on-premise services within the cloud, replicating data between on-premise and the cloud, or replicating your existing cloud architecture to another region within the cloud. All elements of your infrastructure should be completely replicated to allow a disaster to happen to your on-site infrastructure, but then taken over by those within the cloud. This offers the quickest RTO and RPO from the four methods discussed.

This takes us to the end of this lecture. Coming up next we take a look at why a proof of concept should be considered.