As an Enterprise Strategist, I find multicloud topics come up in many discussions rife with confusion, false certainty, and tentativeness. Companies are bombarded with conflicting messaging telling them to never adopt a multicloud approach or not miss out because “everyone is switching to multicloud.”
There are good reasons for pursuing or avoiding multicloud strategies. This blog focuses on eight proven practices for succeeding with multicloud, including when and where multicloud makes sense and how AWS is positioned to help enterprises succeed with their multicloud strategies.
Multicloud refers to using more than one cloud service provider (CSP) simultaneously across an organization. But first, let’s clarify some terminology. Using SaaS products, such as email or project management software, alongside a CSP does not constitute a multicloud environment. It is a good strategy, but it is not multicloud.
1. Pursue Multicloud Only to Fulfill Legitimate Business Needs
Although we advise AWS customers to fully realize cloud benefits by choosing a primary cloud provider, where the majority of their workloads are on a single CSP, there are valid reasons why a multicloud approach might be right for your organization. Situations that may require the complexity of a multicloud infrastructure include:
Mergers and Acquisitions
A multicloud environment can be created during an M&A transaction when the acquiring company is on one primary CSP, and the acquired company is on another. Welcome to multicloud! What comes next is not easy. The engineer in me wants to say consolidate—less is more. However, it may not make sense to consolidate immediately. Your overall technology integration strategy and assessment approach should be reflected in this process; make it part of your M&A playbook. What you move from one provider to another, when you move it, and what you leave alone may vary, but establishing an integration strategy is as important as preventing multiple instances of ERP from running forever.
Compliance
Regulatory agencies often advise companies to have a multicloud strategy; companies may believe they need multicloud to address data sovereignty issues. These requirements are typically vague and focus on practices instead of desired outcomes. We have found that AWS customers can often meet regulatory requirements through a reversibility plan that protects the organization should something go wrong with a CSP. (Check with your own compliance and regulatory teams.)
A good reversibility plan includes (1) ensuring the CSP contract provides enough time to execute an exit strategy, (2) establishing a beachhead with a secondary CSP, (3) actively managing the health of the CSP relationship through a framework, (4) determining an Exit Risk Impact, or XRI, for each CSP service in use that accounts for the extent to which native services for the CSP are used, (5) evaluating Steps 3 and 4 and establishing exit and risk mitigation strategies for the most critical and dependent services, and (6) conducting a biannual tabletop exercise to test and practice the exit plans for those services.
Regulatory authorities occasionally advise operating within a specific region to meet data sovereignty regulations. If a CSP cannot provide services within the required region, a company may need to engage an alternative CSP that meets regulations.
Desire to Leverage Long-Term Differentiated Capabilities of Another CSP
The fear of missing out drives some companies to want a bit of every cloud. This sounds good in theory but is rarely a good idea. When considering a multicloud approach to allow for best-of-breed, we recommend using the 80/20 Rule. Companies are better served by selecting a CSP that can solve the majority of their organization’s challenges rather than adopting a more diffuse strategy. Indexing on the 80% (and not the 20%) results in better efficiencies, talent retention, and value. While there may be specialized workloads that require a certain technology, those situations should be addressed case by case, where benefits and tradeoffs can be considered.
“The right workload for the right cloud” might sound like a good idea, and it can be. Make sure that the analysis of what constitutes the “right cloud” extends beyond considerations for a specific workload. Ask how spreading this workload onto an additional CSP impacts overall risk and cost by increasing complexity and burden on the engineering department. Make sure the value is enough to justify the costs.
Multicloud at the Holding Company and Primary Cloud at the Operating Company/Line of Business
For private equity organizations or large holding companies with several portfolio companies, it can make sense for each portfolio company to have its own CSP strategy (frequently driven by M&A). Here, having a multicloud strategy will probably forgo any volume discounts as workloads are spread among CSPs. But the other shortfalls around talent, fragmented workloads, and increased risks are largely bypassed as each organization operates independently.
2. Be Mindful of Multicloud Myths
Myth 1: Everyone is Adopting Multicloud Strategies
For the past several years, multiple advisory and media companies have claimed that a majority of Global 1000 enterprises report pursuing some form of a multicloud strategy. Flexera’s 2023 State of the Cloud report says that 87% of enterprises have a multicloud or hybrid strategy, while CIO.com claims 73% are pursuing multicloud strategies.
However, research from Bain & Company found that as of 2020, 71% of companies standardized on one CSP. The remaining 29% spent, on average, 95% of their cloud budgets with just one CSP, effectively pursuing more of a primary cloud strategy than a multicloud one. In our conversations with AWS customers, we have found more enterprises that align with Bain & Company’s findings, with few companies succeeding with a true multicloud strategy due to the increased complexity, cost, and time.
Myth 2: Multicloud Reduces the Risk of Vendor Lock-In
Some companies cite the fear of lock-in (from both contractual and technological perspectives) as a primary reason for pursuing multicloud strategies. In on-premises environments, companies are driven to large long-term capital investments and are often governed by lengthy, complicated service contracts. These are big one-way door decisions (i.e., difficult and costly to reverse) for companies and necessitate a strong focus on lowering risk.
To prevent lock-in, companies resort to two primary approaches: (1) deliberately using the most basic IT building blocks of compute, storage, and databases rather than leveraging value-adding differentiated services and (2) utilizing abstraction layers, brokers, and tools (e.g., Kubernetes, virtual machines, OpenShift, or Docker) to abstract CSP-specific dependencies. Both approaches treat the cloud as someone else’s data center instead of an enabler of digital transformation, thus trading speed, agility, and innovation for complexity.
I recommend that companies work to fully understand their potential switching costs if they need to exit their existing CSP through the XRI mechanism described above and the likelihood of that occurring. From there, it is possible to define the best approach to reduce lock-in by evaluating the cost and likelihood of needing to change CSPs vs. the strategic benefits of having a primary provider.
Myth 3: Multicloud Improves Availability
Reducing the risk of service disruption if a company’s primary CSP has an outage is an increasingly rare reason for adopting a multicloud strategy. In these cases, there is a belief that a company can simply and seamlessly switch its workloads to a secondary CSP.
Multicloud failover presumes that an application can be failed over to another cloud. As many companies have found, this is extremely challenging. Achieving this requires the company to maintain full portability between two CSPs, adding complexity, risk, and additional work in the belief that failover is possible. The basic compute runtime (whether VMs or containers) is a small part of the problem, so OpenShift, Anthos, or other container-moving solutions do not really help.
The problem in making failover work is all the CSP differentiators (e.g., the different network architectures and features, different storage capabilities, proprietary higher-level services, database layers, ML services, and possibly even application connectors, along with different security capabilities, etc.). And when workloads are spread across CSPs, a failure in either CSP could cause an outage. In this case, spreading workloads across CSPs actually increases risk.
Instead, I recommend that companies mitigate risk by “implementing and simplifying.” Target a specific workload or application for a single cloud, migrate it, master it, take cost and risk out, and repeat. Encourage deeper learning of CSP-specific features and capabilities via training and take advantage of higher-level CSP-specific services and tooling that are already integrated. Lastly, and maybe most importantly, take advantage of AWS’s Regions and Availability Zones. AWS’s capabilities in this area already provide AWS customers with excellent capabilities to ensure highly available and reliable solutions.
Myth 4: Multicloud Provides Better Pricing
Price competitiveness might be the weakest argument of all for multicloud. Organizations’ experiences with complicated, expensive software or data center contracts that lock them into multi-year agreements have made them wary when procuring IT services. Traditional procurement approaches have not adapted to pay-as-you-go purchasing, volume discounts, or the reality of price competition in the cloud. (AWS has reduced prices 129 times since its inception.)
The biggest single driver of cost reduction is how well-managed and optimized a company’s cloud environment is. Multicloud makes cost transparency, maturing operational intelligence, and experience optimization much harder to achieve. Multicloud also limits a company’s ability to take advantage of services that offer price-performance advantages, such as compute instances based on custom-designed chips like AWS Graviton. According to a 2021 Hackett Group study of more than 1,000 organizations, infrastructure spending as a percentage of total IT spending was 20% lower for AWS-exclusive customers compared to multicloud organizations.
Our experience has shown that companies do not anticipate the significant added cost and complexity of operating in multiple clouds. The cost to recruit, retain, and train talent on multicloud normally exceeds any costs that a company perceives they would gain in a head-to-head sourcing engagement.
3. Have a Clear Strategy and Governance to Support It
Just deciding to pursue a multicloud strategy is insufficient; you must also establish a strategy for delivering on your multicloud objective, including clear governance for which workloads will go where and why. Switching workloads between CSPs can be costly. Consistent evaluation criteria should be used to optimize workloads and their dependencies. If left up to individuals, the uncoordinated sprawl across CSPs is likely to erode any value the multicloud strategy sought to achieve. Evaluate CSP workload performance regularly and use your assessment as a key input to CSP selection, criteria, and future usage.
It is crucial to have comprehensive visibility into the total number of services, applications, and components being used across the enterprise as part of an overall governance strategy. Integral to this is a robust tagging strategy that spans CSPs and establishes clear ownership, usage, and environment (e.g., development, QA, stage, and production) for 100% of deployed resources. Everything should be tagged to an owner; if it is not tagged or an owner cannot be identified, it should be removed. This codifies governance rules and automates enforcement instead of creating blocks to progress (guardrails, not gates). Cost, operations, and security must be tracked, monitored, and acted upon in the same manner with the same depth of data and transparency across CSPs. A single tool for a given need that can operate across CSPs is preferred.
4. Do Not Spread Contiguous Workloads Across CSPs
Applications should be discrete and self-contained; ideally, they should not operate across CSPs for a specific workflow. Workflows spanning multiple CSPs introduce needless complexity, risk, and cost while complicating support, deployment, and architecture with little value added. When evaluating this type of design and business need, specific criteria and guiding principles should be established.
5. Applications Should Remain with Their Transactional Data
Care should be taken when developers are forced to move large volumes of data between applications in different clouds, especially with compute/applications deployed in one CSP and data storage in another. Such a situation adds complexity, latency, and costs that typically offset perceived benefits.
The decision criteria for determining a CSP for a workload should include a long-term view of integrating that workload with others. Will the data be needed for advanced analytics or ML beyond its current scope? Will the services provided be consumed broadly across other CSPs, or is it isolated to the workloads in that CSP? For more guidance and a decision model for deployment considerations, check out my colleague Gregor Hohpe’s Multi-cloud: From Buzzword to Decision Model blog.
6. Use Containers but Realize They Do Not Solve Every Use Case
Using containers is generally a good idea for any modern application, and they will help with some elements of portability. But containers do not work in all cases (e.g., large monolithic applications), and they do not solve all the issues (especially data, policies, and security) around portability between CSPs. You also need to be cautious of what operational overhead containers will add and ensure your teams are skilled to operate in this way.
In short, containers can help to a degree, but they are only as useful as your application and teams enable them to be.
7. Have a Single Cloud Center of Excellence (CCOE) but Specialize Within
As we advise many AWS customers, you should leverage a CCOE within your organization to provide leadership, standardization, and acceleration of your cloud journey. When it comes to multicloud, we find the most successful companies have a single CCOE but specialize within that CCOE the skills, tools, and mechanisms particular to a specific CSP. We find that when AWS customers have multiple CCOEs for each CSP, it often leads to divergence, reengineering, and waste instead of a more coordinated approach through a single CCOE.
8. Make Sure Security is Always a Top Priority
Multicloud makes security harder by increasing the risk of unauthorized access or data breach. Multicloud forces companies to deal with multiple security models across CSPs in areas such as identity management, network security, asset management, and audit logging.
This complexity makes transparency harder and increases the burden on security teams, elevating risk. Although they are not unique to multicloud, several core security practices become more important: (1) shifting security left by automating and embedding it into delivery pipelines, cloud environments, and team priorities; and (2) encrypting data at rest and in transit within or between CSPs.
One useful approach to multicloud adoption is creating a single destination for security data (i.e., a single pane of glass). Augment this with cloud-native tools developed by every CSP to present this data so it makes sense within that environment.
Conclusion
For most organizations, a primary cloud strategy provides the most value through simplicity, focus, and risk mitigation while allowing companies to deepen their partnership and working knowledge of their primary CSP and services. This increases an organization’s ability to take advantage of more sophisticated services and better attract and retain talent while delivering value to companies faster.
There are times that a multicloud approach makes sense, but companies should take care that this decision is driven by business needs with full awareness of the tradeoffs it will incur. In this case, we recommend a cloud model focused on applications and business workflows that can each be delivered from a single CSP, are unlikely to share data across CSPs, and have clear governance for which workload goes where.
To learn more about the AWS services that can help centralize and simplify management and monitoring of hybrid and multicloud environments, provide access to all your data wherever it is stored, and run applications on AWS, on-premises, and other clouds with AWS container services, check out the AWS Solutions for Hybrid and Multicloud.
