Why the Multi-Cloud Approach May Not Be All it is Cracked Up to Be

According to a survey commissioned by Microsoft, 86% of IT and business decision makers plan to increase investment in hybrid and multi-cloud technology in the next 3 years. It seems there is a general consensus that the multi-cloud approach is the way forward, recognising such technology as being critical to meeting business demands. Not only does it reduce an organisation’s reliance on any one cloud platform, but it also provides greater flexibility and scalability, among other perceived benefits. However, this fixation on ‘multi-cloud is recommended’ is misplaced and distracts us from the more pertinent question: “When is the multi-cloud approach advisable?” Before delving into this question though, it is worth clarifying what we mean by multi-cloud.

A single business running Kubernetes on Google, Office on Microsoft and serverless applications in AWS does not constitute a multi-cloud business in our books. In this instance, a particular cloud vendor is leveraged for each specific use case. Rather, a multi-cloud strategy means splitting an application across multiple public cloud vendors. In other words, an application is built with components – be it, foundational, computing, storage, or networking – from different public clouds; thus, replicating the infrastructure.

Inevitably, this introduces significant complexities, so there must be a strong strategic reason for undertaking such a project. It would need to be essential, or the benefits should, at least, outweigh the operational costs of running the additional infrastructure.

How do you determine when it is appropriate to convert to a multi-cloud environment?

A multi-cloud strategy is a costly pursuit and requires mastery of the multiple cloud vendor landscapes employed, along with expertise to execute some form of cloud customisation or tuning. Typically, cloud vendors offer discounts based on resource utilisation; whereby the more you use, the greater the discounts received. Therefore, the size of the business in question, is a principal factor to consider. Indeed, unless the business is a large enterprise, discount offers for resource usage will not offset the additional infrastructure expense. The larger an organisation, the more likely they will also have the means to hire the required expertise.

Another element to take note of is the purpose of the application. One must ask themselves if the application is mission critical in the same way an air traffic control application is. Or, if failure of the application would pose a threat to life, such as life support machines. Even then, shifting to multi-cloud may not necessarily be justified. While these systems need to survive outages, and entire region outages have been known to occur – though rarely, multi-region architectural patterns offer an excellent workaround. In fact, it may even be better than deploying multi-cloud computing within a distinct region. A natural disaster, for example, could potentially wipe out infrastructure across that territory, rendering any multi-cloud approach utterly useless.

Of course, geography is also something to take into account; particularly, with regard to data sovereignty rules in certain industries or countries which prevent data from leaving or being processed beyond specified borders and boundaries. Once again, deciding whether multi-cloud is the right path to go down, boils down to purpose and criticality of the application.

A multi-cloud approach isn’t always safer

Last but not least, is the question of security. Cloud security relies on the principle of shared responsibility. In short, public cloud vendors as well as consumers or their Managed Service Providers, all bear the responsibility of securing workloads and applications. The difference with multi-cloud security is that this duty is extended to numerous cloud vendors. On the one hand, this allows for risk to be spread out. Should one platform be compromised by an event such as a brute-force DDoS attack, organisations can readily switch to another. Nevertheless, this does add complications to the implementation of security measures as leakages would need to be contained and data protected across more than one platform.

Granted, public cloud vendors typically possess in-built protections to mitigate against threats like DDoS, and other security tools like Web Application Firewalls, Content Delivery Networks and Edge Locations can be incorporated. However, external threats are not always the biggest issue to worry about. Insider threats and cloud misconfigurations can cause just as much damage, if not more.

In fact, a report from Divvy Cloud indicated that cloud misconfigurations were responsible for a staggering 196 distinct data breaches resulting in 33.4 billion data records being exposed at a cost of $5 trillion, across 2018 and 2019 combined.

In order to minimise the impact of the insider threats, businesses must ensure that the policies attached to each identity, whether machine or person, are reduced to least privilege and expire on completion of a required action. This is a considerable task to accomplish on a single cloud setting but it is exacerbated across the multi-cloud environment. It calls for detailed knowledge of each cloud vendor’s unique policy implementation language, and an understanding of how to scope down permissions. Dealing with cloud misconfigurations also demands the same attention to detail and can easily be missed within one hyperscale environment alone.

If the aim of switching to multi-cloud is simply to spread risk, there are actually other methods to do so without venturing outside the use of a single cloud vendor. Consider AWS, which essentially offers zero-trust containers as only the user who creates the account can access or do anything with it; nothing can move in or out of the account unless explicitly permitted by the root user. Organisations can then create various AWS accounts for development, test, pre-production etc. all for the same workload. By using multiple accounts, the risk is dispersed, and any issues are limited to a single account. A similar method can be achieved using Projects within the Google Cloud Platform. The only thing that larger organisations will need to be wary of is ensuring that the accounts or projects are well-organised and structured to avoid problems down the line.

To conclude, while multi-cloud is purported to offer a wealth of benefits, this is true only for a select few. In reality, there are only a handful of use cases where the multi-cloud strategy is appropriate. One would need to conduct a thorough cost-benefit analysis, verifying that the business is large enough to take advantage of cloud vendors’ discounting models and have the expertise needed for an effective multi-cloud programme. What’s more, the purpose and criticality of the application being discussed, must necessitate this change. And even then, all other options should be exhausted first.

To find out more about Adarma and how we can offer cloud security consulting to help you manage and secure your cloud environment, please contact us.

Stay up-to-date with the latest threat insights from Adarma by following us on Twitter and LinkedIn.