🦄 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 - Navigate multicloud with AWS: Essential foundations for success (HMC101)
In this video, Ellie and Shankar from the AWS multi-cloud program present foundational guidance for operating in multi-cloud environments. They introduce the AWS Multicloud Readiness Framework and discuss three deployment models: discrete, integrated, and flexible. Key topics include understanding customer motivations (flexibility, M&A, regulatory requirements), defining clear business cases before adoption, and implementing best practices across enterprise strategy, foundations (security, networking, FinOps, observability), architecture, and data/AI layers. They emphasize that adding another cloud doesn't automatically solve challenges like lock-in or resilience without proper architectural planning. The session covers AWS capabilities including the multi-cloud FinOps dashboard with FOCUS specification, CNOE for internal developer portals, and tools for Kubernetes fleet management. They stress the importance of cloud-agnostic architectural principles, unified observability, consistent security policies, and democratizing data/AI usage while maintaining proper guardrails and data lineage tracking.
; 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 to AWS Multi-Cloud Program and Session Overview
Hi everyone. Welcome to HMC101. Our assumption for this session is that you're operating in a multi-cloud environment or planning to do so. Can you raise your hand if that's the case? Alright, if your hand is down, this would be a good time to leave. You're still sitting, good. I'm Ellie, and this is Shankar. I lead the AWS multi-cloud program, which means we provide cloud agnostic support to customers operating in a multi-cloud environment. This includes thought leadership, strategic consulting, and best practices. Agnostic means that we might not even recommend specific services to one cloud or another; we may recommend them all.
We're going to take you through our session today and have fun. We're here to provide cloud agnostic guidance, right? So architectural patterns and services and the way you would string them together, what kind of patterns you should look for. Here's what we have in store for you. First, this is a foundational session. So if you have a lot of experience running a multi-cloud environment, you may be aware of these topics. You may learn things you don't already know, but just to level set, this is our foundational strategic guidance.
Now, as far as what we'll cover today, we're going to start with what we hear from customers—voice of customer feedback we've gotten. We'll introduce the AWS Multicloud Readiness Framework, which is one of the ways we guide customers to prepare for having a multi-cloud environment. We'll then go through some of our best practices, what we share with customers that come to our program to get information. We'll make sure to end with some key takeaways for you to know, including some other sessions we recommend for you to join this week.
As I said, my name is Ellie and I lead the business side of the multi-cloud program at AWS. We have over 150 specialists that have mastered these topics. They either have certifications from other clouds or they have experience deploying AWS services on other clouds, so they can provide that guidance. Think about this as a consultative experience. We work with our customers long term. It's not a one-time thing. Whatever it is that you need, we're happy to provide and bring the right experts to support you.
Customer Voices: Motivations and Use Cases for Multi-Cloud Adoption
I'm Shankar. I lead the technical practice area in AWS, and I'd like to start by telling you what we're hearing from our customers. We talk to a lot of multi-cloud customers and we capture a few themes. I want to highlight a few of those themes that are worth bringing up to you. First is flexibility. Most customers—this is from a global telecom company—tell us that they adopt multi-cloud strategies because they're looking for the flexibility that adopting multi-cloud strategies gives them. In this case, they're adopting three clouds.
The second quote comes from a large enterprise. This is also an ISV. They're further along in their multi-cloud journey. What I want to highlight here is the fact that they have standardized on some enterprise level principles. They're standardizing on the architecture principle of adopting open source, which is a very common theme we've seen with many large customers on this multi-cloud journey.
The third quote is from a consumer genomics company, and it highlights how we're seeing Gen AI and multi-cloud adoption go hand in hand. In this case, this customer really wants to adopt what we call best of breed AI services. They just want to be able to innovate and adopt AI services across different cloud providers or partners. Where it comes from is not of any concern to them. So there is this trend of how Gen AI is fueling customers' multi-cloud strategies.
We also see that there are a few motivations. There are some pan-global teams that we see.
If you're an Independent Service Provider (ISV), you're probably going to look for a multi-cloud strategy because you want to serve your customers where they are. You might be in a mergers and acquisitions scenario, which is very common. Let me do a quick poll here in this room. Did anyone come to the multi-cloud space through an M&A? Show of hands. Okay, some of you did. We also see some geo-wide trends. This is not to say that this is just happening in one particular geography, but this is what we see more predominantly. For example, in North America we see customer contracts often drive multi-cloud strategy. In Europe, we often see regulatory requirements dictate the customer's multi-cloud strategy. In Asia, we see that topics such as resilience are guiding customers' motivations towards looking at multi-cloud.
These are some of the trends we're observing. Are you seeing something else too? Well, in a lot of cases we see customers mention several motivations. We want to avoid lock-in and we also want to take advantage of differentiating capabilities. We might end up with a regulatory requirement, so it could be a few different factors. There are definitely cases where we hear that companies are multi-cloud because of executive guidance. It could be that a company had a change of executive leadership and an executive came in with experience from another cloud provider and they want to push that direction. But the most important thing for us to remember is that some of these use cases aren't solved by just adding another cloud.
If you want to avoid lock-in, just adding another cloud isn't going to get you there. We talk about architecting for portability. If you're talking about resilience as a use case, that's very nuanced because adding another cloud doesn't make you more resilient. It actually could make you less resilient. So we help customers think about situations where adding another cloud can help you reach that use case. One of the things we always ask our customers is: let's start with why. What was the reason you opted to operate in multi-cloud? What is that end use case we're hoping to get to? Because if we don't know where we're going, what the destination is, it's going to be very hard for us to pave the way to get there.
Defining Multi-Cloud Deployment Models: Discrete, Integrated, and Flexible
If we drill down onto why you're operating in a multi-cloud environment and what value you expect to get out of operating in a multi-cloud environment, it will help us guide you along that way and reach success. I think it will be super meaningful to define the term multi-cloud. I'm sure each one of you has your own definitions, but for the sake of this session and for the other multi-cloud sessions at re:Invent, we define multi-cloud as the use of multiple cloud providers for meaningful workloads. This means we are automatically excluding, for example, your use of some kind of SaaS solution that might be running in a cloud provider that's not your primary. That is not the use case we're talking about. While that might still be a valid multi-cloud use case, for the sake of this session we're talking about using two or more cloud providers to operate meaningful business workloads as a strategic business decision.
If somebody's just playing around and launching a workload on another cloud, that's different. As we listen in and observe, we've identified a few patterns. I have to say this is my most favorite slide. We see that there are a few distinct patterns. On the left you see customers adopting multi-cloud in what we call a discrete manner. You might have a workload in cloud provider A and another workload in cloud provider B. For all practical purposes, they're just sitting there in their clouds doing their own thing. They're not talking to each other. While you might have a portfolio of multiple clouds, they are just like ice creams in two different cones. The second category is what we call integrated, where you might have workloads in multiple clouds and some of them are actually interfacing with another. Maybe you have data here that is accessed over there in another workload with another cloud service provider. That's your middle sort of multiple scoops in a bowl.
Further along is what we call the flexible mode, where you're really trying to offer your builders an environment that is agnostic to the underlying cloud that will actually support that workload. You're taking off all of that undifferentiated heavy lifting and you're adopting the benefits of multiple clouds. When we ask customers what their goal is, we understand that this doesn't necessarily mean maturity; it just may mean a different business strategy. Some of our customers want to move towards flexible multi-cloud and they want to have abstraction, they want to have full control planes and observability, which we call a single pane of glass. We don't use that phrase anymore because it became confusing. It's never actually single, so we need to understand what is it that you're hoping to achieve. Are you looking for that combined integrated multi-cloud strategy or just operating multiple clouds with maybe one central control plane? You could have any kind of option you want, any flavor.
That brings us to the AWS Multicloud Readiness Framework, which is a structured way in which we would recommend customers go through their multi-cloud adoption. We've been working with a lot of customers over the years, building out this framework that touches upon different layers from enterprise strategy to architecture all the way to AI. As we walk through this presentation, you will see that we keep leaning in on this particular framework and we hinge our best practices and our guidance as well as our capabilities and services along this framework so that you can be ready as you go about multi-cloud adoption.
In practice, how does multi-cloud deployment actually look? We often use an airlines analogy for that. This is my favorite analogy for going multi-cloud. Let's assume you have one fleet of airplanes, and your life is easy. If you think about your people, they're all trained on this one fleet of airplanes. Your pilots all know how to fly all airplanes. Your staff knows how these airplanes work and they know where everything goes. It's very easy and we don't have to train them on other models of airplanes. Same with the process. If a customer makes a booking, the booking system is all the same. Even if I have to swap out airplanes, seats are the same and they can still sit where they booked. With technology, let's think about spare parts. If I only have one airplane model fleet, my warehouse will just have the spare parts that I need for that one model airplane.
But what happens if, like in mergers and acquisitions, I want to expand and I end up purchasing a different fleet? Now I have some thinking to do. What about my people? Are they all going to be trained on all the different models, or do I have specialization? What about my process? How do I have to change it now in order to support the fact that it might not always be the same exact airplane? With technology, we're now looking at complications. How do I actually change my tech stack to support the fact that I now have two different fleets? And then let's talk about the part where we're now adding a third fleet. Now things get even more complicated. Now I have different hubs. Are all the different planes going to be in all the hubs? Are they going to be just specific routes for special planes? What happens when they reach a different hub? What if I have to swap them out? This helps people that don't have IT experience or knowledge understand the complexity.
When we talk to executives, we sometimes have to go through explaining how adding all of these different clouds increases your complexity and it can increase your cost. So going back to where we started, we better have a use case because we want to measure that ROI. I've just added complexity, I've added cost, I've added work in order to manage this complex environment. I want to make sure I get my value out of it. Of course, everybody wants to get to the promised land, so to say.
You really want to get to the point where you are more efficient than you were when you were with a single fleet of gray airplanes, and you can get there. But you need clarity, as Ellie's been talking about, around what are the KPIs that you're going to measure yourself over. Have you actually thought through all of the people, process, and technology considerations? Eventually, we do see customers succeed and really organize their fleets in a meaningful way.
That's as far as the analogy goes, so let's come back to the cloud. We know more about the cloud than we do about managing airline fleets anyway. Just to summarize that part, we spoke about three distinct deployment models, and I want to emphasize this. These are discrete, distinct categories. You don't necessarily need to go from discrete to integrated and then to flexible. If your business needs propel you to go from discrete directly to flexible, then you would do so. You're perfectly fine establishing your baseline on discrete and staying there, or on integrated, or on flexible.
Enterprise Strategy Best Practices and the AWS Multicloud Readiness Framework
Now let's look at what are some best practices and AWS capabilities, and we're going to hinge this back on our readiness framework, all the way from enterprise strategy. We will start with the enterprise strategy layer and see what are some best practices that we would recommend you adopt toward multi-cloud readiness. I'm going to bring this back to the discrete, integrated, and flexible deployment models, and you're going to see the same sort of visual repeat.
At the discrete deployment model, we would recommend that you definitely rationalize your multi-cloud investment. Start with the why, because if you're not able to articulate in clear business case terms why you're doing what you're doing from a multi-cloud strategy perspective, then it's very difficult to make any sense of it, even if you are going further along in the integrated path.
As you go to an integrated model of deployment, here is where we would definitely recommend that you take a serious look at what is the skill set in your team. Are they really ready to operate effectively in a multi-cloud environment? How do you identify what the skills gap is and how are you going to address that? Also, eventually your success with multi-cloud strategy is going to reflect your overall organizational structure. You need to make sure that you think through how you're going to proactively and consciously design your team structures to be able to succeed with your multi-cloud strategy.
Eventually, to succeed in the flexible deployment, whatever strategy you've put in place, you want to make sure that you've defined it as a policy, better still an automated policy. You want to put all of this such that, let me take an example, what about workload placement? It is one thing to say that I'm adopting cloud A for this and cloud B for that, but you need to be able to programmatically govern that. You need to be able to influence your builders in a way such that either this decision is off their plates or they know exactly where a workload is supposed to go. You need to put your multi-cloud strategy as a policy and automate that.
Now let's look at some AWS capabilities that align with these best practices. At the discrete level, we've been talking about the readiness framework. We would highly recommend that you evaluate if this is the right kind of framework for your organization. It likely is. If not, it's based on an open standards-based, open alliance approach, so you can take this, make it your own, and create your own readiness framework out of this as a baseline. But make sure you have a clear, structured approach toward this.
At the integrated level, we've been delivering what we call the School of Multi-cloud, which is training and enablement for your team. It's been globally very successful, and we're happy to come and help equip your team to be able to operate in a multi-cloud environment. This is both technical as well as non-technical, and in the technical realm, this goes
quite deep around all of the topics that come to mind: operations, security, data, AI, networking, and more. At that flexible level is when I would recommend that you start thinking about contextualizing your approach for your vertical. For example, we have published best practices guidance and multi-cloud best practices guidance for FSI, financial services. You want to start adopting your vertical-specific best practices and guidance at that enterprise strategy layer.
Building Strong Foundations: Security, Observability, Networking, and FinOps
Let's look at the next layer, which is the foundations you need to lay in order to succeed in any of the layers above. This is a very wide topic that encompasses everything from operational security and observability to FinOps and networking. Let's dive into it straight at the discrete deployment level.
Our recommendation is that you definitely start with prioritizing security and applying consistent security policies across your clouds. Your security team, your central security team, does not really care whether your workload is running on cloud A or cloud B. What they care about is what regulation your organization needs to adhere to, so you need to make sure that you are applying consistent security policies across all of your clouds. You also need to make sure that you have unified observability. We see a lot of customers approach us around how to develop internal developer portals and so on. You can do all of that and we can help you with guidance and different mechanisms that help you make that happen easily, but you need unified observability and centralized operations before you can have any of that happen.
At that integrated level is when we would recommend that you start thinking through how you are going to design your cloud-to-cloud connectivity and redundant multi-cloud networking. If you have not been following the most recent announcements, we have a multi-cloud interconnect service that can help you with this piece. Also, here is when your cloud spend across different providers actually becomes meaningful enough that you need to adopt robust multi-cloud FinOps practices. Hopefully you have already adopted FinOps practices for single CSP usage. This is a topic that we have been emphasizing for years now. As you go around your multi-cloud adoption path, you should look into adopting multi-cloud FinOps practices as well.
At that flexible level is when you want to start evaluating if abstraction layers make sense to you. Some customers think of these as internal developer portals. Essentially, these are vending machines for your builders to be able to get cloud environments that are regulated, structured, have the necessary security policies, have the necessary observability tools already built in. We have a number of sessions at re:Invent that touch upon these topics as well, and I will come to that towards the end of this talk, but here is where I would recommend that you evaluate internal developer portals or abstraction layers like these.
Let's talk about some AWS capabilities that can help you implement these best practices. At the discrete level, we have hands-on workshops that your builders can leverage to get experience and sometimes even deploy different solutions. For example, we have one observability workshop that can help you deploy a managed Rifaa environment across clouds so you can really set up your environment through these workshops or at least get hands-on experience learning. We would also recommend that you standardize on different industry practices such as OTel for observability or NIST standards for security. We also have a whole host of AWS services that can help you at this discrete level around centralized operations, whether it be Systems Manager or something else.
I'd encourage you to take a look at AWS services as well. Something I didn't mention was that you can observe there is a lot of color going on in this slide, and that's deliberate. We earlier touched upon how there is a people process as well as a technology element, and the color coding is essentially to help you navigate which are all the people-oriented guidance and capabilities versus those that are process and technology related.
At the integrated level is when I would recommend that you adopt standards such as FOCUS. FOCUS is a cost and usage specification that has been agreed upon by different cloud providers: AWS, GCP, Azure, and more. AWS is part of the FinOps Foundation which owns the FOCUS specification. It helps you bring all of your cost and usage data in a single, known format so that you can make sense out of whether the data is coming from AWS or whether your usage data is coming from another cloud provider.
To this end, to simplify all of this for you, we would also recommend that you look into the multi-cloud FinOps dashboard. There is a demo of this at our kiosk, so stop by and you can see how this looks like in action. You don't need to do anything more than go and turn on FOCUS and then leverage this FinOps dashboard to get your multi-cloud cost visibility.
At that flexible deployment model, we would encourage you to take a look at our best practices that are there in the open source-based CNOE, which stands for Cloud Native Operational Excellence. CNOE is a consortium of which AWS as well as a lot of large enterprises are a part. It helps you adopt a lot of cloud native operational excellence best practices. It not just tells you how you should think through operational excellence, it also allows you to deploy internal developer portals. It's open source, you can deploy it as is, you can extend it if you want, and a lot of large enterprises do actually adopt these internal developer portals.
We'd also recommend that you take a look at a few open source solutions that can help you with multi-cloud Kubernetes fleet management. There's a reason I'm talking about Kubernetes. A lot of customers think Kubernetes in tandem with multi-cloud, and while it might be easy if your builder is just experimenting in another cloud and they deploy a few Kubernetes containers, once this comes at scale, you really need to think about how you're going to manage your multi-cloud fleet across different providers.
For which we have seen customers adopt different multi-cloud solutions of which AWS has contributed to as well, such as Argo CD and Flux, all of which helps you with multi-cloud fleet management. Again, we have a demo on this in our multi-cloud kiosk at the expo floor so come and check it out and you can learn more. We also have a whole host of not just AWS professional services who can come and help deploy different sort of solutions in tandem with multi-cloud, as well as AWS partners who can come and help you if you need additional people help with this.
Architectural Principles: From Cloud-Agnostic Standards to Internal Developer Portals
Let's move on. What about architecture? At the discrete level, what I'd recommend is that as an organization you need to come together to determine what are your architectural principles that matter to you. Is it portability? Is it interoperability? Maybe it's both, as well as maybe you want to standardize on open source, but the key thing is number one, standardize on your principles, and number two, it needs to be cloud agnostic.
You cannot say my cloud architectural principle is to use API Gateway with Lambda. That's not an architectural principle. You could say that this type of a workload, this type of a business workload that is best suited for serverless is best suited for a serverless pattern, and we would recommend that builders adopt a serverless pattern that is cloud agnostic architectural principle. A lot of customers here have standardized on open source.
We have customers here at re:Invent talking about their path along this as well. Adobe is here, so you should go and check out that session. I'll leave a pointer to that at the end as well.
At that integrated level, whatever architectural principle you've laid out before, you want to take them and build out blueprints that your builders need to adopt. You want to really socialize this through a construct such as the Cloud Center of Excellence, or CCOE for short. A lot of customers, I suspect here as well, have an existing CCOE. So your best bet is to put these blueprints and socialize this and structure this via a mechanism such as the CCOE.
Typically, at that flexible deployment model, we see that all of these blueprints that you have established before are now available as cards that your builders could pick out from based on a set of specifications that is available at an internal developer portal. So if I'm a builder in a large enterprise that's having a flexible deployment model, I'll come to an IDP and I'll say this is the kind of application I'm trying to build, click click click click click, and that's going to give me a blueprint and it's going to say click to deploy this. You want to get to that point, right? An abstraction layer integration, from a capabilities perspective, we would recommend that whatever principles you have aligned on as an organization, you tie that in tandem with the Well-Architected Principles and the framework.
Hopefully you're familiar with the AWS Well-Architected Framework. It's been in existence as long as I've been in AWS, which has been quite a long time. When it was built, it was built to be cloud agnostic. So certainly, if you want to pick out principles from the framework that will work well, or whatever you pick out, you want to see if it aligns well with the Well-Architected Framework. It will also give you some additional considerations to think through.
At the integrated level, we'd invite you to partner with us around building your multicloud CCOE. We've done that successfully for customers, and we have a very prescriptive playbook on how customers can actually go about building these multicloud CCOEs. At the flexible level, we would recommend that you look at industry-specific best practices that actually tie back to what kind of architectural patterns you want to adopt. For example, we have best practice guidance for financial services that is very prescriptive on what kind of architectures fit best for different use cases.
Multi-Cloud Data and AI Strategy: Guardrails, Lineage, and Democratization
Finally, we're on to our two pinnacle pieces: data and AI. We're going to cover both of these together, simply because we often see that this is a very interlinked topic whenever it comes to customer discussions. If you want to have a successful multicloud AI strategy, then you need to have thought through your multicloud data strategy effectively. Therefore, we're talking about this in tandem.
At that discrete level, what we would recommend is that you really think about what kind of guardrails you're going to put in place for your multicloud data and AI. What does this look like in practice? Maybe you're a healthcare organization and your guardrails would be how you want to either obfuscate PII and PHI, personally identifiable information or personal health information, and what kind of guardrails you want to put in terms of how AI would be able to use that data. So it's guardrails not just in terms of what kind of data you have, but also how your models would leverage that data. What data can it use, what data can't it use?
With a deployment model, you really want to start thinking about how you do effective capacity planning when working with customers. We see that some of their best laid plans in terms of data strategy and AI strategy often hinge on how much capacity is available in the providers that you use. Often I see that customers recognize this as the trigger point for multicloud itself, right? Because maybe you were on one provider leveraging one model because your data was there, and you realized that provider has only that much capacity. So how are you going to effectively succeed in your multicloud strategy? You do that by doing proactive and effective capacity planning.
Also, as you move to an integrated deployment model, you start really paying attention to whether you are effectively tracking data quality and data lineage. Where was this data born? Who changed it and where? Which AI model is allowed to use it? So what is your mechanism in your organization to track data lineage? It becomes extremely important to track these points.
At the flexible deployment model is when we would recommend that you start thinking through how you are going to democratize data and AI usage. The vast majority of our data conversations often start here. But before you start succeeding in this, you need to put all of what I have spoken about in place: the guard rails, the capacity planning, the data lineage, and so on. What do we mean by democratizing multicloud data usage? Maybe you have data in multiple clouds and you are leveraging models across different providers, maybe even different partners. You want to go to a model where your builders are able to leverage services and models for AI irrespective of where your data actually resides.
Your producers are able to produce the data and hand it over to some kind of a centralized data team, and you have your consumers on the other end who in many cases might even be producers themselves, prosumers, so to say. The consumers in turn are able to leverage the data from the data team. So you have producers, your data team, and then your consumers. That is the ideal democratization model where you have self-serviceability for the consumers and your producers can produce without actually thinking about anything else.
So what kind of AWS capabilities can help you with implementing these best practices? Recently we announced the Well-Architected Responsible AI Lens, which lays out a lot of the best practices and how you should think about what considerations you should have, especially at that discrete deployment model. I encourage you to check that out. I think it speaks well to the best practices that we advocated for in the prior slide.
At that integrated level is when we would recommend that you check out the AWS services, whether that be Agent Core or Athena or more, that can help you with multicloud data and AI. At a flexible level is when you want to start considering whether you need something like a data mesh architecture, which precisely helps you do the producers, the consumers, and the data team that we have. We have at least two sessions at re:Invent that help you think through this. So I will give you some pointers towards the end as you go through the conference. Think through whether this makes sense for your organization. We have a lot of guidance that is already published on this. I encourage you to go and check out the guidance around this.
Key Takeaways, AWS Multi-Cloud Resources, and Next Steps at re:Invent
So that brings us to the key takeaways. We talked about thinking about our people, process, and technology. The most important thing that we stress is that our strategy should not be determined by the services we use, by our people, by our processes. It is the other way around.
Once we define your multi-cloud strategy with you or once you come to us with a defined multi-cloud strategy, we can move forward and think about all the different aspects and the different recommendations that we have for each. As far as AWS is concerned, it doesn't matter what your cloud architecture is. It doesn't matter where your workloads are, and it doesn't matter which cloud service providers you chose to use. The multi-cloud program and our team provide consultancy at no cost. It's part of our service to our customers in order to help them navigate this complex environment.
We will guide you through this process. We shared these strategies and best practices at a very high level, but as we work with customers, we work with them long term. We start with that definition: what is our goal? Are we going to stay discrete? Do we want to go all the way to flexible? Then we determine where we have to make adjustments in our people, process, and technology in order to succeed with that use case.
In addition, the multi-cloud program not only provides you with enablement and guidance, we also release thought leadership. We help customers write an exit strategy, yes, even if it's off of AWS. If you need an exit strategy document or a policy for your regulators, we'll gladly help you develop it. We have customers who want to know if they're putting the right workload on the right cloud, and they look for that workload placement strategy. If they don't have one, we can help you develop your own.
We'll help you define the different dimensions to reduce risk as you make your workload placement strategies. It could be that it's led by organizational dimensions, it could be risk reduction, it could be performance-led, or it could be for any other reason. We can help your builders and regulations. We can help you build those dimensions and come up with this document, which hopefully will be programmatized, showing where to put your workloads.
I want to leave you with some next steps. At re:Invent, we have a good catalog of multi-cloud sessions for you to check out. Being the first day, I think it's extremely meaningful to help you navigate. At the foundation layer, we have sessions covering security, networking, observability, FinOps, and I alluded to our most recent announcement around AWS Interconnect multi-cloud. If you want to know more about how to do multi-cloud networking along with this new service, check out our networking session.
I've left you with some codes. If you plug this into the re:Invent catalog, you can see them. Essentially, they cover the foundations layer. Then we have more sessions at the architecture layer. At this layer, we're talking about how to do multi-cloud Kubernetes fleet management and how to think through multi-cloud resilience, which is an extremely nuanced topic. We have Monzo Bank here to talk about how they think about multi-cloud resilience, so check it out.
Again, there are a bunch of codes for you to look at. At the data and AI layer, we have another four sessions for you. One talks to how you think through from data strategy all the way to your AI usage. We have chalk talks that are completely dedicated to how you effectively build your data strategy or how you effectively implement generative AI-based solutions. If you want to take a photo of this, I'll leave it on for a second, but I think this is very meaningful for you to plan your days at re:Invent. I'll leave this on for a few seconds and then we will move on.
We also have a multi-cloud kiosk at the expo floor in the AWS village. Come and check us out. We've got demos on multi-cloud FinOps and Kubernetes multi-cloud fleet management. We also have a demo on multi-cloud data and AI where we talk about agentic AI orchestration across clouds with the data spread between Google and AWS. It's fantastic. Come and talk to us. We're going to hang out there, so if you have any deep dive questions, come and ping us. We're happy to engage with you.
Of course, we also have executive briefings. If you haven't already leveraged this, you can actually go up to the Venetian 4th floor or set up an ad hoc executive briefing. Just talk to your account manager and let them know that you want to meet with our team. They can schedule an executive briefing, and we can spend an hour with you to help you specifically with whichever topics you'd like to raise.
Lastly, I want to leave you with two resources. One is the multi-cloud landing page, and number two is the dedicated multi-cloud blog channel for any sort of future announcements and more. That's it. Don't forget to complete the feedback in the mobile app.
; This article is entirely auto-generated using Amazon Bedrock.
More...
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 - Navigate multicloud with AWS: Essential foundations for success (HMC101)
In this video, Ellie and Shankar from the AWS multi-cloud program present foundational guidance for operating in multi-cloud environments. They introduce the AWS Multicloud Readiness Framework and discuss three deployment models: discrete, integrated, and flexible. Key topics include understanding customer motivations (flexibility, M&A, regulatory requirements), defining clear business cases before adoption, and implementing best practices across enterprise strategy, foundations (security, networking, FinOps, observability), architecture, and data/AI layers. They emphasize that adding another cloud doesn't automatically solve challenges like lock-in or resilience without proper architectural planning. The session covers AWS capabilities including the multi-cloud FinOps dashboard with FOCUS specification, CNOE for internal developer portals, and tools for Kubernetes fleet management. They stress the importance of cloud-agnostic architectural principles, unified observability, consistent security policies, and democratizing data/AI usage while maintaining proper guardrails and data lineage tracking.
; 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 to AWS Multi-Cloud Program and Session Overview
Hi everyone. Welcome to HMC101. Our assumption for this session is that you're operating in a multi-cloud environment or planning to do so. Can you raise your hand if that's the case? Alright, if your hand is down, this would be a good time to leave. You're still sitting, good. I'm Ellie, and this is Shankar. I lead the AWS multi-cloud program, which means we provide cloud agnostic support to customers operating in a multi-cloud environment. This includes thought leadership, strategic consulting, and best practices. Agnostic means that we might not even recommend specific services to one cloud or another; we may recommend them all.
We're going to take you through our session today and have fun. We're here to provide cloud agnostic guidance, right? So architectural patterns and services and the way you would string them together, what kind of patterns you should look for. Here's what we have in store for you. First, this is a foundational session. So if you have a lot of experience running a multi-cloud environment, you may be aware of these topics. You may learn things you don't already know, but just to level set, this is our foundational strategic guidance.
Now, as far as what we'll cover today, we're going to start with what we hear from customers—voice of customer feedback we've gotten. We'll introduce the AWS Multicloud Readiness Framework, which is one of the ways we guide customers to prepare for having a multi-cloud environment. We'll then go through some of our best practices, what we share with customers that come to our program to get information. We'll make sure to end with some key takeaways for you to know, including some other sessions we recommend for you to join this week.
As I said, my name is Ellie and I lead the business side of the multi-cloud program at AWS. We have over 150 specialists that have mastered these topics. They either have certifications from other clouds or they have experience deploying AWS services on other clouds, so they can provide that guidance. Think about this as a consultative experience. We work with our customers long term. It's not a one-time thing. Whatever it is that you need, we're happy to provide and bring the right experts to support you.
Customer Voices: Motivations and Use Cases for Multi-Cloud Adoption
I'm Shankar. I lead the technical practice area in AWS, and I'd like to start by telling you what we're hearing from our customers. We talk to a lot of multi-cloud customers and we capture a few themes. I want to highlight a few of those themes that are worth bringing up to you. First is flexibility. Most customers—this is from a global telecom company—tell us that they adopt multi-cloud strategies because they're looking for the flexibility that adopting multi-cloud strategies gives them. In this case, they're adopting three clouds.
The second quote comes from a large enterprise. This is also an ISV. They're further along in their multi-cloud journey. What I want to highlight here is the fact that they have standardized on some enterprise level principles. They're standardizing on the architecture principle of adopting open source, which is a very common theme we've seen with many large customers on this multi-cloud journey.
The third quote is from a consumer genomics company, and it highlights how we're seeing Gen AI and multi-cloud adoption go hand in hand. In this case, this customer really wants to adopt what we call best of breed AI services. They just want to be able to innovate and adopt AI services across different cloud providers or partners. Where it comes from is not of any concern to them. So there is this trend of how Gen AI is fueling customers' multi-cloud strategies.
We also see that there are a few motivations. There are some pan-global teams that we see.
If you're an Independent Service Provider (ISV), you're probably going to look for a multi-cloud strategy because you want to serve your customers where they are. You might be in a mergers and acquisitions scenario, which is very common. Let me do a quick poll here in this room. Did anyone come to the multi-cloud space through an M&A? Show of hands. Okay, some of you did. We also see some geo-wide trends. This is not to say that this is just happening in one particular geography, but this is what we see more predominantly. For example, in North America we see customer contracts often drive multi-cloud strategy. In Europe, we often see regulatory requirements dictate the customer's multi-cloud strategy. In Asia, we see that topics such as resilience are guiding customers' motivations towards looking at multi-cloud.
These are some of the trends we're observing. Are you seeing something else too? Well, in a lot of cases we see customers mention several motivations. We want to avoid lock-in and we also want to take advantage of differentiating capabilities. We might end up with a regulatory requirement, so it could be a few different factors. There are definitely cases where we hear that companies are multi-cloud because of executive guidance. It could be that a company had a change of executive leadership and an executive came in with experience from another cloud provider and they want to push that direction. But the most important thing for us to remember is that some of these use cases aren't solved by just adding another cloud.
If you want to avoid lock-in, just adding another cloud isn't going to get you there. We talk about architecting for portability. If you're talking about resilience as a use case, that's very nuanced because adding another cloud doesn't make you more resilient. It actually could make you less resilient. So we help customers think about situations where adding another cloud can help you reach that use case. One of the things we always ask our customers is: let's start with why. What was the reason you opted to operate in multi-cloud? What is that end use case we're hoping to get to? Because if we don't know where we're going, what the destination is, it's going to be very hard for us to pave the way to get there.
Defining Multi-Cloud Deployment Models: Discrete, Integrated, and Flexible
If we drill down onto why you're operating in a multi-cloud environment and what value you expect to get out of operating in a multi-cloud environment, it will help us guide you along that way and reach success. I think it will be super meaningful to define the term multi-cloud. I'm sure each one of you has your own definitions, but for the sake of this session and for the other multi-cloud sessions at re:Invent, we define multi-cloud as the use of multiple cloud providers for meaningful workloads. This means we are automatically excluding, for example, your use of some kind of SaaS solution that might be running in a cloud provider that's not your primary. That is not the use case we're talking about. While that might still be a valid multi-cloud use case, for the sake of this session we're talking about using two or more cloud providers to operate meaningful business workloads as a strategic business decision.
If somebody's just playing around and launching a workload on another cloud, that's different. As we listen in and observe, we've identified a few patterns. I have to say this is my most favorite slide. We see that there are a few distinct patterns. On the left you see customers adopting multi-cloud in what we call a discrete manner. You might have a workload in cloud provider A and another workload in cloud provider B. For all practical purposes, they're just sitting there in their clouds doing their own thing. They're not talking to each other. While you might have a portfolio of multiple clouds, they are just like ice creams in two different cones. The second category is what we call integrated, where you might have workloads in multiple clouds and some of them are actually interfacing with another. Maybe you have data here that is accessed over there in another workload with another cloud service provider. That's your middle sort of multiple scoops in a bowl.
Further along is what we call the flexible mode, where you're really trying to offer your builders an environment that is agnostic to the underlying cloud that will actually support that workload. You're taking off all of that undifferentiated heavy lifting and you're adopting the benefits of multiple clouds. When we ask customers what their goal is, we understand that this doesn't necessarily mean maturity; it just may mean a different business strategy. Some of our customers want to move towards flexible multi-cloud and they want to have abstraction, they want to have full control planes and observability, which we call a single pane of glass. We don't use that phrase anymore because it became confusing. It's never actually single, so we need to understand what is it that you're hoping to achieve. Are you looking for that combined integrated multi-cloud strategy or just operating multiple clouds with maybe one central control plane? You could have any kind of option you want, any flavor.
That brings us to the AWS Multicloud Readiness Framework, which is a structured way in which we would recommend customers go through their multi-cloud adoption. We've been working with a lot of customers over the years, building out this framework that touches upon different layers from enterprise strategy to architecture all the way to AI. As we walk through this presentation, you will see that we keep leaning in on this particular framework and we hinge our best practices and our guidance as well as our capabilities and services along this framework so that you can be ready as you go about multi-cloud adoption.
In practice, how does multi-cloud deployment actually look? We often use an airlines analogy for that. This is my favorite analogy for going multi-cloud. Let's assume you have one fleet of airplanes, and your life is easy. If you think about your people, they're all trained on this one fleet of airplanes. Your pilots all know how to fly all airplanes. Your staff knows how these airplanes work and they know where everything goes. It's very easy and we don't have to train them on other models of airplanes. Same with the process. If a customer makes a booking, the booking system is all the same. Even if I have to swap out airplanes, seats are the same and they can still sit where they booked. With technology, let's think about spare parts. If I only have one airplane model fleet, my warehouse will just have the spare parts that I need for that one model airplane.
But what happens if, like in mergers and acquisitions, I want to expand and I end up purchasing a different fleet? Now I have some thinking to do. What about my people? Are they all going to be trained on all the different models, or do I have specialization? What about my process? How do I have to change it now in order to support the fact that it might not always be the same exact airplane? With technology, we're now looking at complications. How do I actually change my tech stack to support the fact that I now have two different fleets? And then let's talk about the part where we're now adding a third fleet. Now things get even more complicated. Now I have different hubs. Are all the different planes going to be in all the hubs? Are they going to be just specific routes for special planes? What happens when they reach a different hub? What if I have to swap them out? This helps people that don't have IT experience or knowledge understand the complexity.
When we talk to executives, we sometimes have to go through explaining how adding all of these different clouds increases your complexity and it can increase your cost. So going back to where we started, we better have a use case because we want to measure that ROI. I've just added complexity, I've added cost, I've added work in order to manage this complex environment. I want to make sure I get my value out of it. Of course, everybody wants to get to the promised land, so to say.
You really want to get to the point where you are more efficient than you were when you were with a single fleet of gray airplanes, and you can get there. But you need clarity, as Ellie's been talking about, around what are the KPIs that you're going to measure yourself over. Have you actually thought through all of the people, process, and technology considerations? Eventually, we do see customers succeed and really organize their fleets in a meaningful way.
That's as far as the analogy goes, so let's come back to the cloud. We know more about the cloud than we do about managing airline fleets anyway. Just to summarize that part, we spoke about three distinct deployment models, and I want to emphasize this. These are discrete, distinct categories. You don't necessarily need to go from discrete to integrated and then to flexible. If your business needs propel you to go from discrete directly to flexible, then you would do so. You're perfectly fine establishing your baseline on discrete and staying there, or on integrated, or on flexible.
Enterprise Strategy Best Practices and the AWS Multicloud Readiness Framework
Now let's look at what are some best practices and AWS capabilities, and we're going to hinge this back on our readiness framework, all the way from enterprise strategy. We will start with the enterprise strategy layer and see what are some best practices that we would recommend you adopt toward multi-cloud readiness. I'm going to bring this back to the discrete, integrated, and flexible deployment models, and you're going to see the same sort of visual repeat.
At the discrete deployment model, we would recommend that you definitely rationalize your multi-cloud investment. Start with the why, because if you're not able to articulate in clear business case terms why you're doing what you're doing from a multi-cloud strategy perspective, then it's very difficult to make any sense of it, even if you are going further along in the integrated path.
As you go to an integrated model of deployment, here is where we would definitely recommend that you take a serious look at what is the skill set in your team. Are they really ready to operate effectively in a multi-cloud environment? How do you identify what the skills gap is and how are you going to address that? Also, eventually your success with multi-cloud strategy is going to reflect your overall organizational structure. You need to make sure that you think through how you're going to proactively and consciously design your team structures to be able to succeed with your multi-cloud strategy.
Eventually, to succeed in the flexible deployment, whatever strategy you've put in place, you want to make sure that you've defined it as a policy, better still an automated policy. You want to put all of this such that, let me take an example, what about workload placement? It is one thing to say that I'm adopting cloud A for this and cloud B for that, but you need to be able to programmatically govern that. You need to be able to influence your builders in a way such that either this decision is off their plates or they know exactly where a workload is supposed to go. You need to put your multi-cloud strategy as a policy and automate that.
Now let's look at some AWS capabilities that align with these best practices. At the discrete level, we've been talking about the readiness framework. We would highly recommend that you evaluate if this is the right kind of framework for your organization. It likely is. If not, it's based on an open standards-based, open alliance approach, so you can take this, make it your own, and create your own readiness framework out of this as a baseline. But make sure you have a clear, structured approach toward this.
At the integrated level, we've been delivering what we call the School of Multi-cloud, which is training and enablement for your team. It's been globally very successful, and we're happy to come and help equip your team to be able to operate in a multi-cloud environment. This is both technical as well as non-technical, and in the technical realm, this goes
quite deep around all of the topics that come to mind: operations, security, data, AI, networking, and more. At that flexible level is when I would recommend that you start thinking about contextualizing your approach for your vertical. For example, we have published best practices guidance and multi-cloud best practices guidance for FSI, financial services. You want to start adopting your vertical-specific best practices and guidance at that enterprise strategy layer.
Building Strong Foundations: Security, Observability, Networking, and FinOps
Let's look at the next layer, which is the foundations you need to lay in order to succeed in any of the layers above. This is a very wide topic that encompasses everything from operational security and observability to FinOps and networking. Let's dive into it straight at the discrete deployment level.
Our recommendation is that you definitely start with prioritizing security and applying consistent security policies across your clouds. Your security team, your central security team, does not really care whether your workload is running on cloud A or cloud B. What they care about is what regulation your organization needs to adhere to, so you need to make sure that you are applying consistent security policies across all of your clouds. You also need to make sure that you have unified observability. We see a lot of customers approach us around how to develop internal developer portals and so on. You can do all of that and we can help you with guidance and different mechanisms that help you make that happen easily, but you need unified observability and centralized operations before you can have any of that happen.
At that integrated level is when we would recommend that you start thinking through how you are going to design your cloud-to-cloud connectivity and redundant multi-cloud networking. If you have not been following the most recent announcements, we have a multi-cloud interconnect service that can help you with this piece. Also, here is when your cloud spend across different providers actually becomes meaningful enough that you need to adopt robust multi-cloud FinOps practices. Hopefully you have already adopted FinOps practices for single CSP usage. This is a topic that we have been emphasizing for years now. As you go around your multi-cloud adoption path, you should look into adopting multi-cloud FinOps practices as well.
At that flexible level is when you want to start evaluating if abstraction layers make sense to you. Some customers think of these as internal developer portals. Essentially, these are vending machines for your builders to be able to get cloud environments that are regulated, structured, have the necessary security policies, have the necessary observability tools already built in. We have a number of sessions at re:Invent that touch upon these topics as well, and I will come to that towards the end of this talk, but here is where I would recommend that you evaluate internal developer portals or abstraction layers like these.
Let's talk about some AWS capabilities that can help you implement these best practices. At the discrete level, we have hands-on workshops that your builders can leverage to get experience and sometimes even deploy different solutions. For example, we have one observability workshop that can help you deploy a managed Rifaa environment across clouds so you can really set up your environment through these workshops or at least get hands-on experience learning. We would also recommend that you standardize on different industry practices such as OTel for observability or NIST standards for security. We also have a whole host of AWS services that can help you at this discrete level around centralized operations, whether it be Systems Manager or something else.
I'd encourage you to take a look at AWS services as well. Something I didn't mention was that you can observe there is a lot of color going on in this slide, and that's deliberate. We earlier touched upon how there is a people process as well as a technology element, and the color coding is essentially to help you navigate which are all the people-oriented guidance and capabilities versus those that are process and technology related.
At the integrated level is when I would recommend that you adopt standards such as FOCUS. FOCUS is a cost and usage specification that has been agreed upon by different cloud providers: AWS, GCP, Azure, and more. AWS is part of the FinOps Foundation which owns the FOCUS specification. It helps you bring all of your cost and usage data in a single, known format so that you can make sense out of whether the data is coming from AWS or whether your usage data is coming from another cloud provider.
To this end, to simplify all of this for you, we would also recommend that you look into the multi-cloud FinOps dashboard. There is a demo of this at our kiosk, so stop by and you can see how this looks like in action. You don't need to do anything more than go and turn on FOCUS and then leverage this FinOps dashboard to get your multi-cloud cost visibility.
At that flexible deployment model, we would encourage you to take a look at our best practices that are there in the open source-based CNOE, which stands for Cloud Native Operational Excellence. CNOE is a consortium of which AWS as well as a lot of large enterprises are a part. It helps you adopt a lot of cloud native operational excellence best practices. It not just tells you how you should think through operational excellence, it also allows you to deploy internal developer portals. It's open source, you can deploy it as is, you can extend it if you want, and a lot of large enterprises do actually adopt these internal developer portals.
We'd also recommend that you take a look at a few open source solutions that can help you with multi-cloud Kubernetes fleet management. There's a reason I'm talking about Kubernetes. A lot of customers think Kubernetes in tandem with multi-cloud, and while it might be easy if your builder is just experimenting in another cloud and they deploy a few Kubernetes containers, once this comes at scale, you really need to think about how you're going to manage your multi-cloud fleet across different providers.
For which we have seen customers adopt different multi-cloud solutions of which AWS has contributed to as well, such as Argo CD and Flux, all of which helps you with multi-cloud fleet management. Again, we have a demo on this in our multi-cloud kiosk at the expo floor so come and check it out and you can learn more. We also have a whole host of not just AWS professional services who can come and help deploy different sort of solutions in tandem with multi-cloud, as well as AWS partners who can come and help you if you need additional people help with this.
Architectural Principles: From Cloud-Agnostic Standards to Internal Developer Portals
Let's move on. What about architecture? At the discrete level, what I'd recommend is that as an organization you need to come together to determine what are your architectural principles that matter to you. Is it portability? Is it interoperability? Maybe it's both, as well as maybe you want to standardize on open source, but the key thing is number one, standardize on your principles, and number two, it needs to be cloud agnostic.
You cannot say my cloud architectural principle is to use API Gateway with Lambda. That's not an architectural principle. You could say that this type of a workload, this type of a business workload that is best suited for serverless is best suited for a serverless pattern, and we would recommend that builders adopt a serverless pattern that is cloud agnostic architectural principle. A lot of customers here have standardized on open source.
We have customers here at re:Invent talking about their path along this as well. Adobe is here, so you should go and check out that session. I'll leave a pointer to that at the end as well.
At that integrated level, whatever architectural principle you've laid out before, you want to take them and build out blueprints that your builders need to adopt. You want to really socialize this through a construct such as the Cloud Center of Excellence, or CCOE for short. A lot of customers, I suspect here as well, have an existing CCOE. So your best bet is to put these blueprints and socialize this and structure this via a mechanism such as the CCOE.
Typically, at that flexible deployment model, we see that all of these blueprints that you have established before are now available as cards that your builders could pick out from based on a set of specifications that is available at an internal developer portal. So if I'm a builder in a large enterprise that's having a flexible deployment model, I'll come to an IDP and I'll say this is the kind of application I'm trying to build, click click click click click, and that's going to give me a blueprint and it's going to say click to deploy this. You want to get to that point, right? An abstraction layer integration, from a capabilities perspective, we would recommend that whatever principles you have aligned on as an organization, you tie that in tandem with the Well-Architected Principles and the framework.
Hopefully you're familiar with the AWS Well-Architected Framework. It's been in existence as long as I've been in AWS, which has been quite a long time. When it was built, it was built to be cloud agnostic. So certainly, if you want to pick out principles from the framework that will work well, or whatever you pick out, you want to see if it aligns well with the Well-Architected Framework. It will also give you some additional considerations to think through.
At the integrated level, we'd invite you to partner with us around building your multicloud CCOE. We've done that successfully for customers, and we have a very prescriptive playbook on how customers can actually go about building these multicloud CCOEs. At the flexible level, we would recommend that you look at industry-specific best practices that actually tie back to what kind of architectural patterns you want to adopt. For example, we have best practice guidance for financial services that is very prescriptive on what kind of architectures fit best for different use cases.
Multi-Cloud Data and AI Strategy: Guardrails, Lineage, and Democratization
Finally, we're on to our two pinnacle pieces: data and AI. We're going to cover both of these together, simply because we often see that this is a very interlinked topic whenever it comes to customer discussions. If you want to have a successful multicloud AI strategy, then you need to have thought through your multicloud data strategy effectively. Therefore, we're talking about this in tandem.
At that discrete level, what we would recommend is that you really think about what kind of guardrails you're going to put in place for your multicloud data and AI. What does this look like in practice? Maybe you're a healthcare organization and your guardrails would be how you want to either obfuscate PII and PHI, personally identifiable information or personal health information, and what kind of guardrails you want to put in terms of how AI would be able to use that data. So it's guardrails not just in terms of what kind of data you have, but also how your models would leverage that data. What data can it use, what data can't it use?
With a deployment model, you really want to start thinking about how you do effective capacity planning when working with customers. We see that some of their best laid plans in terms of data strategy and AI strategy often hinge on how much capacity is available in the providers that you use. Often I see that customers recognize this as the trigger point for multicloud itself, right? Because maybe you were on one provider leveraging one model because your data was there, and you realized that provider has only that much capacity. So how are you going to effectively succeed in your multicloud strategy? You do that by doing proactive and effective capacity planning.
Also, as you move to an integrated deployment model, you start really paying attention to whether you are effectively tracking data quality and data lineage. Where was this data born? Who changed it and where? Which AI model is allowed to use it? So what is your mechanism in your organization to track data lineage? It becomes extremely important to track these points.
At the flexible deployment model is when we would recommend that you start thinking through how you are going to democratize data and AI usage. The vast majority of our data conversations often start here. But before you start succeeding in this, you need to put all of what I have spoken about in place: the guard rails, the capacity planning, the data lineage, and so on. What do we mean by democratizing multicloud data usage? Maybe you have data in multiple clouds and you are leveraging models across different providers, maybe even different partners. You want to go to a model where your builders are able to leverage services and models for AI irrespective of where your data actually resides.
Your producers are able to produce the data and hand it over to some kind of a centralized data team, and you have your consumers on the other end who in many cases might even be producers themselves, prosumers, so to say. The consumers in turn are able to leverage the data from the data team. So you have producers, your data team, and then your consumers. That is the ideal democratization model where you have self-serviceability for the consumers and your producers can produce without actually thinking about anything else.
So what kind of AWS capabilities can help you with implementing these best practices? Recently we announced the Well-Architected Responsible AI Lens, which lays out a lot of the best practices and how you should think about what considerations you should have, especially at that discrete deployment model. I encourage you to check that out. I think it speaks well to the best practices that we advocated for in the prior slide.
At that integrated level is when we would recommend that you check out the AWS services, whether that be Agent Core or Athena or more, that can help you with multicloud data and AI. At a flexible level is when you want to start considering whether you need something like a data mesh architecture, which precisely helps you do the producers, the consumers, and the data team that we have. We have at least two sessions at re:Invent that help you think through this. So I will give you some pointers towards the end as you go through the conference. Think through whether this makes sense for your organization. We have a lot of guidance that is already published on this. I encourage you to go and check out the guidance around this.
Key Takeaways, AWS Multi-Cloud Resources, and Next Steps at re:Invent
So that brings us to the key takeaways. We talked about thinking about our people, process, and technology. The most important thing that we stress is that our strategy should not be determined by the services we use, by our people, by our processes. It is the other way around.
Once we define your multi-cloud strategy with you or once you come to us with a defined multi-cloud strategy, we can move forward and think about all the different aspects and the different recommendations that we have for each. As far as AWS is concerned, it doesn't matter what your cloud architecture is. It doesn't matter where your workloads are, and it doesn't matter which cloud service providers you chose to use. The multi-cloud program and our team provide consultancy at no cost. It's part of our service to our customers in order to help them navigate this complex environment.
We will guide you through this process. We shared these strategies and best practices at a very high level, but as we work with customers, we work with them long term. We start with that definition: what is our goal? Are we going to stay discrete? Do we want to go all the way to flexible? Then we determine where we have to make adjustments in our people, process, and technology in order to succeed with that use case.
In addition, the multi-cloud program not only provides you with enablement and guidance, we also release thought leadership. We help customers write an exit strategy, yes, even if it's off of AWS. If you need an exit strategy document or a policy for your regulators, we'll gladly help you develop it. We have customers who want to know if they're putting the right workload on the right cloud, and they look for that workload placement strategy. If they don't have one, we can help you develop your own.
We'll help you define the different dimensions to reduce risk as you make your workload placement strategies. It could be that it's led by organizational dimensions, it could be risk reduction, it could be performance-led, or it could be for any other reason. We can help your builders and regulations. We can help you build those dimensions and come up with this document, which hopefully will be programmatized, showing where to put your workloads.
I want to leave you with some next steps. At re:Invent, we have a good catalog of multi-cloud sessions for you to check out. Being the first day, I think it's extremely meaningful to help you navigate. At the foundation layer, we have sessions covering security, networking, observability, FinOps, and I alluded to our most recent announcement around AWS Interconnect multi-cloud. If you want to know more about how to do multi-cloud networking along with this new service, check out our networking session.
I've left you with some codes. If you plug this into the re:Invent catalog, you can see them. Essentially, they cover the foundations layer. Then we have more sessions at the architecture layer. At this layer, we're talking about how to do multi-cloud Kubernetes fleet management and how to think through multi-cloud resilience, which is an extremely nuanced topic. We have Monzo Bank here to talk about how they think about multi-cloud resilience, so check it out.
Again, there are a bunch of codes for you to look at. At the data and AI layer, we have another four sessions for you. One talks to how you think through from data strategy all the way to your AI usage. We have chalk talks that are completely dedicated to how you effectively build your data strategy or how you effectively implement generative AI-based solutions. If you want to take a photo of this, I'll leave it on for a second, but I think this is very meaningful for you to plan your days at re:Invent. I'll leave this on for a few seconds and then we will move on.
We also have a multi-cloud kiosk at the expo floor in the AWS village. Come and check us out. We've got demos on multi-cloud FinOps and Kubernetes multi-cloud fleet management. We also have a demo on multi-cloud data and AI where we talk about agentic AI orchestration across clouds with the data spread between Google and AWS. It's fantastic. Come and talk to us. We're going to hang out there, so if you have any deep dive questions, come and ping us. We're happy to engage with you.
Of course, we also have executive briefings. If you haven't already leveraged this, you can actually go up to the Venetian 4th floor or set up an ad hoc executive briefing. Just talk to your account manager and let them know that you want to meet with our team. They can schedule an executive briefing, and we can spend an hour with you to help you specifically with whichever topics you'd like to raise.
Lastly, I want to leave you with two resources. One is the multi-cloud landing page, and number two is the dedicated multi-cloud blog channel for any sort of future announcements and more. That's it. Don't forget to complete the feedback in the mobile app.
; This article is entirely auto-generated using Amazon Bedrock.
More...