iTranslated by AI
re:Invent 2025: Debunking Multicloud Myths and Practical Principles for Leaders
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden valuable information more accessible. The presentation we're covering in this project, based on that concept, is:
For re:Invent 2025 transcript articles, please refer to this Spreadsheet for compiled information. Please check it.
📖 re:Invent 2025: AWS re:Invent 2025 - A leader's guide to navigating multicloud strategies and decisions (SNR204)
In this video, Tom Godden, Executive in Residence at AWS, provides practical insights into multicloud strategies. He identifies situations where multicloud is appropriate, such as M&A and independent business units, while clearly refuting four major misconceptions: "everyone is doing it," "it avoids lock-in," "it improves availability," and "it provides price competitiveness." He advocates an 80/20 primary cloud approach and points out failure patterns such as distributing contiguous workloads, ignoring data gravity, and over-relying on abstraction layers. He presents nine practical principles, including establishing a unified Cloud Center of Excellence, formulating clear workload placement criteria, and ensuring consistent security and governance. Research by Hackett Group shows that single-cloud infrastructure costs are 20% lower than multicloud.
- This article is automatically generated, aiming to maintain the content of the original lecture as much as possible. Please note that there may be typos or incorrect information.
Main Content
The Importance of Multicloud Strategy and AWS's Commitment: An Introduction by Tom Godden
My name is Tom Godden. I'm an Executive in Residence at AWS. Our Executive in Residence team consists of 15 members who are former Chief Information Officers and Chief Technology Officers from companies like Coca-Cola, McDonald's, Capital One, Airbus, NASA, and JPL. I was the Chief Information Officer at Foundation Medicine, the largest genomics company in the world. I spend a lot of time with customers, helping them with their digital transformation, cloud transformation, AI, and data initiatives.
One of the topics I spend a lot of time talking to customers about, and even more so recently, is multicloud. And how to navigate those strategies and the decisions that impact us. Multicloud signifies an extremely crucial decision. It can shape your entire technology strategy. It's one of those pivotal choices you must make as a leader.
In my role, I've seen countless multicloud discussions, and they've been a mix of confusion, contradiction, assumptions, and often misplaced confidence and a lot of hesitancy. You're probably being bombarded with conflicting messages like you should do multicloud, you shouldn't, you should do it to some extent. It's a difficult situation as a leader. The freedom to innovate isn't just a slogan; it's our fundamental promise to you.
We believe that cloud providers should expand your choices, not restrict them. That's why our commitment to interoperability is a key strategy and one of the reasons many people choose AWS over competitors. That's our commitment to being interoperable across clouds. We've built a comprehensive suite of tools to help you build, migrate, operate, and manage these workloads. These multicloud capabilities are not add-ons; they are fundamental features.
However, the question still remains: Is multicloud right for me? Let's explore that a bit. The answer is, it depends. What works perfectly for one organization may not work perfectly for another. But trust me, we'll delve a little deeper and talk a bit more. Unfortunately, it's not as simple as it looks. There's more to it than meets the eye.
When is multicloud the right strategy for an organization? Our experience working with thousands of companies shows that most achieve better results by operating with one primary provider. However, there are valid reasons for some companies to move to a multicloud environment. I think it's a reality we all face, so let's explore those scenarios. It's easy to stand up here and say one provider is better, but the reality you're living in is probably not that.
Before we dive deeper, I want to take a moment to clarify what we mean by multicloud. I always make sure to clarify this. It's not about using different SaaS products, email solutions, CRM solutions, or other clouds. That's not multicloud. True multicloud means actively using at least two cloud service providers for meaningful IT operations. We're talking about running significant workloads across different providers in a substantial way.
So I'm going to share with you nine principles that I've learned and developed in working with so many customers on their multicloud journeys. These are borne out of continuous conversations around this topic. We've seen organizations struggle and succeed with multicloud across many industries. And the best practices I'm going to talk to you about are borne out of real conversations that we've had.
Principle 1: Multicloud Should Not Be a Solution Looking for a Problem
Let's start with our first big insight regarding multicloud: it should not be a solution looking for a problem. Multicloud brings complexity. There's no doubt about it. So, you need a legitimate business need driving this decision. We've seen far too many organizations pursue multicloud without a clear rationale. The real question isn't whether we should do multicloud, but what business problem are we trying to solve?
Let's look at where multicloud adds value. If you're operating in a primary cloud and you acquire another company, and they're using a different cloud, then welcome to the multicloud world. Now, you might be luckier than I was when I spent 20-some years as an executive.
I was never allowed to rewrite the technology of the company I acquired. I had a perfect strategy. Everything was neat and tidy and everything was up and running. And then I acquired a company and it threw everything into disarray. You know the next thing isn't easy. My engineering instincts want to consolidate, less is more. But in reality, rushing to integrate might actually slow you down and delay time to value.
But when you come into a merger and acquisition, you've got to understand how you're going to operate in this new world. Some points as you plan out your roadmap. Think beyond just the technical aspects of migration. Your business impact should drive your decisions. Align your cloud integration strategy with your broader M&A strategy. Don't rush into deciding where everything should be placed. Take the time to develop thoughtful placement criteria. We're going to come back to that later. And keep the business momentum going throughout the entire process. Your customers are still relying on you.
Another one that we see a lot is the desire to leverage more capabilities across different cloud providers. This cloud provider has this great feature, this one has that. And they have this vision of creating a Frankenstein monster version that combines the best parts of all of them. Who would argue against that? It sounds fantastic. It's tempting to pick the best cloud for each job, like being at a buffet. But again, with each new provider you add, you're adding complexity, operational, and governance challenges, and problems across your organization.
If you're managing multiple independent lines of business, this might be another way you end up in multicloud. You have a large enterprise where this division is running on one cloud and this division is running on another. This mostly avoids many of the challenges of multicloud. There are still some challenges, but you can mostly make this business unit an expert in one cloud, and this business unit an expert in another cloud. They're not sharing resources, they're not sharing assets. They're basically operating as independent companies as part of a larger holding company. Multicloud, but no problem. What you lose out on is the ability to negotiate a better deal because you've split your workloads between clouds, but mostly you can avoid that, so this is a good reason.
But when you leverage these different capabilities, be strategic. Take the time to understand each provider's volume discount structure and carefully plan your purchase commitments. Balance the interdependencies you see and always, always, always prioritize your business goals.
Business decisions should drive your cloud strategy, not the latest technology trends, not the latest news from the pundits, or some pithy short comment somebody puts out on LinkedIn saying, "this is what you should do." Think about what really matters to your business. Speed to market, cost predictability. How do you leverage your talent? And there's a great quote from Bezos. There's only one thing your competitors can't copy: it's that you were first. Everything else is replicable. Don't worry about patent protection. Well, do worry about it, but it expires, and you'll find out when you go to China that it doesn't work. The only way is to go fast. So, you really need to ask yourself about this multicloud. Is it making us go faster?
As you can see, this workload placement impacts everyone, not just the IT team, from finance to security to operations. We've seen time and time again that when you concentrate expertise on one platform, companies get more value. And when you disperse it across multiple clouds, you slow down time to value and you increase complexity. So, be clear about why you're pursuing multicloud. Don't assume everyone understands the rationale.
When I was a CIO, I would walk the halls and I'd meet a new QA person. Hi, I'm Tom. Have a little conversation in the hallway, get a little executive time with them. That's a good thing. But at the end I would always ask them, what are our top three priorities and why? And if they didn't know the why, well, I wasn't happy with them, but what I did was I went to their boss. Even if it was multiple layers down in the organization. Because if we all don't understand the why, they can't help you with the trade-offs as you try to implement your multicloud strategy.
They don't know. Should I do this or should I do that? I thought we were doing multicloud for this reason. Is what I'm doing contributing to that? So what do they do? Well, they either make bad decisions or they stop and wait for a HIPPO to make a judgment call, as we call them. Now, I'm not talking about the animal here. HIPPO stands for the highest-paid person's opinion. And most of the time, they don't know what they're doing. They're too far away from the problem. And I was, I was an executive. I was too far away from the problem. So we need our people to be empowered to act. Document this why, follow up, be obsessed with it.
Principle 2: Examining Three Myths About Multicloud
Alright, we've talked about the primary considerations for why to go multicloud, now let's consider our second insight: common myths to watch out for. Many assumptions about multicloud feel good, but they don't stand up to scrutiny. First up, the misconception that everyone is doing multicloud. Is that true? Headlines suggest widespread adoption. Everyone's doing it. For years, advisory firms have claimed that most of the Global 1000 are pursuing a multicloud strategy. Pursuing a multicloud strategy, not successfully running workloads that provide value in a multicloud environment.
Flexera's 2023 report suggests 87% of enterprises have a multicloud strategy. But a Bain study shows that 71% of companies still standardize on a single cloud, and the remaining 29% also spend 95% on one provider. This means an overwhelming majority of companies are still in a primary cloud model. We shouldn't be fooled by this. Again, it should be driven by business value.
So the first thing you need to know is to really be clear about why you're considering it, no matter what those flashy reports or those pithy LinkedIn posts say, by the way, I write pithy LinkedIn posts too, so feel free to follow me and you'll find out what I'm doing. Make decisions based on your business needs. Your organization's requirements are more important than any industry analyst. And look at the spending patterns. Realize that many companies that say they're multicloud are actually primary cloud, and don't get caught up in that.
Our second myth is that multicloud helps avoid lock-in. But isn't this legacy IT thinking? Let's be honest, nobody wants to be locked in. We all want options. But is it realistic? What problem are we trying to solve with it? Many companies cite fear of lock-in as a primary reason for pursuing multicloud. They seek freedom of choice, control over technology choices. And some worry what if a cloud provider's focus changes and they start doing something different. And others simply don't want to rely on a single provider for their entire digital foundation.
But remember, every technology choice creates lock-in of some sort. As leaders, the key is understanding what those trade-offs are and how you manage them. A simple model might help you move beyond that reflexive instinct. First, we all need to accept that we live with lock-in in many aspects of our business, our technology, and our personal lives. We might even be happy to embrace lock-in if we get enough value. This creates a decision matrix that you can use to objectively look at these four scenarios. We're trying to look at them objectively.
As we go through this, lock-in equals bad is a mindset that many of us have, but we need to embrace this lock-in. And as you look at this, you might say, oh, okay. Down at the bottom you have disposable technology. Cables for your smartphones, your devices. The European Union is forcing standardization, but it's easy to change them. And as you go along the axis of uniqueness, well, I have a presence on Twitter and I get value out of that. Can I switch to Instagram? Yeah, I can switch. I'm not locked in. And as you look at switching costs, well, my cell phone service is one provider, if I want to switch to another, I don't really get a lot of uniqueness by switching. I mean, they're all more or less the same, it's not that hard.
But as you look at this, and you think about, say, your smartphone, something like iOS or Android, you can get a lot of value by switching. At the same time, you're locked in. You probably couldn't pry me from my phone with dynamite. And it's not because I love it, it's because I'm in an ecosystem. My kids communicate with me on it. I make phone calls and FaceTimes, and I do all this other stuff on it. So I've embraced that lock-in. Why have I embraced that lock-in? Because I'm getting value. So you have to look when you see this lock-in, are you getting value for it?
Another thing you see here is abstraction layers. People come up and talk to me, and I've worked with these companies, and they say they're going to build an abstraction layer. So we're going to have a cloud, and we're going to put an abstraction layer over the whole thing, and people are going to communicate with the abstraction layer. Sounds like a great way to spend millions of dollars and get fired. I've never seen it work. If you have, find me later and tell me how you did it.
Because the problem is so many of these critical components that we rely on cannot be abstracted away through an abstraction layer. Provisioning, cost management, security, most databases, monitoring, event management—these all behave differently. These abstraction layers might solve 15% of your problem at a massive cost. And don't forget the time, because now you're going to spend all your time building the abstraction layer. Oh, by the way, AWS released a bunch of new stuff today, so feel free to go back and update your abstraction layer. There's new stuff. Not to mention when other cloud providers change.
It sounds like a good idea, but don't let your architects do it. You're going to add significant cost, complexity, and risk to your overall technology decision. Multicloud does not help avoid lock-in. It creates different types of complexity and constraints. Multicloud interoperability is crucial, and you need to plan for it and understand it. You must define and plan practical strategies for reducing lock-in.
So I'm not telling you to ignore it. Take your primary cloud provider, analyze it. What are you using? Why are you using it? How are you using it? And do a table-top exercise with your leadership team about what it would take to move off that provider. It's a good exercise, a good risk exercise to understand. Regulators will love it. Evaluate the functions that you truly depend on and develop mitigation strategies or migration strategies other than an abstraction layer.
And leverage the value of the cloud. Because the value of the cloud isn't just that you're running a data center somewhere else. It has good provisioning, it scales up, it scales down, it has elasticity. The true value comes from those cloud-native capabilities, the unique capabilities of each provider. Where you can get higher-level value-added services beyond just basic compute instance provisioning. And we can't abstract those away.
Myths 3 and 4: Misconceptions about Availability Improvement and Pricing Strategy
The third misconception I encounter is that multicloud enhances availability. This is a common belief. Many assume they can seamlessly switch workloads. Sounds like a great idea, doesn't it? You put one on this cloud provider and one on that cloud provider, and you replicate all your data between the two, and if one has a problem, you fail over to the other. Don't let your engineers convince you they're right.
You're much more likely to create your own availability problems by trying to keep these two instances in sync and available and running. I've seen it time and time again. In the early days, multicloud customers often thought they could do this to reduce outages. Based on the premise that one cloud might go down, which sounds like a good idea. Lydia Leon, an analyst at Gartner, notes that multicloud failover reaches levels of complexity, cost, and impracticality. Preparing for this unlikely scenario often creates operational risk on a daily basis.
Think about it. You're trading off a potential possibility that something might happen. Now, remember, Werner Vogels says everything always fails, so I can't promise you it won't fail. But you're trading off a potential possibility that it might fail with increased operational risk today, and tomorrow, and the next day.
And we add this complexity thinking we can abstract it away. Here's a crucial truth: it increases risk. When customers try to build these things, they're often forced to a lowest common denominator approach because they want to have an abstraction layer and then they can't use those high-level services. Instead, if you truly need it, you're better off using a multi-region strategy. Again, driven by business needs. If a single region with availability zones isn't enough, then go to a multi-region approach. Put 50% of your workload in one region, 50% in another, and if one fails, you go to the other. But doing it within the AWS infrastructure is much more resilient. As we look back at some of the challenges and problems that have happened within AWS, they've been confined to a single region. If you had a multi-region strategy, you would have gotten through it.
So let's talk about the harsh truth. Another problem is that multicloud requires multiples of everything. You have to build cloud-specific landing zones. Visibility becomes a challenge. Multicloud leads to data duplication. With a primary cloud, you benefit from native service integration and immediate access that platform provides. Because, again, multicloud adds significant complexity across your organization. Security teams struggle to find fragmented data. GDPR's right to be forgotten is going to be tough. Where is that person's data stored? It's in seven, it might be over here. Otherwise, a great strategy.
Teams have to master those multiple security type challenges, and frankly, resilience capabilities vary widely by provider. Choose a cloud service provider with strong resilient options. Amazon is the only cloud provider that has multiple availability zones per region in every region across the world. Target specific workloads, migrate, master, optimize, reduce costs and risks, and repeat. If you want to talk more, find me later. We can talk about chaos monkey strategies and how to test your organization for high availability and whether that multi-region type model is going to get you the resilience you truly desire.
Principle 3: Establishing a Clear Strategy and Governance
Now, let's move to myth number four: multicloud provides a pricing strategy. Don't let your procurement people lead you down this path. This is old school thinking. I had an old school thinking procurement person. Sounds like a great idea, let's create competition. The goal is to create competition among vendors and drive down prices. This approach doesn't always work. Most of these contracts lock companies into multi-year agreements with limited flexibility, but cloud has fundamentally changed this model to volume type dynamics.
So let's quickly talk about cost optimization in the cloud. With a primary provider, you pay once for all features instead of duplicating costs. And the biggest driver in cost reduction isn't how well you negotiate contracts, but how well you master the cloud to reduce costs. Develop that deep expertise, and if you have a primary cloud, people can lean into it and figure out how to get to that spot. Because with multicloud, you're going to pay multiple times: multiple landing zones, multiple security systems. Your teams are likely to become less efficient at what they do, unable to reduce costs, and that expertise is going to be diluted.
Even if you believe in competitive pricing, your overall cost is likely to be significantly higher. And even if you get a better contract with competitive pricing, in every case I've seen, the net overall cost is higher because of all the other complexity, duplication, all these challenges. So, traditional procurement isn't working for us. The real savings come from mastering and understanding your cloud. Hackett Group found that when using a single cloud, infrastructure costs were 20% lower than multicloud. Just how each individual cloud organically works, not totaling up everything else. Primary clouds were 20% less.
And AWS is driving continuous cost reduction. The best indicator of future performance is past performance. We've lowered prices over 130 times. And we will continue to do so.
Our third insight, this is where we often see people who've started to pursue multicloud running into challenges. It's about having a clear strategy and the governance to support it. Again, simply deciding to do multicloud is not enough for most organizations. The complexity quickly overwhelms them. Unfortunately, once you open the door to multicloud, uncoordinated efforts lead to uncontrolled sprawl. As a leader, you wake up one morning and say, "Oh my gosh, why do I have all this stuff everywhere, and who signed this contract for this cloud?" It's chaos. Without clear governance, you'll struggle with visibility, security, and risk management. The key challenge is to maintain control as you implement this.
So how do you address these governance challenges? First, start with the why. Start with a clear strategy and governance model. Centralize multicloud management through a unified Cloud Center of Excellence. Here's what I mean by this. You might have a core team that sets up and builds your Cloud Center of Excellence, which is great. Have one for Provider 1. Build another one and have one for Provider 2. Don't fall into the trap of thinking one can manage both. If you're going to master it and drive down costs, you need to separate them. But you don't want them completely siloed, so make them part of the same organization. So you want to distribute a little, but you still need coordination. Standardize change management processes across all cloud environments. Implement a consistent tagging strategy for full visibility and ownership.
As you know, Rackspace is an AWS Premier Consulting Partner, and they faced the challenge of how to manage these diverse customer environments they have. They needed a single solution to patch and update servers and virtual machines across environments. But by implementing AWS Systems Manager, they created a unified approach that could manage all cloud environments, reducing time, cost, and risk.
Deutsche Börse operates a financial trading market with globally significant infrastructure needs. Previously, they monitored their on-premise data centers using traditional solutions. But as they expanded into multicloud, they realized logging wasn't working, monitoring wasn't working. By implementing AWS Config, they gained continuous monitoring capabilities and configuration and tracking across other clouds, on-premise, and within AWS. And now they can record the inventory and changes happening in their environment.
Principle 4: Avoid Distributing Contiguous Workloads and Understand Data Gravity
Now, let's talk about another critical mistake organizations make on their multicloud journey: don't distribute contiguous workloads across multiple clouds. Distributing connected cloud workloads creates risk and incurs costs. Spreading workloads across multiple clouds creates digital traffic jams. Splitting connected workloads creates unnecessary complexity. Teams find themselves juggling multiple APIs. This creates additional risk. And let's not forget the latency between cloud providers.
We just announced on Sunday that we now support Direct Connect from AWS to Google Cloud. This connects directly, not over the internet. You can expect this isn't the end of it. This helps. This is a good thing. So you can use this. You will be able to reduce latency. But here's my candid advice. You can avoid unnecessary latency and costs by keeping your workloads together. Applications should be individual and self-contained.
I talk to customers, and one customer told me, "I'm going to put my dev environment on this cloud and my production environment over here." And I thought, "Oh my gosh." Just because you can, like Jurassic Park, you're so preoccupied with whether you could that you didn't stop to think if you should. Now, you want to keep these contiguous workloads together, so keep your applications together. For instance, it might be a mobile ticketing app. Keep the entire mobile ticketing app in one cloud. Don't put some over here and some over there. Keep these together. This approach helps simplify what you're doing.
When you distribute workloads across multiple clouds, well, you know everything becomes more difficult. Debugging becomes harder.
Your security team is going to struggle, and your operational SLAs will face challenges. Ironically, this actual approach, which many people think is increasing resilience, is actually decreasing it. Think about it, I'll simplify the math, if one cloud provider has a 1 in 10 chance of failure, and another also has a 1 in 10 chance, if you put your workloads in both, you've actually increased your risk. Because either one of them can fail at any time. You have two opportunities for failure every time. You thought you were resilient, but no, it was counterproductive.
So let's move forward with these things in mind. It feels like you're doing the right thing, that's the worst part about it. So what are the guidelines for dealing with these workloads? Keep applications contiguous and self-contained. Structure each solution to function independently within its environment, and always question the business case when people say they want to distribute workloads. If cross-cloud communication is necessary, build it to be loosely coupled. This is something you know when building the architecture of your current system, but I've seen it time and time again when moving to multicloud, they become tightly coupled between the two. Make it message-based, make it loosely coupled.
Now, let's address a fundamental principle that is often underestimated. It might be becoming less so as we evolve, but it's data gravity. Applications have various things, and you need a long-term strategy for where they're going. Think of data gravity like physical gravity. Applications are naturally drawn to it. Ignoring this when architecting your multicloud solution is a significant challenge. My advice to people is don't separate your applications from your data. Sounds obvious, but as you scale, these costs will only increase, and your most demanding applications will be the first to feel this pain.
So let's talk about some more practical recommendations. Start by simplifying your approach to data and application placement. Minimize cost and bring your applications as close to your data sources as possible, or your data as close to your applications as possible. When considering distributing applications, weigh the benefits against the value. I always talk to organizations that say, I'm going to have my apps over here, and I'm going to build my data lake over there. Really? I mean, going back to one of my points, if you think you're getting business value by leveraging differentiation, as one of the legitimate reasons to do multicloud, I'm not here to tell you not to do it. But question people. Are you truly getting value out of it, or are you just doing it because you can? It's a natural segmentation: apps over here, data over there. It feels good, everything's neat and tidy, rows and columns. But what's the value behind it? So you have to challenge that.
Always start with a deep dive into that specific use case. Keep applications physically close, and if remote data is unavoidable, implement aggressive caching. Make your applications latency-aware, and again, that message, loosely coupled model. Once your architecture is in place, focus on continuous data governance across your multicloud environment. Be vigilant about this. Maintain consistent data policies across clouds, deploy smart lifecycle management, and recognize the increasing risk and cost.
Data Lakes, Containers, and Optimizing Organizational Structure
Okay, but wait, wait, wait, what about data lakes in a multicloud world? We just touched on that. The same principles apply. Place your primary data lake as close to the source as possible. What we're seeing more and more organizations do, instead of having one huge, big data lake, which again, as an engineer, feels right, is to build type 1, actually purpose-built data lakes. A data lake for a specific domain function, a data lake tied to a specific application that's deployed. So, do you really need to put HR data in the same data lake as your customer information? I mean, no, you would never combine those. Please, I hope you would never combine those. I mean, from a security perspective, in terms of separation of concerns, it's a good thing. There are other ways to ensure that, but why can't you just, you know, put your HR data closer to your Workday solution that you're running over here. Put your customer data over here. You want to reduce latency.
So you don't want to be moving those things around. Now, another thing I hear a lot is, well, just use containers. Containers are portable, they're interchangeable.
So you can just take your application, if you need to move it, you can take it out of this Kubernetes instance and throw it into that Kubernetes instance. But let's look at this a little more deeply. Where do containers help, and where do they actually add unnecessary complexity?
I think of containers like a Swiss Army knife. They're versatile, but they have their limits. Can you eat a steak dinner with it? Well, you can, but it's not going to solve all our challenges in multicloud. Sure, it improves portability capabilities, but data management is still difficult, as is maintaining consistent security policy monitoring. Again, we've only solved a small piece of the problem, and we've solved it by going to a lowest common denominator to actually make it portable. The specialized capabilities of each provider impact how well this can actually be done. This, unfortunately, becomes a false promise.
That being said, I think containers are a good strategy. Just not for multicloud. Deploy them thoughtfully where they add value. Again, remember to add value. Take the time to apply consistent policies and embrace the native tools of each cloud provider to manage your containers. You'll get better results that way.
Now, I touched on this a little earlier, it's about organizational strategy. In multicloud, finding that model, that organizational structure for multicloud, deserves careful decision-making. Again, having two divisions within a single Cloud Center of Excellence, one focused on one cloud and one focused on another. Cross-cutting concerns like security and operations have to be coordinated as you do this. You can't just set up one team and say go, and set up another team and say go. You have to coordinate this.
The reality of talent complicates this. Finding talent with experience across multiple clouds is like finding a left-handed, four-foot-tall pink unicorn. The left-handed part is the hardest part about the unicorn. You're not going to find that. You have to lean into people's expertise on this, and you have to allow them to master the cloud and drive down costs.
So let's talk again about practical considerations for organizing your organization for multicloud. Create a unified Cloud Center of Excellence, build cross-provider governance frameworks, align security and operations both with your business and your engineering teams, and hire people with deep single-cloud expertise for each Center of Excellence. Not a four-foot-tall left-handed pink unicorn. The problem with unicorns is they don't exist, and they're not left-handed. So looking for full-stack developers and multicloud developers, it's just not practical. You need to lean into the expertise you have.
The Complexity of Security and the Practice of the 80/20 Approach
Now, our last insight might seem obvious, but it can be underestimated in multicloud environments: it's security. Multicloud inherently increases security complexity. Each provider has different ways of implementing security, different ways of managing it, different handling, asset tracking, consistency, logging, auditing. As a result, transparency becomes more challenging in how you manage this.
Security realities demand a practical approach to multicloud. Let's start by acknowledging the truth. Multicloud doesn't make security easier; it makes it harder. I'm sorry. Implement automated security controls and create a single pane of glass visibility. We can help you with that with AWS tools. And establish consistent security policies across your organization.
Our data shows that most multicloud strategies fail. And often it's because there's a fundamental misunderstanding about how to try to run workloads in a multicloud environment. As I said earlier, the primary model, where you put 80% of your workloads on one and 20% on another, is how most companies actually running a multicloud strategy are doing it. Unfortunately, most companies start by trying to put 50% here and 50% there. Again, it feels right, but our research shows this rarely delivers benefits commensurate with the added cost.
Instead, an 80/20 approach ensures that you have the talent to master your primary cloud, reduce costs, eliminate risk, and get value from leveraging the higher-level services within your cloud. And you get more ownership from your team instead of them being spread thin.
This helps with retention. So, again, if you are adopting multicloud, choose one primary provider. Place 80% of your workloads there. This dramatically reduces the cost of training, tooling, and security management. It doesn't eliminate it entirely, but it significantly reduces it. Have a single Cloud Center of Excellence, but remember to specialize internally. And regularly evaluate your workload placement.
We talked about governance earlier. Put rules in place as to why some things are in one cloud and some things are in another. Don't let engineers freely choose. That will lead to sprawl, uncontrolled costs, and increased risk. Instead, put clear rules in place. We're going to use this cloud for these things. We're going to use this cloud for these things. Put those clear rules in place.
Practical Criteria for Multicloud Strategy and AWS Support
Our hypothesis for multicloud is this: a leader's job is essentially balancing priorities, right? You're tasked with reducing costs, risk, and complexity, but everybody wants to maintain availability and future flexibility. You need to accelerate innovation and create tangible business value, and multicloud decisions make this harder. So, let's be practical about when multicloud makes sense and when it doesn't.
Consider multicloud if you're looking at M&A, operating as a holding company, or truly pursuing unique capabilities in another provider. Handle specialized workloads or geographic expansion of workloads carefully, and as you tackle it, proceed thoughtfully and intentionally. Avoid multicloud if it's driven by the "everyone is doing it" mindset or theoretical lock-in concerns. Think carefully about pursuing it for cost leverage or unrealistic failover expectations.
At AWS, we're building a lot of solutions to support this multicloud capability. We're trying to simplify management across multiple clouds. Our tools help you maximize the performance of your AWS workloads, and our services have built-in connectivity to other clouds. Our goal is to help you connect, secure, and manage your workloads across all environments you need to run them where you need to run them. You can go to our website here, our multicloud website. It talks about additional capabilities, additional tools that we have. And I have a white paper there that I wrote. It's basically the same thing as this presentation, guiding you in a little more detail.
I hope that exploring cloud strategy has provided you with some clarity. We've identified some legitimate reasons why multicloud might make sense. Hopefully, we've debunked some myths where people make mistakes. And I've tried to share with you some battle-tested techniques to execute thoughtfully and intentionally when you need to pursue multicloud. I encourage you to apply these principles as you move forward with your cloud decisions.
Here's my contact information. If you'd like to continue this conversation with me or a member of my team, we're a free resource from AWS. How often do you hear that? It doesn't cost you anything to talk to me. I like talking to people, so feel free to reach out. I'd be happy to help. I want to thank you for your time. I'm going to spend a little time down here on the stage after we finish, so feel free to come up with any questions or follow-ups. Enjoy the rest of re:Invent. Thank you very much for your time.
- This article was automatically generated using Amazon Bedrock, while aiming to maintain the information of the original video as much as possible.
Discussion