AWS re:Invent 2025 - A leader's guide to navigating multicloud strategies and decisions (SNR204)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - A leader's guide to navigating multicloud strategies and decisions (SNR204)

In this video, Tom Godden, AWS Executive in Residence and former CIO at Foundation Medicine, presents nine tenets for multi-cloud strategy based on extensive customer experience. He clarifies that true multi-cloud means running critical workloads across multiple providers, not just using different SaaS products. Godden debunks common myths: that everyone's doing multi-cloud (71% actually standardize on single cloud per Bain research), that it avoids lock-in (abstraction layers fail), improves availability (increases operational risk), or reduces costs (Hackett Group found 20% higher infrastructure costs). He identifies legitimate multi-cloud scenarios including M&A acquisitions and independent business units, while recommending an 80/20 approach with one primary provider. Key guidance includes keeping contiguous workloads together, respecting data gravity, maintaining separate Cloud Centers of Excellence per provider, and establishing clear governance to prevent sprawl. Godden emphasizes that multi-cloud should solve specific business problems, not follow trends, and that mastering one cloud delivers more value than spreading expertise thin.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: AWS Executive in Residence on Multi-Cloud Strategy

My name is Tom Godden. I'm an Executive in Residence at AWS. Our Executive in Residence team is made up of 15 former Chief Information Officers, 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. Foundation Medicine is the world's largest genomics company. I spend a lot of time with customers helping them through their digital transformation, cloud transformation, AI, and data initiatives.

One of the topics I spend a lot of time talking with customers about, even more so now, is multi-cloud and how we navigate some of these strategies and decisions that are impacting us. Multi-cloud represents a pivotal decision. It will shape your entire technology strategy potentially. It's one of those critical choices as leaders that you need to make.

In my role, I've seen numerous multi-cloud discussions, and they're filled with confusion, contradictions, assumptions, and often this mix of false certainty but also a lot of hesitation. You're probably being bombarded with competing messages about do multi-cloud, don't do multi-cloud, kind of do multi-cloud. It's challenging as a leader. The freedom to innovate isn't just a slogan. It's our fundamental promise to you.

We believe your cloud provider should enhance your choices and not limit them. That's why our commitment to interoperability has become key to our strategies and a lot of reasons why people pick AWS over our competitors. That's our commitment to being interoperable across the clouds. We've built a comprehensive tooling suite that helps you build, migrate, operate, and manage these workloads. These multi-cloud capabilities are not add-ons. They're fundamental capabilities.

But we still have this question. I'm glad AWS has some tools. That's good. But here's the question on everyone's mind: is multi-cloud right for me? We're going to explore that a little bit, and the answer is it depends. What works perfectly for one organization won't work perfectly for another, but trust me, we'll get below that, and I'll give you a little bit more detail on that. It's not as simple, unfortunately, as it seems. There's more to it than meets the eye.

When is multi-cloud the right strategy for your organization? Having worked with thousands of enterprises, we've seen most get better results when they operate with one primary provider. But there are legitimate reasons why some companies find themselves moving into multi-cloud environments. Let's explore those scenarios because I think it's a reality that we're all dealing with. It's easy to stand up here and say you'd be better off with one, but the reality that you're all living in probably isn't that reality.

Before we dive deeper, I want to spend just a second clarifying what we mean by multi-cloud because I clarify this all the time. It's not using different SaaS products, email solutions, CRM solutions, and other clouds. That's not multi-cloud. True multi-cloud means actively using at least two cloud service providers for meaningful IT operations. We're talking about running critical workloads across different providers in a substantial way.

Now I'd like to share with you nine tenets that I've learned and developed in working with lots of customers on their multi-cloud journey. They come from continuous conversations on this topic. We've watched organizations struggle and succeed with multi-cloud across many industries, and these best practices I'm going to take you through have emerged through these real-world conversations we've had.

First Tenet: Multi-Cloud Should Not Be a Solution Looking for a Problem

Let's start with our first big insight about multi-cloud. It shouldn't be a solution looking for a problem. Multi-cloud brings complexity. There's no doubt about it. So you need a legitimate business need driving this decision, and I've seen too many organizations pursue multi-cloud without a clear why. The real question isn't should we do multi-cloud, but what business problem are we trying to solve?

Let's examine where multi-cloud adds value. You might find yourself in a multi-cloud world if you were operating as a primary cloud and you buy another company and they're on another cloud. Welcome to multi-cloud. Now, maybe you're luckier than I was in my 20 some years as an executive.

Never once was I allowed to rewrite the technology of a company that we bought. I had a perfect strategy. It was all neat and tidy and all running, and then we bought a company and screwed the whole thing up. You know what comes next isn't easy. My engineering instinct wants to consolidate that less is more, but actually rushing to consolidate may actually slow you down and delay value.

But you need to understand going into a merger or acquisition how you're going to operate in this new world. So a couple of things as you're planning your roadmap: Think beyond just the technical aspects of migration. The business impact should be driving your decision. Try to align your cloud consolidation strategy around your broader M&A strategy. Don't rush to decide where everything should live. Take time developing thoughtful placement criteria. We'll come back to that. Keep business momentum going throughout the process. Your customers still depend on you.

Another one that I see is there's a desire to leverage more capabilities across different cloud providers. We think this cloud provider has this good capability and this one has this. They have this vision that I'm going to create some Frankenstein's monster version of all the best pieces of all of them. Who would argue? Sounds great. It's tempting to pick the best cloud for each job, just like we're at a buffet. But again, each new provider adds complexity, operations, governance challenges, and problems across your entire organization.

If you're managing multiple independent business lines, well, maybe this is another way that you wind up in multicloud. You have a large company where this division is running on one cloud and this division is running on another. Largely, this bypasses a lot of the challenges of multicloud. You're still going to have some challenges, but largely you can let this business unit become an expert on one and you can let this business unit become an expert on another. You're not sharing resources, you're not sharing assets. They're operating basically as independent companies and part of a larger holding company. You're multicloud, fine. What you're going to miss out on is your ability to negotiate better deals on it because you've spread your workload across clouds, but you're largely going to bypass that, so that's a good reason.

But when leveraging those different capabilities, be strategic. Take time to understand each provider's volume discount structures and plan those purchasing commitments with care. Balance that interdependence that you see and always, always, always, always focus on the business objectives first.

We need to let the business decision drive our cloud strategy, not the latest tech trends, not the latest news from some pundit, not from some witty, pithy LinkedIn comment from someone who's talking about what should be done. Think about what really matters to your business: speed to market, cost predictability. What's your talent going to do? And Bezos has a great quote: the only thing your competitors can't match, it's only one thing, you being first. Everything else can be replicated. Don't care about your patent protection. I mean, I do, but it's going to expire, or you're going to go to China and realize it doesn't work. The only thing is to go fast, and so we need to look at this multicloud and actually ask ourselves, is it helping us go faster?

You see, this workload placement impacts everyone from finance to security to operations, not just your IT team. We've seen time and time again when that focus expertise on one platform occurs, companies get more value. And when we spread it across clouds, we delay value, we add complexity. So be crystal clear about why you're pursuing multicloud. Don't assume everyone understands the rationale.

My CIO, I'd walk through the halls, you'd meet the new quality assurance person. Hello, my name's Tom. Chat with them a little bit in the hall, give them a little bit of time with the executive. Good. But at the end of it, I always ask them, what are our top three priorities, but why? And if they didn't know what the why was, I mean, I wasn't happy with them, but what I did is I went to their boss, even if it was layers down in my organization. Because if we all do not understand the why, they can't help you with the trade-offs as you're trying to implement your multicloud strategy.

They don't know, should I do this or this? I thought we were doing multi-cloud for this reason. Is what I'm doing contributing to that? And so what do they do? Well, either they make bad decisions or they grind to a halt because they wait for what we call the HIPPO to weigh in. Now, I'm not talking about a hippopotamus here. HIPPO stands for the highest paid person's opinion. Most of the time, they don't know what they're doing. They're too far from the problem. I've been there. I've been the executive. You're too far from it. So we need our people to be empowered so that they can take action on that, document your reasoning on this, follow up on it, obsess on it.

Debunking Common Multi-Cloud Myths: Adoption, Lock-In, Availability, and Pricing

So we talked about key considerations for why you might push into multi-cloud, but let's examine a second insight: common myths to be cautious about. Many assumptions about multi-cloud feel good, but they don't hold up to scrutiny. So first misconception: everyone's doing multi-cloud. Is this really true? Headlines suggest that we have widespread adoption. Everyone's doing it. For years, advisory firms claim most global 1000 companies are pursuing multi-cloud strategies. Pursuing multi-cloud strategies, not successfully running workloads delivering value in a multi-cloud environment.

Flexera had a report in 2023 that suggested that 87% of companies have a multi-cloud strategy. Yet Bain did research and said 71% of companies have still standardized on a single cloud, with the remaining 29% spending 95% with one provider. In other words, overwhelmingly people are still in that primary cloud model. We need to not be drawn in by this. Again, be drawn by business value.

The first thing to know, despite what those glossy reports and those pithy LinkedIn posts say, and by the way, I write pithy LinkedIn posts, so you can follow me and find out what I'm doing, but be really clear about why we're considering it. Make decisions on your business needs. Your organizational requirements matter more than any industry analysts, and look at your spending patterns. Understand that many companies that say they're multi-cloud are actually primary cloud, so don't get caught up in it.

The second misconception: multi-cloud helps avoid lock-in. But is this more of a legacy type of IT thinking? I mean, I'll be honest, none of us want to be locked in. We all want options. But is it practical? What problem are we solving by doing that? Many companies cite fear of lock-in as their primary reason for pursuing multi-cloud. They want that optionality, that control over their technology choices, and some worry that, well, what if the cloud provider focus shifts and they start doing something different? Others simply don't want their entire digital foundation dependent on a single provider.

But remember, every technology choice creates some form of lock-in. As leaders, it's about you understanding how to manage what those trade-offs are. A simple model might be able to help us move beyond that reflexive instinct. First, we need to accept that we all live with lock-in in many aspects of our business and technological and personal lives. We may be happy to accept lock-in when we get enough value in return. This creates a decision matrix that we can use to look at these four scenarios objectively. We're trying to look at them objectively.

So as we look at this, lock-in equals bad is a mindset that many of us have, but we need to accept this lock-in. And if we look at this, you might go, okay, down in the bottom is some disposable technology. It's our cables that we have for our phones and our devices. Although the European Union is pushing us to standardize, changing those things is easy. And as you go across that uniqueness, you might go, well, I have a presence on Twitter. I'm getting value on that. Could I switch to Instagram? Yeah, you can switch. You're not locked in. And if I look at the switching costs and I go, well, maybe my cell phone service is on one provider and I want to switch to another, I'm not going to get a lot of uniqueness by switching. I mean, they're all kind of more or less the same, not that hard.

But when I look at this and I think about something like your mobile phone, iOS or Android, you could potentially get a lot of value in switching. You're also locked in. You probably couldn't get me off my phone with dynamite, and the reason why is not because I love it, but because I'm in the ecosystem. My children communicate with me on it. I call them and FaceTime and do all these things on it. So I've accepted that lock-in. Why did I accept that lock-in? Well, because I get value. So we need to be looking at whether we're getting the commensurate value as we look at this lock-in.

The other thing that we see here is abstraction layers. People talk to me and say they've worked with these companies and they're going to build an abstraction layer. So they're going to have a cloud, they're going to put an abstraction layer over the whole thing, and people will communicate with the abstraction layer. Sounds like a great way to spend millions of dollars and get fired. I've never seen it work, not once. If you have, find me afterwards and tell me how you did it.

The problem is many of those critical components that we depend on can't be abstracted away through an abstraction layer. Provisioning, cost control, security, most databases, monitoring, event management—they all work differently. These abstraction layers might solve 15% of your problem for an enormous cost, and remember time, because now I'm going to spend all this time building the abstraction layer. And by the way, AWS just released a whole bunch of stuff today, so feel free to go back and update your abstraction layer because there's new stuff, and I'm not even going to mention the other cloud providers when they change theirs.

It sounds like a good idea, but don't let your architects convince you to do it. It adds significant cost, complexity, and risk to your overall technology decision. Multi-cloud does not help avoid lock-in. It creates a different kind of complexity and constraints. Multi-cloud interoperability is crucial, and we need to plan and understand it. We need to define and plan for a pragmatic strategy to reduce lock-in.

So I'm not saying ignore it. Take your primary cloud provider and dissect it. What am I using? Why am I using it? How am I using it? Go through a tabletop exercise with your leadership team on what it would take to migrate away from the provider. It's a good exercise, a good risk exercise for you to understand. It also pleases the regulators. Assess those features that you're truly dependent on and formulate whether there's a mitigation strategy, whether there's a migration strategy, non-abstraction layer.

And leverage the value of the cloud, because the value of the cloud is not just that it's a data center running somewhere else. It's great provision, scale up, scale down, elasticity. The real value comes from those cloud native features, those capabilities that are unique to each provider, where you're going to get a higher level value service that goes beyond just provisioning that base compute instance. And we can't abstract those away.

The third misconception I see is that multi-cloud improves availability. This is a common belief. Many assume that they can seamlessly switch workloads. Sounds like such a great idea. I have one on this cloud provider, one on this cloud provider. I'll replicate all the data back and forth between the two, and if one of them has a hiccup, I'll fail over to the other. Don't let your engineers convince you they're right.

You are far more likely to create your own availability problem trying to keep these two instances in sync and available and up and running. I see it time and time again. In the early days, multi-cloud customers often said they think they can do this to reduce their disruption. The assumption was if one cloud went down, it sounds like a good idea. Lydia Leon, a Gartner analyst, said multi-cloud failover is complex and costly to the point of being impractical. Preparing for this unlikely scenario often creates operational risk on a daily basis.

Think about it. You're trading the potential possibility that something could happen. Now, remember, Werner Vogels will tell you everything always fails, so I can't promise you that it won't ever fail. But you're trading off that potential possibility that it could fail for increased operational risk today, and then tomorrow, and then the day after that.

We've added this complexity because we think that we've abstracted it away. Here's an important truth: it increases that risk. It forces customers often when they try to build these things into a lowest common denominator because they're trying to have the abstraction layer and can't use those higher level services. Instead, you're better off to use a multi-region strategy if that's what you truly need, again driven by your business needs. If a single region with an availability zone isn't enough, go to a multi-region approach. Put 50% of the workload on one region, 50% of the workload on the other, and if one fails, go over to the other. But use the AWS infrastructure to do it and you'll be far more resilient. If we look back at the challenges and problems with some of the things that have happened within AWS, they've been isolated to a single region. A multi-region strategy would move you past that.

So let's talk about a hard truth. The other problem is multi-cloud requires multiples of everything. Cloud-specific landing zones must be built. Visibility becomes challenging. Multi-cloud leads to duplication of data. With primary cloud, you can benefit from the native services and the integration and the immediate access provided by that platform. Because again, multi-cloud adds significant complexity across your organization. Security teams struggle with that fragmented data discovery. Good luck complying with the GDPR right to be forgotten. Where's that person's data stored? There are seven of them there, I think they might be over there. Other than that, it's a great strategy.

The teams must master those multiple security types of challenges, and candidly, resiliency capabilities vary greatly 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 globe. Target a specific workload, migrate it, master it, optimize it, drive cost and risk out, lather, rinse, repeat. We can talk more afterwards if you want. We can talk about a chaos monkey strategy and how you test your organization for high availability to make sure that that multi-region type of model will really get you the resilience you want.

But let's move to misconception four: multi-cloud gives you pricing strategy. Don't let your procurement people take you here. This is old school thinking. I had old school thinking procurement people. Sounds like a great idea, let's compete. The goal is to have vendors compete to drive the pricing down. This approach doesn't always work. Most of these agreements lock companies into multi-year contracts with limited flexibility, but cloud has fundamentally changed this model into a volume type of dynamic.

So let's talk briefly about cost optimization in cloud. With a primary provider, you pay once for all the capabilities instead of duplicating the costs. And the biggest driver in cost reduction is not how well you negotiate your contract, but it's how well you master your cloud and drive costs out. Develop that deep expertise, and when we have a primary cloud, people can work on that and understand how to get to that point. Because with multi-cloud, you pay for things multiple times: multiple landing zones, multiple security systems. Your teams are likely to be less efficient in what they're doing and not driving those costs down, and that expertise becomes diluted.

Your overall costs are likely to be significantly higher despite your belief of competitive pricing. And even if you can get the competitive pricing to give you a better contract, your net overall costs in every case I've seen are going to be higher because of all of the other complexities, because of the duplication, because of all of these challenges. So traditional procurement is not going to work for us. The real savings comes from mastering and understanding that cloud. Hackett Group found that 20% lower infrastructure costs occurred when you had a single cloud than multi-cloud, not adding up all the other things, just how each individual cloud organically operated. Primary cloud was 20% less.

And AWS is driving continuous cost reductions. The best indicator of future performance is past performance. We've reduced our prices over 130 times. We'll continue to do so.

Establishing Clear Strategy and Governance for Multi-Cloud Environments

Our third insight, well, this is one where I see people when they start to pursue multicloud have some challenges. Have a clear strategy and the governance to support it. Deciding to do multicloud again is not enough for most organizations. That complexity quickly overwhelms them. Unfortunately, when you open up the gates to multicloud, that uncoordinated work leads to sprawl. As a leader, you wake up one morning and go, oh my God, why do we have stuff here, here, here, and here, and who signed an agreement for that cloud? It's chaos. Without that clear governance, you're going to struggle for visibility, for security, for risk management. The key challenge is to maintain control as you do this.

So how do you address some of these governance challenges? Well, again, start with why. Start with a clear strategy and governance model. Centralize your multicloud management through a unified Cloud Center of Excellence. Here's what I mean. You might have a Cloud Center of Excellence, your core team that's setting up and building your cloud. Great. Have one on provider one. Build another, have it on provider two. Do not fall in the trap of thinking that one can manage both. If you're going to master it and drive the costs out, you need to have them separate. But they're part of the same organization because I don't want to be completely split-brain. So although I want to diversify it a little bit, I still want to coordinate. Standardize the change management process across all cloud environments. Implement a cohesive tagging strategy for complete visibility and ownership.

You know, Rackspace is an AWS Premier Consulting Partner, and they faced the challenge of how do they manage all these diverse customer environments that they have. They needed a single solution to patch and update servers and virtual machines across their environments. But by implementing AWS Systems Manager, they created a unified approach that was able to manage across all of their cloud environments, reducing their time, their cost, and their risk.

Deutsche Börse operates a financial trading market with worldwide critical infrastructure needs. Previously, they monitored their on-premise data centers using traditional solutions. But as they expanded to multicloud, they realized their logging couldn't work, their monitoring couldn't work. By implementing AWS Config, they gained continuous monitoring capabilities and configuration and tracking capabilities across other clouds, on-premise, and within AWS. And now they can record the inventory, the changes that are happening in their environment.

Keep Contiguous Workloads Together to Avoid Unnecessary Complexity

So let's talk about another critical mistake that organizations make on their multicloud journey. Don't spread your contiguous workloads across clouds. Distributing connected cloud workloads creates risk, creates cost. When you spread it across multiple clouds, you create a digital traffic jam. Splitting connected workloads creates unnecessary complexity. Your teams are juggling multiple APIs. This puts added risk into it. And don't forget the latency between cloud providers now.

We just announced Sunday that we now support a Direct Connect to Google, to the Google Cloud from AWS that goes direct without going out through the internet. I think you can expect that we're not done. So that'll help. That's good. So you can use that. That'll cut down on latency. But here's my straightforward advice. Keep workloads together so you can avoid that unnecessary latency and cost. Applications should be discrete and self-contained.

I talked to customers. One customer I was working with was like, our development environment's going to be on this cloud, and our production environment's going to be on this one. I'm like, oh my God. Just because you can, what is the Jurassic Park, you know, you're so excited trying to figure out if you could do it, you didn't ask if you should. Now, we want to keep these contiguous workloads together, so keep an application together. Maybe it's your mobile ticketing app. Put the whole mobile ticketing app on one cloud. Don't put part of it over here and part of it over there. Keep them together on this. This approach will help you and simplify what you're doing.

When you spread workloads across clouds, well, we know everything becomes harder. Debugging becomes more challenging.

Your security team will struggle, and your operational SLAs will be challenged. The irony is that this actual approach, where lots of people think they're increasing resilience, is actually reducing it. If you think about it, and I'm going to keep the math simple, if one cloud provider had a 1 out of 10 chance of failing and the other had a 1 out of 10 chance of failing, and I put my workload on both, I actually have increased my risk because either one of them could fail at any point in time. I have two failure opportunities at every single time I do it. I thought I was resilient, but nope, I went backwards.

So think about these things as we do it. It feels like the right thing, and that's the worst part. So what are our guidelines for handling these workloads? Keep your applications contiguous and self-contained. Structure each solution to function independently in its environment and always question the business case for when people want to distribute the workloads. If cross-cloud communication becomes necessary, build it so it is loosely coupled. We know this from building our architecture for our current systems, but so many times when I see people go multicloud, they become tightly coupled between the two. Make it message-based, make it loosely coupled.

Understanding Data Gravity and Application Placement in Multi-Cloud

Now, let's address a fundamental principle that's often underestimated, maybe less so as we evolve: data gravity. Applications can have lots of different things, and we need to have this long-term strategy on where we're going to go. Think of data gravity like physical gravity, where applications are naturally pulled together. When architecting multicloud solutions, ignoring this is a big challenge. What I advise people to do is don't separate your application from your data. It sounds obvious, but as you scale, these costs will only increase and your most demanding applications will feel this pain first.

So a few more practical recommendations. Start by simplifying your approach to data and application placement. Minimize costs and keep your applications as close to the data sources as possible, or keep your data as close to your applications as possible. When you're considering distributing applications, weigh the benefits against the value. I talk to organizations all the time that have their applications over here and want to build a data lake over there. Really? I mean, going back to one of my points, one of the good reasons for doing multicloud, if you think you're going to get business value by leveraging differentiation, who would I be to tell you not to do it? But ask your people, are we really getting value on that or are we just doing it because we can? It's a natural delineation: apps there, data there. Feels good, everything's nice and tidy, rows and columns. But what's the value behind that? So we've got to challenge that.

Always begin with a deep dive into that specific use case. Keep the applications physically close, and when remote data can't be avoided, implement aggressive caching on it. Make applications latency aware and again that message, that loosely coupled type of model. Once your architecture is in place, focus on ongoing data control across your multicloud environment. Stay vigilant on this. Maintain consistent data policies across clouds, deploy that smart lifecycle management, and be aware of our increased risk and cost.

Now, but wait, wait, wait, remember what about data lakes in a multicloud world? I talked briefly about it. The same principles apply. Place your primary data lakes as close as possible to the source. What we're seeing more and more companies do is instead of having one gigantic large data lake, which again, as an engineer, it feels right, type one, we're actually seeing purpose-built data lakes. Data lakes for specific domain functions, data lakes tied to specific applications where they're deployed. I mean, do you really need your HR data in the same data lake that you have your customer information in? I mean, no, you're never going to combine them. God, I hope you're never going to combine them. So it's also good from a separation of concerns from a security standpoint. There are other ways to make sure you do it, but why not just, you know, I can put the HR data closer to that Workday solution that I have running over here. I put the customer data more towards over here. I want to reduce that latency.

Containers and Organizational Structure: Finding the Right Multi-Cloud Model

We don't want to be moving that stuff around. Now, here's another one I get. I'll just use containers. Containers are portable, fungible.

So I'll take my applications and if I need to move them, I'll pick them up from this Kubernetes instance and I'll chuck them over here to another Kubernetes instance. But let's explore this a little bit more. Where do containers help and where do they actually add some unnecessary complexity?

I like to think of containers as a Swiss Army knife, versatile but with limitations. Could you eat your steak dinner with it? Well, you could, but they don't solve every challenge we have with multi-cloud. Yes, they'll introduce an increased ability for portability, but data management remains difficult, as does maintaining consistent security policy monitoring. Again, we've solved for a small portion of the problem, and we've also solved it by going to the lowest common denominator so it's actually portable. Each provider's specialized features will affect how well you can do this. This becomes, unfortunately, a false promise.

With that said, I still think containers are a good strategy, but not for multi-cloud. Deploy them thoughtfully where they add value. Again, remember, add value. Take time and apply those consistent policies, but embrace each cloud provider's native tools for managing containers. You'll be better off if you do that.

Now we talked briefly about this one before, talking about organizational strategy. For multi-cloud, find that model, that organizational structure for multi-cloud that deserves careful decision. Again, single Cloud Center of Excellence with two departments, one focused on one cloud, one focused on another. Cross-cutting concerns like security and operations have to be coordinated as we do this. I can't just set one team up and tell them to go, set the other up and tell them to go. I need to coordinate this.

Talent realities are going to complicate this. Finding people with experience across multiple clouds is like finding a left-handed four-foot-tall pink unicorn. The left-handed part is the hardest part with the unicorn. You're not going to find them. We need to lean into people's expertise on this and allow them again to master the cloud and drive the cost out.

So again, when organizing for multi-cloud, here are some practical considerations. Unified Cloud Center of Excellence, create those cross-provider governance frameworks, and represent security and operations in both business and engineering teams for alignment, and hire deep single-cloud expertise in each of your centers of excellence. Not four-foot-tall left-handed pink unicorns. You know, the problem with the unicorns, they don't exist and they're not left-handed. Hunting for those full-stack developers, those multi-cloud developers, it just isn't realistic. We need to lean into the expertise needed.

Security Challenges and the 80/20 Primary Cloud Approach

Now our final insight might seem obvious, and well, it might be underestimated in our multi-cloud environments: security. Multi-cloud inherently increases security complexity. Each provider has different ways of doing security, managing things, doing different things, asset tracking, consistency, logging, auditing. As a result, the transparency becomes more challenging in how we manage this.

The security reality demands a pragmatic approach to multi-cloud. Start by acknowledging the truth. Multi-cloud makes security harder, not easier. I'm sorry. Implement automated security controls, create that single pane of visibility. We can help you with that with the AWS tools. And establish consistent security policies across your organization.

Our data shows that most multi-cloud strategies fail, often because we have a fundamental misunderstanding and how we try to run our workloads in a multi-cloud environment. As I said before, that primary model where I have 80% of my workloads on one and 20% on the other is where most companies that are actually executing a multi-cloud strategy are working. Unfortunately, most companies set out to say I'm going to put 50% here and 50% there. Again, it feels right, but our research shows that this rarely delivers the benefits for the added cost.

Instead, the 80/20 approach allows us to have people who can master that primary cloud, drive the cost, drive the risk out, leverage the higher degree services inside the cloud so they can get value, and it allows your teams to have more ownership instead of being spread so thin.

This will help improve your retention. So as we talk about this again, select one primary provider if you're going to be multi-cloud. Put 80% of your workloads there. This will dramatically reduce your costs in training, tooling, and security management. It won't eliminate them, but it will significantly reduce them. Have that single Cloud Center of Excellence, remember, but specialized within. And regularly evaluate workload placement.

We talked about governance earlier. Have rules for why some things are going in one cloud and some things in another. Don't let your engineers just pick, or you're going to get sprawl, you're going to lose cost control, and you're going to increase risk. No, have clear rules. We're using this cloud for these things. We're using this cloud for these things. Have those clear rules.

Final Recommendations: When Multi-Cloud Makes Sense and AWS Support

Our hypothesis around multi-cloud comes down to this. A leader's job is fundamentally balancing priorities, right? You're all tasked with reducing cost, risk, and complexity, but everyone wants you to maintain availability and future flexibility. You need to accelerate innovation and create all that tangible business value, but multi-cloud decisions make this more challenging. So let's be practical about when multi-cloud makes sense and when it doesn't.

Consider multi-cloud when you're looking at M&A, when you're operating in a holding company, or when you're pursuing truly unique capabilities in another provider. Be cautious with specialized workloads or geographic expansion of your workloads, and proceed thoughtfully and deliberately as you approach that. Avoid multi-cloud when it's driven by the "everyone's doing it" mentality, the theoretical lock-in concerns. Think twice about pursuing it for that cost leverage or that unrealistic expectation of failover.

At AWS, we're building a lot of solutions to support this multi-cloud capability. We're trying to simplify the management across multiple clouds. Our tools will help maximize performance of your AWS workloads, and our services have built-in connections to other clouds. Our goal is to help you connect, secure, and manage workloads across environments wherever you need them to run. You can visit our website here, our multi-cloud website. We'll give you additional features, additional tooling that we have. There's also a white paper up there that I wrote that's basically the same as this presentation that will guide you through this in a little bit more detail.

I hope our exploration of cloud strategy has provided you some clarity. We've identified a few valid reasons why multi-cloud might make sense. Hopefully, we've debunked a few myths on where people make some mistakes. We tried to share with you a couple of techniques, battle tested, if you need to pursue multi-cloud on how to do it thoughtfully and deliberately so that you're able to do it. I encourage you to apply these tenets as you navigate your cloud decisions.

This is my contact information. If you want to continue this conversation with myself or a member of my team, we're a free resource from AWS. So how often do you hear that? It doesn't cost anything to talk to me. I like to talk to people, so feel free to reach out. I'm happy to help. I'd like to thank all of you for your time. I'll spend a little bit of time here today off the stage when we get done if any of you have any questions or follow-ups. Please enjoy the rest of re:Invent. Thank you very much for your time.

---

; This article is entirely auto-generated using Amazon Bedrock.