AWS re:Invent 2025 - Evaluating architectural trade-offs: Cloud patterns for flexibility (ARC321)

🦄 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 - Evaluating architectural trade-offs: Cloud patterns for flexibility (ARC321)

In this video, Jean-Francois Landreau and Philipp Klose, Senior Solutions Architects at AWS, address cloud vendor lock-in concerns by reframing them as switching costs with multiple dimensions. They introduce two architect maneuvers: adding dimensions through a utility versus switching costs matrix, and thinking across layers rather than separating application and infrastructure teams. The speakers identify patterns that don't work well—provider service mappings and technical abstraction layers—and three effective patterns: managed open source (like Amazon EKS, RDS PostgreSQL), velocity through DevOps practices, and preserving design intent by documenting architectural patterns rather than just service icons. They emphasize that SQL became a standard through productivity first, not portability, and demonstrate how EventBridge can implement multiple patterns like scatter-gather. The key message is to focus on good architecture practices, design patterns, and business value rather than building complex portability frameworks that create opportunity costs.

; 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: Balancing Cloud Capabilities with Lock-in Concerns

Hello everyone and welcome to session ARC321, where we are going to talk about how you can take advantage of the cloud's capabilities without being stuck in the candy store. I'm Jean-Francois Landreau, also known as JFL. Philippe is going to call me that name. It's not a new service, and it's not an airport—it's only me. I'm a Senior Solutions Architect at AWS for global financial services.

My name is Philipp Klose. No jokes aside, my name is Philipp. I am also a Senior Solutions Architect working mostly in the financial industries, spending most of my time building flexible data and AI platforms, and these days also agentic AI platforms.

Let's get started. How many of you have been stuck in this conversation you can have sometimes with the application teams? They want to take advantage of the cloud's capabilities, as I said at the beginning, but the IT folks, the managers, and people with more experience in IT are worried because of their experience with what it could mean in terms of lock-in. Is it going to be the new mainframe? Are we going to have problems because of that? So how are we going to address this concern? It's a legitimate concern, and as architects, we need to articulate and make sure the application teams and the rest of the IT organization are going to be happy with the cloud.

The first thing we need to explain is what the application teams are looking for when they go to the cloud and what the benefits are. Then we are going to use two architect maneuvers. As architects, we can bring new perspectives. We are going to add dimensions, go through different layers, and with these tools that we can use, we are going to analyze patterns—actually two patterns we believe don't work so well when you are concerned about being able to move from one cloud to another or go back to your premises. So two patterns that work not so well and three patterns that work quite well.

First, let's talk about modern cloud applications and what the application teams are looking for in the cloud. Very often you are going to see this schema. I mean this diagram. I mean you understand it—VMs, probably not so modern, or less modern, but actually this diagram has multiple errors in it. So first, containers are serverless. What is the distinction? You can run containers in Lambda. You can run in ECS, Elastic Container Service, and you can run serverless. So you have containers serverless, so it's not accurate. Actually, you are not looking for only the runtime when you are going to the cloud and when you are using these capabilities that you have on the cloud.

Let's say now you have set up a Lambda function, but you have done it with clickops. Is it a modern application? Probably not. So you don't have CI/CD. You don't use deployments. It's probably not such a modern application. How much managed services do you use? That's going to determine also if the application is going to bring all the values you expect. Granularity—if you run a gigantic monolith in an EC2 instance, is it really a modern application running on the cloud? Probably not. So even programming language—if you are still on COBOL, you don't have APIs, it's probably not such a nice cloud modern application. So it's not only about the runtime, and you have all these other dimensions you need to take into account.

The reality is why you go to the cloud. You go because it's going to help you with scalability. It's going to clarify the cost. It's going to be more transparent. You are going to gain agility. You are going to be able to deliver faster and more frequently. All these advantages—more resilience and also observability. You are going to have more detailed observability that is going, for example, to help you identify where there is a performance issue.

Now if we look even more abstractly, what are we looking for? We talked about fine-grained applications. We don't want these large monoliths. When we have finer-grained applications, we gain failure isolation, so the resilience is going to be better. And then the teams, particularly when you have loosely coupled services, the teams are going to be able to work independently and they are going to be able to work faster.

And then some applications are even event-driven applications. With event-driven applications, you can make them evolve even more easily. Think about your message bus. You can put a new producer, a new consumer, and you extend and evolve your applications. Now people are going to say, "Well, we want that. Sign me up." There is no problem. These seem to be good qualities you want to achieve with your application team, so no problem with that.

Architect Maneuver #1: Adding Dimensions to the Lock-in Problem

But still, IT experienced senior managers may be concerned. Sometimes procurement may be concerned. But is there still a lock-in? Is there still something to pay if we go in that direction? We need to address that now. Yes, thank you Jean-Francois, and as Jean-Francois told you, as architects we are trying to create new dimensions, or rather, to see the world in more perspectives. We see the world as trade-offs, right? There is never this one single right solution, and there is never this one single wrong solution or option to solve a certain problem.

Given that, the most powerful architecture maneuver we can apply is actually twofold. We can try to break down the problem into multiple small pieces, and by doing this, we create and add more dimensions to the problem. Or, even better, we can also broaden the scope of the solution and have more options available for the actual problem. This may sound a bit abstract, but no worries. I will walk you through this.

So what we hear a lot, especially in the beginning of these discussions when talking about lock-in, is: "Well, I like to have the new world, this beautiful modern, fine-grained managed services, but then there is this red flag, which is the lock-in." The lock-in is basically a very single-dimensional perspective on that problem because there is no happy place for this, right? What we actually want to have is more cloud usage and less lock-in, right? We do not want to have this blue bar here. What we actually want to do is bend this curve and have a lot of cloud usage but less lock-in.

So the question is: how can we get there? As I have told you, architect maneuver number one is adding more dimensions to this problem. The first dimension we are going to break down into multiple small pieces is the dimension of locking. Actually, when we are talking about lock-in, most people mean vendor lock-in. That is the first thing. And the second thing, which is also the reality, is that there is no lock-in, right? So what people also mean when talking about vendor lock-in is basically the switching costs, right? The switching costs of moving from vendor A to vendor B.

If we keep this in mind, then we quickly can identify that there are even more dimensions to this, right? It is not only the vendor who is creating switching costs. It is also things like the product I am using. Maybe I am able to switch to a different product, which will of course also create switching costs. But also simple things like changing versions, right? Changing versions can be a simple problem but can be a terrible hard problem. For instance, upgrading your database version to a version which is not backward compatible, right? It is a hard and tough problem.

Also, architecture refactorings, right? Refactoring a monolithic architecture into, for instance, a distributed architecture is going to be a long and painful endeavor, right? And all these things contribute to the switching costs. And also, do not forget skills, right? If we are modernizing or changing into a different technology, re-educating your staff, your team, your workforce is also creating lots of costs. To stay within our two-dimensional story, the popular decision model we can apply, and also for this problem, is a two-by-two matrix. So we can try to break down the problem into the utility we are getting from our locking in relation to the switching costs.

And we will identify, by doing this, we can identify four quadrants. The most boring one is here in the white box. It is a commodity, right? Commodity means low value but low switching costs.

Think of it conceptually, for instance, like a USB stick. You plug it in. If it breaks, I buy a new one. I couldn't care less. More interesting though is the green box because the green box is: I'm getting a lot of value out of my login, but also I don't have a lot of switching costs. Unfortunately this is pretty rare, but there are these technology services that exist, and when JFL will later talk about managed open source, small hint, they apply to this green box.

And of course there is this yellow box. Yellow is a warning, right? Be careful. There are always these things like: low utility but high switching costs. I mean, the simple message is avoid them. And then there's the fourth very interesting quadrant with the blue one here, which means: OK, maybe I have a very unique problem. And I can accept a very high lock-in because the value I'm getting out of this lock-in, like with a marriage, is pretty high. Right? So this is an interesting concept to keep in mind. By this example, we can now have a much more nuanced discussion when discussing switching costs, and this is what we call Architect Maneuver number 1. By saying this, I'm handing back to JFL who will introduce you to Maneuver number 2.

Architect Maneuver #2: Thinking Across Layers and Patterns That Don't Work

Exactly. So Architect Maneuver number 2. The first one was about adding more dimensions and not staying in either it's good or bad, where nobody is happy in the middle. Actually, with more dimensions we have more possibilities, and we need to think across layers. You probably all know this model. How many of you have been either on the application teams or on the infrastructure team? And have been on the application team side, actually, and deployed on the operations teams who were responsible to run this application for me? And they are also deployed. The other technical term is throwing over the wall. Actually, the problem when you are on the upside is that very often you try to pass the blame on the other side, and it's a model that doesn't work. We have better ideas now. We do DevOps, but if you come from this model, like many of you, including me, you may think that the people in the blue box are responsible for the scalability, they are responsible for the availability, they are responsible for these aspects of my application. And then you may think: well, portability sounds a little bit like the other realities, so it's something that they should take care of. Very wrong idea.

So first, think about this. Who is responsible for the code in the Lambda and who is responsible for putting the Lambda together with your sequence, for example? Well, the separation is not so clear. Very often it's the same team, so you don't have this separation. It doesn't work so well. Actually, the application team has a lot of responsibility for the portability. So don't forget it's not only the responsibility of the blue box, but also of the application team. So now we have a new model, and probably many of you are using this one. We came with Platform Engineering and with this new model and new mindset. The platform team, the blue box, enables the application team. The application team has their full responsibility to run their applications. They are going to worry about the scalability and the availability. They are enabled by the platform team, but still they have to take care of that. And with this mindset, it's clear that portability is part of the responsibility of the application team.

So the lesson here is don't try to solve a problem somewhere else from where it originated, and it's the application team that has a lot of responsibility with portability. So yeah, we already announced it. We will also talk about things that do not work well, and one of them is provider mappings, and I have to admit

I was working as an enterprise architect here. No offense to any enterprise architects here, but what we typically have to do is draw these super nice high-level capability diagrams. If you just fly high enough, every cloud vendor looks the same and awesome. They have virtual machines, we have serverless functions. The same holds true for message queues and NoSQL databases.

But let's hold on. NoSQL databases come in many flavors. NoSQL database could be a graph database, could be a document store, a key-value store. There are myriads of different types of NoSQL databases, and all of them have been designed in a different context with a different philosophy in mind. They are already integrated in that specific environment. The more we zoom in into this problem, the more nuanced and different these things become, and it gets even harder to really distinguish between them or compare them on a reasonable level.

Just as an example, Amazon EventBridge is a pretty straightforward service. EventBridge, we're taking this as an example, though you can choose whatever service you like. I'm pretty sure it applies to all of them. It's built as an event bus. When the state of an event changes, something happens in the AWS cloud or in your application, so you're sending an event to the event bus, and then it triggers a downstream step function, Lambda function, or whatever you need.

But here's the important part. There are lots and lots of unique different properties of this service that come along with it. For instance, it comes through a schema registry, has hundreds of different connectors built in, and event filtering. All of them are unique abilities. Remember the metrics we had, the two-by-two matrix where we're talking about value when you choose a service? You choose the service for certain features, and maybe for your problem, EventBridge is the perfect fit because you require an event registry. If you're not having the discussion on that level, you actually cannot see this value and might be taking the wrong decisions.

What I want to show you with this example is that service mappings are a dangerous illusion and oversimplify the problem of picking the right service. This was the first pattern that we believe doesn't work so well. We don't do service mapping. We don't have that. Some other vendors do that, but we don't because there are many things we can distinguish.

Why Technical Abstraction Layers Fall Short as a Portability Solution

The other pattern we have seen a lot that doesn't work so well is technical abstraction layers. We all know layers. They solve a lot of problems. There's even a saying in IT that you can solve any IT problem with a new layer. Does it work so well all the time? Well, we have a demonstration. It works well. We have done that already. We have standardized, for example, for our web services so that we can communicate. We can build web services in different languages. Today I can decide to work with Java over here, and Go over there. How did we manage to do that? We added this API layer and we standardized the layer on top. HTTPS, we all use that. JSON, we all use that. We standardized the layer and by doing that, we gain options. We harmonize on top and we gain options at the bottom.

This doesn't mean that you should build an application with all possible different languages, but it means that if you work with another partner that works with Go and you work with Java, you can still collaborate with each other. What happens with this standardization is that we open new options. Now let's apply this principle. We know it works. Does it work for the cloud? Platform A, Platform B. We put the layer on top, and then we have the applications and they are going to be able to move from one place to the other.

Let me take one example that demonstrates that this doesn't work so well. I don't know if you know Esperanto. Well, I know Esperanto because the capital of this language is close to where my parents live in France. But most people don't know that, so it's a language. The idea was to pick some words from the different human languages we speak, pick some of the grammar, and build a new language so we could all communicate with it. The problem with that is everybody needs to learn Esperanto, and actually we already have a de facto standard: English. I'm French and I have a bad accent, but I still speak in English and you can all understand me. So we don't have this need to learn a new language, and that's the idea behind this extra layer you may not need.

Another problem with this pattern of adding more and more layers is that cloud vendors are different. If you remember the event picture, for example, there are little nuances which are different. What I saw a lot with my big customers is the idea that cloud provider A does not have this feature, so they start to build these features on their own and try to catch up with the cloud provider. But honestly, this is a super tough race. We're releasing around thousands of new features over the year, so keeping up with this race is going to be a super costly endeavor.

Obviously, what you can do is try to do the opposite: just use what the common denominator of the different cloud offerings is. But this will eliminate the value you're actually trying to get out of the cloud because then you can only use what both have in common. This also puts you in a disadvantaged spot relative to your competitors because you're not using the value you could get out of the specific services.

There's another aspect of this, and this is where this approach clearly gets to its limits because there are also physical characteristics of these services which you cannot influence just by adding new layers . For instance, the pricing model is something we define. Whether a service is built by request or just by uptime is something you simply cannot influence. The same holds true for things like the geographic presence or availability of a service. We as the vendor decide where to deploy a service or not. You can hardly deploy, for instance, DynamoDB where we don't have a region. So it's a pretty tough problem to solve.

I do not want to neglect that these options provide value . We discussed this in the very beginning, and indeed options have a value. I think there's even a mathematical proof for this, and I'll show you an example later why and how they add value. But the point is, especially when adding these layers, you also have to keep in mind the developer efforts and developer rewards you have to invest in by adding these layers. But also, and this is often overlooked, is the opportunity cost of doing this. While you're investing in adding and building all these layers and doing the investments to keep the switching costs low, you're not investing into your business. You're allocating money for something which could maybe even better contribute to the business. And you're increasing the complexity of the system, which is something at least we as architects don't like.

As you've learned in the beginning, Jean-Francois and I are working in financial industries, so we had to pick an example which is from financial industries. An interesting model to look at this problem is actually option pricing. Options work like an insurance: you pay an upfront fee to control or reduce the impact of an event . For instance, like stock prices.

This applies well to our problem actually, because we should not be naive and avoid investing anything into preparing for switching. But on the other side, we should also not overcommit to preparing for the switch because in the end, the point is to switch. It's an event that might occur, but we're not sure it's going to happen. The question is whether it even ever happens. And on top of this, it's money we have to invest now, which is then not available anymore to contribute to our business. So the message is actually quite simple. The sweet spot most probably is somewhere in the middle and not at the extremes.

We work with global financial services and big enterprises, and very often they ask how they can be as fast as we are. How can they be as fast as a startup that works on the cloud? Actually, this fast company has one of the secret recipes. They don't like to use complex portability frameworks because, as we've seen on the curve for options, you have an upfront cost. It's money you need to invest, and it's effort distracted from the features you want to build and from the speed at which you want to bring new features to your customers.

But we have some other examples. Some people are going to say, well, SQL. Isn't SQL an example where we have a standard? Everybody is talking the same language. Most databases support it. This is a good portability framework. So what is interesting here is to look at the history of SQL. How did it appear? It was IBM. They had new storage systems and they wanted to make sure that the application teams could be efficient and access the data efficiently. Then they developed this language, and competitors realized it was pretty cool and decided to implement the same thing.

Implementing the same thing is not that easy. It's 587 pages of specification, and we all know that different databases don't exactly support the exact same definition of SQL. If you want to port from Oracle to PostgreSQL or from IBM to another database, you know it's not straightforward. You're going to have some effort to do. What's important to recognize here is that productivity was the trigger. This is what made SQL a standard. You need to bring productivity first and think about portability as a second aspect. Why is that? If your competitors are productive and deliver a lot of features while you are developing your portability framework, you may not have to worry about portability anymore.

Three Patterns That Work: Managed Open Source, Velocity, and Preserving Design Intent

When you select a product or framework, it needs to help you today. It makes you productive now, not only in the future, because the future may not come. So now we are finished with the bad news and we are starting with the first pattern, which is actually good news. We started to talk about SQL as a de facto standard. In open source, we have a lot of these de facto standards. Somebody creates a new database system and shares it as open source, and a lot of people start to realize it makes them really productive. Then it gets several implementations, and what cloud vendors have done is provide managed open source. We have managed open source in nearly all categories. We have a lot of databases. I talk about PostgreSQL. We have managed Aurora and RDS with different options. We have Amazon EKS. I'm a big Kubernetes fan, so with EKS you don't have to worry about the control plane. This is managed for you, but you still have the standard that you like to deploy your applications to.

We implement your platform, and we have many of these other systems. On the messaging queue side and EMR, there are many different places, and it doesn't stay only on the web application side and not only the service you use for web applications. I guess you are going to hear a lot about AI/ML during this week. Well, we do the same efforts, so we bring you open source, managed solutions. It's on the green place in the schema from Philippe, so a lot of values, but switching costs are limited, and we manage that for you. Same thing for Gary. We have Bedrock where you can have a number of LLMs that are open weight, so maybe not fully open source, but open weight, and you can customize them. We have the Bedrock adjunct core and we will see with adjunct core, so we run the adjunct, but you can still select your framework and very often it's an open source framework. We have Amazon SageMaker on Jumpstart where you will be able to use some of the open source models more on the area and let them run very easily on SageMaker.

So how does that look for standard applications? Well, you are going to have agent core here. You are going to be able to select your framework, so still open source. You can select your own agentic framework. You are going to select the model as well. You have options and you can select an open weight model, and then the rest around the mechanics, the heavy lifting, which is not really bringing some differentiation, we will take care of that for you. So managed open source is a good pattern. Use that a lot. You have the open source that brings the portability plus the value, and we manage that for you. So the switching cost is going to be reduced, and you have a lot of value for it. That was the first good pattern.

Let's continue with the good patterns and the second pattern or highlight of this idea on how to reduce switching costs is velocity, and that's a dimension we haven't talked about yet. If you remember our graph from the very beginning of the session, we were thinking about what are the dimensions we could add. We broke down the login. But there is another dimension, the one I mentioned a second ago, which is velocity, and velocity is pretty interesting. The good news about velocity is first of all it's fully under your control, right? It does not depend on us as a vendor. The second good news is that investments into, let's say, logical layers or other stuff, investments into good DevOps, lean organization, and agile practice directly pay out. It's kind of a no regret move because you directly benefit from having things like continuous integration and continuous testing. It's obvious because think of it this way: now I need to, for instance, change my architecture or refactor from monolithic to distributed. Having these continuous delivery pipelines in place will drastically reduce the risk and the costs of doing these things.

An often forgotten and overlooked aspect of this discussion is agile, not agility in terms of having our daily stand up. It's more like how it helps a lot to really focus on the business outcomes of your products, and by doing this, you're reducing the clutter left and right, which you have to touch again and again when it comes to the event of switching. In a nutshell, switching costs is also a matter of how you work and not just only about which services you are going to use. By this, we have already seen two good patterns. First one, managed open source. Second one, velocity. It's going to help you. Good development practices is going to help you to move. Another one where the architects may have a very important role is to preserve the design intent. And what does that mean?

Let's talk about EventBridge. EventBridge is a simple service with a simple icon, but there are many features behind it. You can implement many different patterns with EventBridge. Here we have four different patterns that can be implemented with it. If the only documentation you have about your architecture or your applications is this diagram with the icons from AWS, they are really nice, but they don't give you much information. They don't tell you how you are going to use it. Is it a message filter or is it a recipient list? These are completely different approaches. When you are going to port this application, it's really important to know which one you're using. If the only place you can find this information is inside the code, you quickly realize that for the portability of your application, it's going to be more complex. You will need to reverse engineer the code, and then it's going to take time, so the switching cost is going to be significant.

As an architect, if you think only with platform icons and really nice service selections, that's good, but it's not enough. You should think about design patterns. They communicate information that will be relevant on platform A and platform B, whatever the service you use to implement them. Now let's dig into a more complex pattern. A central pattern is scatter-gather. Not only should you have the nice icon, now we have the pattern, but actually on this pattern there are many architectural decisions being taken. The first one is broadcast. How many recipients will it broadcast to? Is it a fixed set? Is it viable? Depending on this decision, it may be EventBridge, it may be another service, so you should document that.

Then there's the recipient question. Should they give back an answer? Should they provide a message? Maybe, maybe not. That's another decision which is really important in the way you design your service, and it doesn't determine which service on AWS you use. Same thing applies when you aggregate. Do you need to wait to aggregate everything? That's another decision. Same thing. How do you output? How do you concatenate and give this response? Well, it's not something you see simply in the diagram, so it's not enough. You need on top of that to document and have some text around your diagram, and that means noting all the decisions that you have taken. When you document that, you realize that the service selection doesn't depend entirely on these decisions.

What is important here to think about is that service selection is only one part, but there are many other critical decisions that you need to document. You will need to provide this information so that porting the application becomes easier for the team. You don't need to go inside the code. You don't need to reverse engineer. You have this information, and with these patterns and with the description of all the decisions on the patterns, you are going to reduce the switching cost. That was the last pattern and the last good news, and we are going to summarize what we discovered.

Key Takeaways: Reframing Vendor Lock-in as Switching Costs

The key takeaways we want you to take home from this session are basically starting with reframing the problem. Instead of talking about vendor lock-in, talk about switching costs. By doing this, we are automatically breaking down the problems and adding more dimensions to it, which allows us to have a much more intelligent discussion about the actual switching costs. We also learned that options provide value. Remember the graphic with the option pricing? But they also have costs. Things like the upfront investments you need to do and the opportunity costs of not investing into actual business. Then we showed you the patterns, the provider service mapping, which is typically far too high level and does not take into account the characteristics of these services, which then provide you the actual value of specific services. We've also seen that adding layer upon layer is most probably not going to solve this problem.

We also have the physical characteristics of the specific services which we cannot change or influence, but there are good things as well. The things that work—Jean-Francois Landreau has introduced the idea of using managed open source, and I think this is a pretty good pattern. This sits in the green quadrant from the beginning, having a lot of utility with actually low switching costs.

It is always good to have well-established DevOps and agile practices. They always help, so this is really a no-regret move. Just do it; it always helps. Also, think in design patterns, not services. This will especially help sooner than later because if you need to rethink your system by keeping and remembering what your original idea was and what the actual intent was, this really helps in later stages to modernize the thinking.

What we told you is maybe something you already knew. What we told you is just do a good job as an architect, which means use proper design patterns, use abstraction where appropriate, and just stick to well-established good development practices like DevOps, agile, and designing lean products. By saying this, thank you to you. If you want to talk about flexible data and AI architectures, I am happy to have this discussion later. It is in the green area on the utility versus switching costs, so a very nice one, but there are still more dimensions. ECS may be a good option if you ever want to talk about these options.

If you have questions, you can come after the talk and we can discuss that. Do not forget to use the app and to fill out your survey. We really appreciate your data about that, and we can improve the sessions. Thank you very much. Thank you.

---

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