5 Recommendations to Build Security into Your Multi-Cloud Strategy

Let’s Build Security Into Your Multi-Cloud Strategy.jpeg

By Mario Duarte

Do you find it challenging to develop a multi-cloud strategy that accounts for security? You’re not alone.

Organizations today use an average of 4.8 different clouds. The benefits of multi-cloud are undeniable, including added flexibility, data redundancies that reduce or prevent data loss and downtime, the ability to match cloud offerings to IT needs, and the avoidance of a lock-in to only one cloud provider. It’s no wonder 81 percent of organizations report having a multi-cloud strategy.

However, 77 percent rank security as the top cloud challenge. While multi-cloud is a smart decision, it’s extremely hard to get right, and the added complexity of securing data makes it an even more daunting proposition.

At Snowflake, we’ve provided our cloud data warehousing service on AWS from the very beginning. We’ve since added the option of deploying Snowflake on Azure. Our goal was to offer the same secure service on Azure that our customers receive on AWS.

To achieve this cloud-agnostic status, we needed to address substantial operational obstacles and fully answer the security challenges that multi-cloud presents. This endeavor ended up taking longer and proved to be harder than we imagined.

From that experience, five recommendations have emerged so you can benefit from our hard-earned learnings, and execute on your own secure multi-cloud strategy.

Trifecta of Obstacles

My favorite way to describe the multi-cloud challenge is through a driving analogy. For anyone who has spent their life navigating roads in America, it’s a bit harrowing to drop into Australia and be confronted with left-hand driving. Everything is the opposite of your years of training and know-how, which makes the experience feel unnatural. After some practice and hours on the road, you eventually adjust.

Now let me throw a curveball into the mix. What if you needed to switch between left-hand and right-hand driving at a moment’s notice? This scenario is akin to what DevOps teams are asked to do when they’ve trained on one cloud provider and then must work with another. The basic concepts might be the same, but the execution is entirely different.

There are three main reasons why this is the case:


Each cloud provider has created or adopted its own terminology. In order to sound credible, DevOps must speak fluently in the correct cloud language at all times. For example, mixing up Virtual Private Clouds (VPCs) in AWS with Virtual Networks (VNETs) in Azure is an immediate tip-off that you lack proficiency or expertise.

Unfortunately, this example barely scratches the surface, as everything from basic concepts to proprietary technology uses different words and parlance. Simply put, cloud providers lack a common language to connect them.


The underlying technology is even more complicated. AWS uses an authorization and authentication infrastructure built on roles, IAM users, service policies, etc. Azure’s infrastructure is akin to Active Directory. Without proper training on each, it’s challenging for DevOps to understand and maintain the same features across clouds. This expertise takes time and practice to build. Once trained and proficient, DevOps must discover commonalities across cloud providers in order to create efficiencies and address security challenges, all while keeping cloud provider specifics unmuddled.


Given the complexities of working with different cloud providers, companies typically default to separate groups within DevOps to ensure that each cloud infrastructure is staffed with experts.

While this strategy may work as a short-term fix, it’s important to recognize all of the future problems it creates, including silos, communication barriers between team members, double the work when issues arise, and the inability to respond quickly to customer demands. Instead, invest the time, effort and resources upfront to ensure that your DevOps team is strategically aligned and can standardize operations.

How to Build a Secure Multi-Cloud Platform

The following recommendations represent our thinking on how to formulate and implement a multi-cloud strategy that won’t expose you to security holes or weaknesses.

1) Ask Questions

You must unearth your strengths, weaknesses and points of failure upfront in order to address them properly. Ask a multitude of questions that drive at how clouds are connected, what systems and tools are used, and how capable your team is at making multi-cloud secure.

Most importantly, focus on where the convergence of technologies happens because that’s where you’ll find potential security issues. Non-automated processes are most likely to introduce problems, while automation is difficult and takes a long time to get right. However, committing to automation helps you avoid misconfigurations, which are often the genesis of potential security breaches.

2) Review Third-Party Security Reports

While multi-cloud providers document their sources and security measures, you may be surprised to discover that few companies do this well today. If complexities and differences between cloud environments are described generically, that lack of transparency should send up a red flag.

Make sure that any third-party vendors you work with have an independent source, such as a SOC 2 report or other third-party report that reflects in great detail the differences between implementations with AWS, Azure, and/or Google Cloud.

3) Rewrite Code

Here’s the unfortunate truth: Until the industry catches up, the onus is on your team to build out its own integration. Your team will spend long, hard hours figuring out how to rewrite code to connect different cloud providers securely. This investment starts with addressing the three obstacles above: terminology, technology, and team.

Once your team has learned the new cloud provider’s terminology and infrastructure and is well-versed in the APIs, they can determine configuration methods for each cloud provider and decide what to port across multiple clouds. The final step is writing applications or infrastructure orchestration scripts that are sophisticated and flexible enough to standardize functions and automate processes.

4) Train Team Members

If you’ve tried to recruit DevOps people who work with both AWS and Azure, you already know how challenging these strategic resources are to find. Unless you get lucky — in which case, hire that person immediately — you’ll need to devote time, money and resources to training your current DevOps engineers to become cloud-agnostic.

Best advice? Immerse your senior team members in the new cloud provider and watch them expand their skill sets as they build the secure multi-cloud environment you desire.

5) Partner Wisely

When it comes to security, multi-cloud is still in its infancy. However, the good news is that enterprises and SaaS providers that take the time to figure out how to build secure connections across cloud providers will reap the rewards of this hard work for many years to come.

The even better news is that you don’t have to do it alone. Partner with the right SaaS providers to get ahead of the curve. Organizations such as Snowflake have invested the resources and time to support multi-cloud, and we represent the type of partner that will help ensure security for your users, both now and in the future.

About Mario Duarte

Mario Duarte is the Vice President of Security at Snowflake.

More About Mario