AWS re:Invent 2025 - Building Sovereign Cloud Environments (COP409)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Building Sovereign Cloud Environments (COP409)

In this video, Bo Lechangeur and Randy Domingo from AWS present the Landing Zone Accelerator (LZA), an open-source solution for building sovereign cloud environments. They explain digital sovereignty challenges, regulatory compliance requirements across regions like Europe, and how LZA uses AWS CDK and YAML configuration files to deploy scalable security controls across multi-account, multi-region environments. The session includes a deep dive into the codebase, demonstrating how LZA orchestrates Security Hub deployment through TypeScript modules and constructs. They discuss the Universal Configuration aligned with frameworks like NIST 800-53, GDPR, and C5, and address customer questions about sovereign cloud partitions, migration from existing environments, and organizational structure flexibility.

; 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 Digital Sovereignty and the Challenge of Cloud Compliance

Good morning, everybody. We are here today to talk about how to build sovereign cloud environments. I'll introduce myself. My name is Bo Lechangeur. I'm a Principal Engineer within Amazon Web Services. To my left here is my colleague Randy Domingo. He is a Senior Software Delivery Manager on the team. So today we're going to introduce the concept of digital sovereignty, and really this is a code talk. We do want to talk about the problem statement at first in terms of what digital sovereignty is, how customers are having to address this, and the challenges that they see from a global perspective. This goes into really what is the choice around controls that are adoptable for you as an organization and what they're doing. Then we're really going to touch upon how AWS is taking this approach and how to approach it from a sovereign cloud perspective, and then how the Landing Zone Accelerator on AWS, the solution that Randy and I manage with our team, the concepts that we've taken utilizing the AWS CDK will go low level in terms of how we're addressing these challenges for large scale customers.

To understand digital sovereignty again, it's very important to note that a lot of times customers and organizations coming into AWS, as they're bringing their business into AWS, they're having to manage large swaths of data. In today's time, the landscape is always evolving from a regulatory perspective at a global point. We see a lot of regions, especially in Europe, where the regulatory compliance is changing at a very rapid pace, so customers are not just having to manage their own security standards that adhere to their business needs, but they're also having to adhere to regulatory compliance needs as well. So from that perspective, as you're managing your data, you need to understand from a learning perspective what controls are available to me, how do I evaluate my threat model in my environment, what controls are there, but I also need visibility into my environment as well. That's where customers want control over their digital assets and how to really manage that data in the cloud. They want that control and choice of which prescriptive controls they can use to safeguard that data from various scenarios like data exfiltration, while still having that technical autonomy, so they're not essentially restricting themselves from innovating in the cloud.

As we start talking about sovereign cloud, I did mention that customers are operating in various regions. Sometimes we have customers that are US based. You have other enterprise level customers that are more scalable in the sense that they have a more global presence, and that's where it gets really interesting from an enterprise environment in terms of how we're layering controls, how we're allowing different segments to talk to one another. At the same time, as part of the shared responsibility model, customers need to be able to control their data and have the choice of how they secure and manage that data in the cloud. So from that perspective, we want to give customers the flexibility in determining how am I layering on my preventative control layer, how am I handling my detective control to gain that audit and visibility into the AWS ecosystem so I can ensure that I have a strong security posture in the cloud.

So what we've seen with customers as regulatory environments evolve over time, customers are concerned. AWS, as we want customers to bring their business into the cloud, we constantly preach the ability to innovate and move faster. But as we've seen, Randy and I many times, customers also have to understand how can I ensure that I have a strong security culture, right? And that's where customers are having to lean on, can my environment operate within the AWS partitions where I may be able to take full advantage of all the services and capabilities that AWS provides, or do I need to go into a more sovereign cloud perspective where I may be more restrictive, and we're going to talk about that in a little bit. But customers should have the ability to choose, and I think that's where we talk about the digital sovereignty pledge. The AWS landscape, if you keep up with our services, we're rapidly innovating and providing more choices for our customers. For example, over time, one of the big pain points for customers was VPCs and understanding within my network what did that traffic look like in terms of having a centralized view, and then recently we enabled VPC encryption control, so being able to see at a centralized view what plain text communication is going on in my environment.

Customers want to be able to take advantage of more prescriptive controls like that and understanding where the threats are in our environment. That's part of the pledge, the ability to continue to evolve our services and make them stronger for customers to operate in the sovereign cloud partitions, where we provide existing capabilities and really expand upon that. That way they can continue to build regardless of the access restrictions that they can still apply to their workloads.

We also talk about generative AI, which everyone is aware is now a thing that has been brought into the landscape as a technical stack. It introduces from a security perspective a lot more challenges that business leaders, including CIOs, need to be able to understand. How can I maintain that level of innovation but at the same time ensure that our security posture is still strong with AWS? I've delivered with a number of customers across a large number of verticals, and Randy has as well across a variety of industries, some very highly regulated.

Platform Readiness: Integrating AWS Services for Security and Compliance

As we start talking about platform readiness, you see a lot of these AWS services here, and they all play a key part. There's no one service to rule them all. I can't layer on networking controls and ensure that that's also going to provide identity access management. The idea here, and this is where our Landing Zone Accelerator solution comes into play, is to kind of stitch all these elements together. At the same time, we're ensuring that we are identifying and reducing security risk within our ecosystem, protecting networks, and safeguarding that data, preventing various scenarios like data exfiltration, especially when we start working with highly regulated data. If you're working in various regulatory frameworks as well, that's a typical nightmare scenario that you need to always safeguard for.

This is a lot of compliance requirements, but from the AWS lens, I think we're up to 143 security standards and compliance certifications that AWS supports. Some of the popular ones that you may be familiar with are FedRAMP, GDPR, HIPAA, which are very common. NIST 853 is widely used amongst a lot of customers as well. This is kind of a large scope of what LZA, the solution, is trying to do in terms of deploying these scalable controls within your ecosystem, especially as you start to scale out your environment.

This is where we're going to start talking about the Landing Zone Accelerator itself. I've kept mentioning security compliance and regulatory frameworks that customers are having to adhere to, and that's also just the base layer where customers still need to adopt their own security controls that don't fit within that framework to better safeguard a lot of our digital assets, especially when you start working in a lot of highly regulated environments. Those environments are where the LZA solution in and of itself was built from, where we designed it to be open source. This gave us more feedback from the overall community in terms of making sure that we have the most secure solution possible, where we operate beyond just the normal partitions but operate in GovCloud and other partitions as well for those really highly restrictive customers that have deep security requirements.

The idea around the LZA is that we wanted to provide a really balanced approach focusing on extensibility, visibility, as well as modularity within the solution. Randy will kind of touch upon that a little bit more as he starts really deep diving on the solution itself, but it's a model configuration that we've seen a lot of customers use within DOD, NATSEC, a lot of our public sector customers, and even venturing into the private sector from a global perspective. We definitely leaned on, or LZA rather leaned in heavily on the AWS Cloud Development Kit, the AWS CDK, for a lot of that dynamic provisioning that you'll kind of understand how we're utilizing that base technology.

Landing Zone Accelerator on AWS: Architecture and Universal Configuration

The LZA solution is tied fairly closely with AWS Control Tower. From that perspective,

when you are operating and establishing your own landing zone and layering on your own prescriptive controls in terms of how these controls adhere to your business needs. LZA with Control Tower is something that we highly recommend for all our customers to use, understanding that AWS Control Tower, when we start talking about those sovereign cloud partitions, is not available in some regions. That's where the modularity component comes in from the LZA side, so you're still able to take advantage of LZA and all the governance resources that we can provision in your environment.

As we start talking about platform readiness, there are a lot of design choices that come into it, such as how I'm layering on my preventative controls where I take advantage of organization policies like Service Control Policies and Resource Control Policies. How do I prevent data exfiltration? Do I prevent these workloads that are meant to be isolated from VPC peering or internet gateway attachments? Do I want to make sure that my network traffic never leaves? You start taking a lot of these security concepts like incident response and identity access management, and that's where you kind of see how all these elements in their own security pillar are stitched together to maintain that security posture within AWS.

That's also where Randy and I developed the LZA Universal Configuration. To give a level of abstraction here, LZA is a solution that utilizes the CDK. It is dynamically provisioning out your environment based on your inputs. The configuration is a prescriptive guidance, and we'll go into some of the security workbooks that we've developed to frame against various compliance frameworks. When we initially designed this, we essentially wanted to have a global representation of regulated customers.

As the LZA is a globally adopted solution that we've seen in ANZ, EMEA, and North America, we've had to ensure that we had security compliance workbooks that map to those respective frameworks like GDPR, C5 in Germany, and NIST 800-53, which is a widely adopted framework as well. We really wanted to make sure that we had a support model that continuously iterates on this, and Randy and I will be able to provide those links for you to consume. The Universal Configuration in and of itself is based on our Well-Architected Framework as well as Security Reference Architecture to ensure that we're maintaining that strong security posture, aligning those controls to those regulatory standards.

We've also, if you take a look at it, incorporated networking, which starts to become important. There are various WAN patterns that are supported in the LZA, and we do have various network and security profiles based on what your use case is. Not every customer is the same. Customers have various business challenges and security challenges that they have to address, and that's where we wanted to provide options for customers where they can still take advantage of that industry and regional guidance packages as well as the extensibility layer that LZA provides when you start talking about various ISV products.

Customers coming into the cloud may be very strong in a particular technology that they want to lean on in the cloud. As they have to come in with tight deadlines, they want to still lean on that service capability to ensure that they are maintaining that security posture within AWS. The LZA, from what we've seen with customers, has been transformative. I started in AWS back in 2016, and I've been doing landing zones with customers since 2017. This used to be a very long process, and a lot of that time, once we got a picture of what the landing zone would look like, the development phase came in. That's where LZA is really trimming that development timeline down. We're taking care of all the orchestration elements for you so that you don't have to.

That's why we've started seeing the global adoption of LZA in and of itself, where we can lean on it for Greenfield customers in highly regulated industries and provide that multi-account structure that is really needed. Even from a small environment, customers have to be mindful of their disaster recovery or business continuity planning requirements that would necessitate them operating in a multi-regional landscape. That's where you need to start having those scalable controls in place.

So I mentioned some of the workbooks as well. You'll find these workbooks in AWS Artifact as part of the Universal Configuration, and how we've architected and designed the Universal Config that is up for public consumption as well. But this is just a snippet again of NIST 800-53, which is widely used in terms of from an auditor perspective. They'll want to see in your environment how you're handling this particular control, whether it's at a preventative or detective layer, understanding how to respond to incidents. That's where the LZA comes in for you, and at the same time we've layered on those controls to at least accelerate that ability to maintain compliance within your environment.

C5 is another one that we've seen from a regulatory perspective, especially out in Europe, and that's why the European Sovereign Cloud has come about. Their regulatory frameworks are changing very, very fast, and it's very difficult for customers to keep up with those changes and at the same time adhere to those compliance regulatory requirements. So from a usability perspective, and then I'll hand off to Randy to talk more about the LZA solution. It is open source, so as you're using the LZA solution, you can reference our implementation guide, install in your environment wherever you want. You can file feature requests, issues, anything related to the LZA solution, and our team will see it and interact with it. By default, there is a lot of extensibility and feature availability for the LZA solution by way of YAML configuration files. We wanted to make that user experience very seamless where you're not having to understand AWS CloudFormation at a deep level. We want to give you a YAML configuration where we're taking your inputs and we're ingesting that into the LZA engine, which is using the CDK. From there, as we're taking your inputs, we're handling that multi-account, multi-region scalability for your controls. So that's it at a high level. Randy, I'll leave it to you.

Deep Dive into LZA Code: Security Hub Implementation with AWS CDK

Thank you. All right, so I'm actually quite excited. This is a code talk, so I get to really dive into the code a bit here in the LZA. I'm going to start kind of high level and we're going to work our way through an example of one of the configuration options that the LZA allows you to do. Specifically, we're going to be setting up Security Hub through the LZA. I'm going to kind of go through how it's normally done and some of the orchestration steps, how we configure it through LZA, and then we're going to dive into the code base.

The LZA, like Bo was saying, is open source, so there's obviously no secrets in the magic that we're doing there. But one of the things that we don't get to do often is really walk through how we're utilizing the CDK to be able to touch all of the accounts and regions within your environment here. This is a pretty kind of standard setup. This is the account structure that we have within our Universal Configuration, so kind of a standard security OU with a workload OU here. We do break it up generally within our dev, test, prod OUs, but here just a generic workload OU, and then our management account is our root account here.

When we're setting up Security Hub and we want to set that up across the whole entire environment, we need to of course make sure Organizations is enabled. And then from that management account, right, or root account, if we wanted to be able to delegate and configure Security Hub into a security audit account or security tooling account, we need to enable it in that account and pass the delegation over to it. And then finally, once that delegation has happened, we want to also ensure that all of our workload accounts are configured so that way we also have situational awareness of what's happening in those accounts.

And then finally, if you've used Security Hub, there are some frameworks that do require some Config metrics and alarms to be in place, logging events like CloudTrail feeding it in, so that way it could help identify findings and configure it. So again, pretty standard architecture here for many of the AWS security services that you want to have delegated over to a separate account and then enabled across your whole entire environment and then across all of your regions that you have enabled. But you'll see, right, so six steps here to be able to get that done if you were kind of going through the console.

So in the LZA, as Bo was talking about, we use YAML files to be able to describe the environment.

In this case, what you'll see is the top level here. The delegated admin account we want it to be our audit account. This is just setting up one standard, the foundational security best practices, and then you'll see the series of config rules and metrics and alarms that we have configured as well. So if you're familiar with the LZA and have used it before, this is in our security config YAML. These are the inputs that go into the LZA to be able to then drive the CDK engine.

The net result is that you end up with the CloudFormation templates that will deploy out all of those resources. There are about 14 resources just to be able to enable all of the architecture elements that we had in the diagram before. What this doesn't take into account though is all of those orchestration steps. The Landing Zone Accelerator also has a deployment pipeline with it, and it understands the A, then B, then C orchestration and dependencies that need to be done, and what stacks need to go when.

Working our way down now, again like I said, the LZA is an open source project. That QR code just goes to our GitHub repository if you wanted to go in and look at the code there. That's where our documentation is, that's where we take intake from our customers, and that's where we put out different roadmap items and issues and our release notes for our solution. The way that our monorepo is broken up, it is a TypeScript project. We are using TypeScript because it is CDK. We are exercising the CDK directly, so we just wanted to stay very tight and close with the way the CDK project is built.

There are four major modules or packages within our monorepo. We have our top level accelerator project that has our top level CDK application and all of the different stacks that are represented when you deploy out the LZA. We have a separate config package because we share that across our code base, so we just leaned in on code and had it as a separate library. Then same with the library approach, any of our custom constructs that we're building, again, we want to stay very close to the paradigm that is CDK. So again, you have your stacks, and then the stacks utilize constructs. Those constructs represent collections of CloudFormation objects or resources that you want to have deployed. So any of our LZA specific ones we keep in our constructs library.

Finally, we've extended out a little bit past the CDK and we've been building out a module library as well. These modules can be used outside the LZA. They can be integrated, but what this allows us to do is a lot of the things that we're historically doing in custom resources, we're starting to move those over into modules so we could just call the APIs and the service clients directly.

We're going to get into code, and all code and design documents start with the flow chart. Here's the call flow for what we were building out earlier with the Security Hub use case. It is a CDK application and it all starts from our accelerator project. From the accelerator package, we load in our configuration. We ask the config library to load it for us. It does some initial validation checks to make sure that the syntax is good. After that's loaded, we start working through each one of the stacks that we have as part of the solution.

That then goes over to our modules. We have moved, again like I was saying, some of our items that we had in custom resources, we're just calling the modules directly now. One of those are, for example, setting up our Security Hub frameworks and just ensuring Security Hub is working. Then finally we start really getting into the meat of the CDK project, or the CDK stack here, and in this case we're building our security resources stack. Our security resources stack has the config rules, the metrics and alarms, among other security service related resources that are in there that it deploys. Those constructs and those libraries, if they're from our custom constructs library, we'll fetch them out of there, but then when we're able to use the ones that are resident in the normal CDK project, we'll utilize those as well.

Technical Implementation Details: Stacks, Constructs, and CloudFormation Generation

I'm going to start working our way down. We're going to look at the code a little bit. This is our create security resources stack.

An important callout here is that we have built the Landing Zone Accelerator to work in every commercial region as well as our non-commercial regions and other partitions. A big part of our code from day one was ensuring that we are writing region-safe and partition-safe code. So if you're in partitions like GovCloud or other regions like that, the LZA will work in those environments.

This specific stack demonstrates what's great about CDK, which is that it allows us to write higher-level logic. We can understand whether or not the stack should even be included or built out as part of our deployment engine. In our pipelines, what you'll see is that we have the orchestration where we're doing our organization steps in one stage, we're doing our security resources in another stage, and we're doing our networking in yet another. We verify at each stage that we are deploying the right stacks that are needed there. And then lastly, if you're familiar with CDK, it's just a pure invocation of our security resources stack. So we instantiate that object, we pass in the descriptions, and we have our own specific synthesizer that we're building. This allows us to deploy and synthesize multiple stacks at one time. We are really trying to take advantage of the compute that we're on to be able to generate all of the hundreds or thousands of stacks that we'll have to deploy across the environment that you may have.

So let's double-click into what that security stack actually looks like. We're trying our best, and we know our code is open source, so we know that we have customers and partners that are looking at it, so we're trying our best to keep it as readable as possible. This is a literal excerpt of that construct constructor within that stack. You'll see that we try to encapsulate the smaller pieces into functions. This has made it easier for us to test because we can test each one of these functions at a much smaller micro level. And kind of the theme of re:Invent this year, it makes it a lot easier for our AI tools to be able to better understand the code that's there. So we're leaning in and using tools like Amazon Q Developer and all that to be able to help us evaluate some of the code and help author it.

Let me click in a little bit further. We're looking at setting up the AWS Config rules here. This is the create AWS Config rules function, and you'll see in that YAML file we had a list of rules that we want to deploy, and this is pure serial logic that we get to take advantage of because we're inside CDK. Again, other solutions like CloudFormation are great, however, the reason we have CDK is so that we can make a little bit more logic-based decisions as we're deciding what resources we can put in our stack. CloudFormation does support logic, but if you're familiar with it, this is a lot easier to express when it's written as code here.

As we work through that list, we're able to see whether or not the rule is a custom rule or if it's one of the regular managed Config rules, and we just pass that on over to our constructs library or the standard CDK constructs library to instantiate and build out those Config rules. And then, you know, the other features that we support with Config also support remediation. So if you have custom remediations for any of your managed rules or remediations for any of the rules that you define in general, we would be able to deploy those there.

And then finally, one of the big callouts here is that this is a CDK project. It is ultimately CloudFormation that's generated at the end. With the Landing Zone Accelerator, we're able to determine all of the dependencies that are happening with resources that are above it. In this case, we know that we can't create our Config rules if we don't have the Config recorder enabled, and the Config recorder is also deployed in the stack, kind of north of the function. But we have to set those dependencies to ensure that the Config recorder is generated before any of our Config rules are created.

The same is true all across the board for many of our stacks within the Landing Zone Accelerator. One of the value adds that we have in there is to really make sure that it's able to handle those dependencies. And then finally, what you'll see is the CloudFormation that generates it. Those are the CloudFormation templates that are generated by the CDK.

We talked about this a little bit earlier as far as how we build these environments, the definitions of what good looks like for environments, and how to be able to go in and have these secure environments. We touched on this a bit with our universal configuration, but these links here are to two sites. The first one is a blog that goes into a lot more detail about what we're doing from a digital sovereignty perspective, utilizing the Landing Zone Accelerator. The second one is our universal configuration for the LZA. What you'll find inside that GitHub repository is not just the configurations themselves, but the documents. We try to really go into detail about the rationalization and the reasoning that we had, like why our OU structures are the way they are, why we chose certain Config rules, so a lot of the reasoning behind the decisions that went into that architecture. This gives you the information needed when you go look at our compliance workbook, which is an artifact, and look at it more from the control's perspective of why that Config rule was added or why that SCP was added.

Q&A Session: Sovereign Regions, Migration Strategies, and Organizational Flexibility

Lastly, I'm going to go back a slide here because I wanted to get through all that because I know there's going to be questions and we want to leave room for questions. We're part of the Cloud Ops talk track this year, so come check out the kiosk. There is swag there. I'm going to go back to this because I saw people taking pictures there, but I'm happy to answer any questions that might come up. I'm happy to discuss the LZA in general and then how that fits in with the use cases that you all have. If there's any questions.

That's a good question regarding data. Sorry about that, it's about the launch of the AWS European Sovereign Cloud. Yeah, I'll try to repeat the question here. So once the sovereign cloud region is launched, will I need to deploy two LZAs, one in our global regions and then one in the sovereign regions? Did I capture that correctly? Yeah, so the answer there is, depending on when we talk about the sovereign regions or we talk about even our commercial regions and you're building it out there, you can deploy your LZA today to be able to build, specifying the region that you want to have it deployed in. As we start expanding out and we start talking about separate partitions that are not part of our commercial region, those don't have any connection points between each one of the partitions. So that would be a separate instantiation or a separate landing zone that you would be building out because the best way that you would think about it is even if you're doing this in commercial regions, you're going to have two separate organizations, you're going to have two separate management accounts that are there. And then that affords you the opportunity to decide. Like some customers want to just stay within that sovereign region, or if you have use cases or compliance requirements to be able to utilize both, then you would have both of those environments. Okay, yeah.

Any other questions? When will LZA support, I guess the question is about when support is coming. Are you talking about the features of Security Hub or the Security Hub frameworks? The new service, the CSPM. Yeah, we've definitely received market signal from customers. One of the feedback mechanisms we have since we are open source is we see it internally and externally, so I think we're aiming for second half of, no, not second half, second quarter of 2026 right now on our roadmap for that service.

Oh yes, you. So for the module input, it's basically all the YAML files populate how it's going to lay out. Yeah, and to me that screams kind of with all the AI talk of some sort of an agent to help guide that input. Do you see anything like that on the roadmap? Yeah, I think it would be. So the question is, with the YAML file and the editing of it, and you know, definitely all the talks of agents and AI tooling that's out there, how does that relate? I think it's safe to say that we are leaning very heavily into the AI space. So when we're talking about MCPs and ensuring that the structure of our YAML files is amenable to those tools, we're very much looking in that space. So yes, the LZA is definitely moving towards that direction, hopefully more information to come very soon on that.

Cool. Question up front. Yeah, I'm just wondering, cloud migration or implementation, so probably not a lot of organizations here that are greenfield. We already have lots on. It's hopefully already in place. Have you had contact with customers that have moved to this? Yeah, yeah, so the question is around migration. So yes, we've seen a lot of customers that have already existing landing zones, existing organizations, right, existing resources that are already deployed within AWS, and how can they go take advantage of the Landing Zone Accelerator. There's kind of a few approaches that we've seen, some like all the way from one spectrum where customers are looking at it as an opportunity to go retire that environment because it was kind of stitched together and be able to go migrate those workloads over. So treating it as a greenfield. And then we've also seen customers just piecemeal utilizing, let's say the security services of the LZA, right, to be able to go in and take advantage of your Service Control Policy management and your security services that are there. And just, you know, once you have production workloads and your networking is pretty set and all of that's pretty static, like you tend to not want to go touch that.

That being said, with CDK and CloudFormation allowing resource assumption and management of existing resources, that is something that we're looking at to be able to go allow imports into the LZA of existing resources so we can go interact with them and start managing them going forward. It's also a focus of kind of our modules here to be able to go understand what has already been deployed in an environment like Security Hub and then looking at the configuration that's provided, be able to go then shift it to that manifest, if you will, right, that explicit I want it to be able to go look this way, so.

One more question. Sure, so how strict organizational structure and your own structures. Yeah, so the Landing Zone Accelerator is broken up into, so the question was how strongly do customers have to adhere to the organizational structure and account structure that's within the Landing Zone Accelerator. So the LZA is broken into two parts. One part is the deployment engine. We kind of went through the code base a little bit of how that works. And then there's a configuration that you feed it, which we have within our, like for example, our universal configuration. The engine itself will deploy out whatever you tell it to deploy through the YAML file, so you can tell that I want this organization structure. I want these accounts that are deployed out to these Organizational Units. You're very much in control of what's there.

However, when we're talking about kind of highly prescriptive environments and environments that are really, you know, kind of taking advantage of a lot of the compliance work that we've put in, that's why we built out the universal configuration, right, to be able to be a lot more, this is how we would build an organizational structure with the controls in place, with the Service Control Policies in place, if you wanted to be able to go quickly hydrate and stand up in the environment today. So, long-winded way of answering your question of, you can ask the LZA to go deploy whatever you want. However, we have opinions about what you should probably go deploy based off of our Well-Architected frameworks and our security reference architectures. Yeah.

Any other questions? OK. So Bo and I will obviously stick around for a bit. I'm happy to kind of dive into kind of more details on what is in the Landing Zone Accelerator and kind of what we're doing, especially within the sovereign region space. So if there's any other questions feel free to kind of come by. We'll hang out outside and obviously in here for the foreseeable time, but yeah, if you have an opportunity again, the Cloud Ops kiosk is in the village. They have swag and demos and and workshops that are available that's over there, but yeah, I appreciate you coming and taking the time to hear about what we're doing.

---

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