Hello, and welcome to this lecture.

Moving your services out of your own data center environment and into a third-party vendor's data center can cause issues and concerns when it comes to contractual obligations.

How will this move to the public cloud affect your service level agreements, your SLAs, with your customers? Will the cloud provider be able to operate at the same level? What reassurances can you offer your customers?

Having less visibility opens you up to a lot of unknowns when it comes to cloud production issues, especially when the resolution of those issues are out of your control. What kind of resiliency does the vendor have surrounding specific services across their environment?

It's important to look at your chosen vendor SLAs for each service that you are intending to use. Each service will have its own SLA with its own set of definitions of criteria to be met.

As an example, when looking at the SLA for the AWS EC2 service, you can see that it's made up of a number of different definitions, such as the Monthly Uptime Percentage, the Region Unavailability, and the Unavailability of EC2 and EBS.

Now, if we compare these definitions to another AWS service, AWS S3, you can see that it has different definitions and criterias, such as the Error Rate.

Be sure to analyze these SLAs to have a good understanding of what parameters the vendor has to abide by with regards to availability of service. Identify areas that fall outside of any SLAs you currently have in place with any of your customers. Depending on the type of service plan you have with your cloud provider, you may be able to negotiate specific terms surrounding SLAs that affect customer agreements.

However, these are likely to be small changes from the current SLAs that are stipulated. You will find that the cloud provider has the right to change the SLA terms as and when they see fit. The services they offer are ever changing, and so to keep up, so will the SLA agreement.

Be sure to review these SLAs regularly to ensure compliance with any contractual agreements you may have.

Sometimes, you may feel that you don't want to rely on statistics of the SLAs to ensure you maintain stability of a particular system or application. In this case, you can of course build in higher availability by architecting your systems to be fault tolerant across different geographic regions.

By doing so, it would protect you from a major incident on the cloud provider's part should a particular service offered fail in one region. If an incident occurred, your environment will handle this failure by utilizing the high availability system you architected to maintain reliability of service.

However, this does of course cost you the additional resource, and so it's a fine balance of defining if that particular workload requires that level of continuity.

Compliance controls.

In a standard on premise environment, you would have likely been audited by external auditors to check your IT infrastructure for compliance against security and data protection, or control surrounding PCI DSS, ISO, SOC, or even HIPAA.

There are many more compliance programs, but these are some of the most common.

To maintain compliance to these programs necessitates the need for the infrastructure which ultimately confirms that your customers' data is protected, and so is of course of the utmost importance.

Some responsibility of these compliance controls can now be passed over to the cloud provider, specifically elements geared toward physical security of the host, as we do not have access to the physical infrastructure. As a result, cloud providers have to abide by a huge set of compliance programs on a worldwide scale.

The large cloud providers, AWS, Azure, and Google, operate their services on a global level and therefore have to meet regulated controls of compliances from hundreds of different countries.

This is a great comfort to organizations operating within the cloud, as it's likely that the compliance of the services they are using are far greater than that compared to their own infrastructure.

For a full list of compliances offered by the leading cloud providers, please take a look at the links on the screen. You will still need to be responsible for specific compliance controls, and so do not think your provider will cover everything.

However, there are services that can help you with maintaining with this compliance. For example, the AWS Config service allows for the continual monitoring of the configuration of your assets. This service can use specific rule sets that check for audit compliance controls that relate to PCI DSS or HIPAA.

Reports can also be generated to verify conformity, allowing you to present to auditors.

We have come to the end of this lecture, so in the next lecture, I will cover some of the business risks involved.