Optimize costs in your multi-account environments

All right, let's get started. Um so we deal with costs every day and costs make up a major factor whenever you're making a purchase for a product or an item. But it's not the only view or angle that you'll take. When you purchase a product, you also have to consider the value and the benefits that you receive from a product.

So let's take a simple example. If you're purchasing a place to live, you may consider a large house out in the countryside, maybe it's a three bedroom place with a large yard or a small one bedroom apartment in the city that's close to your work, but it's really going to depend on what your needs and wants are.

Similarly, when you're thinking about reducing costs and driving spend down for an IT organization, you want to do so while maximizing the business value for the organization. And in order to do that, you need to know what's within your environment, what are the resources who's using what and the impact on the business.

And so in today's session, Andrew and I are going to share some of the best practices and techniques that you can implement for a cost optimization within a multi-account environment.

So when you start on AWS and you start your environment, this might be your cost view. It might be pretty simple as you add additional instances, resources, storage resources, services for visibility, it can be sort of clear how your environment is growing or how your costs are growing on any sort of week, over week or month to month basis. You're seeing those changes and you're kind of aware of where they're coming from. It's might be, it might be clear within your, your bill from your single account, why it's going up on any given week or month.

Now, you might add additional accounts, you might add additional teams, new applications, new services. Um and it can be a little bit harder to understand where your costs are coming from, like, you know, they're going up, you know, that your costs continue to increase. But in terms putting your consolidated bill might be like an index fund. You weren't entirely sure what is happening that's causing all those costs to go up.

Um and then you really know you're in trouble when uh there's a couple of interns who have kicked off a few graviton instances because they hear that, that Gen IA i is the next big thing and they want to build a new model. Now, there's a lot of excitement for Gen AI and I do think there's a lot of promise with it. But you sort of realize at that point in time that you might want to put some cost controls in place, you might want to allow that to happen, but only in a, the controlled environment that it is built for that purpose and not necessarily for someone who's just kicking the stones and seeing what's going on.

And so that's exactly when you're at this point, having that cost, visibility and those introspection and those controls in place or what can help you to manage the cost in the environment where it's not quite as clear what's going on where you know, the costs are going up, but you don't exactly know why, but you can build those cost optimization patterns within your environment so that you can better control how they're going up and making sure that you're getting the value out of the services that you're using as Novos has mentioned.

Now this isn't just you in this room, there's a number of different customers who have gone through the same growth realized that they were at a point where they didn't know what visibility they had, they didn't know what use resources are being utilized um and they needed to implement cost controls. So there's a number of customers as in, for example, Lyft Wildlife Studios, a number of them achieved a large cost savings mainly by having better visibility of what their costs were being able to share the cost visibility with the teams that they were working with helping them to start to own their own costs and then implementing measures to control the cost within, within their environment.

All right. So we'd also like to acknowledge that within the audience, we likely have different personas, different personas mean that there are different perspectives for how everyone approaches their cost optimization strategies.

So we'll start with the engineers and developers, the engineers and developers are typically asking themselves how can they ensure that they don't go over their budget limits? And this is extremely important when you're dealing with the cloud where you have nearly an infinite amount of compute resources. The second engineers are also looking to see how they can provide more efficient processes through automation.

We have often heard from customers where their development teams are struggling to provision resources and it's taking months or weeks of effort because they have to read lots of documentations and engage with multiple teams for review cycles and then you have your center of excellence teams, your financial operations teams. They're very interested on understanding what each team is doing so that they can calculate the return on investments and whether the IT services are actually having a positive impact on the business.

A key feature of these teams too is that because they're looking across the board across the entire organization and the multi-account environments, they can actually identify opportunities for the use of common tools and services. This could be networking services security services and others.

Um we have also seen these teams limit and reduce the number of shadow IT tools because anytime you have shadow IT tools, this is ends up being a security risk as well as it is somewhat expensive for the organization.

So we're going to talk about how to manage costs across accounts and Andrew and I decided to try and keep it as simple as possible. We broke it down into three stages. The first is understand and plan. And in order to do that, we first have to set up the multi-account environment with a solid foundational structure.

Once you have this foundational structure, you can implement your cost analysis tools with the cost analysis tools. This allows you to visualize and measure metrics from which you can then take certain decisions and the these decisions will allow you to implement cost controls across your multi-account environment.

And if you look at the slide, you can see the arrows, it's it's circular in motion. And this means that as you progress in your cloud journey, it's not going to be a one time effort as your business grows and scales, you'll be continuously looking to see how you're managing costs and evaluating the controls in your environment.

So we start with our very first stage, the understand and plan and we start quickly with a couple of fundamental concepts. The first is start with your business objectives. Organizations are looking at generative AI tools, they're looking at analytical tools, they're trying to scale out to new markets and regions to increase revenue, they're building out new products and features. And it's very, very important that you pick and select your technology tools to support the business objectives of the organization. And um this will help you accelerate the innovation across the organization.

I think one more point that I'd like to add here is sometimes we have seen organizations implement a cost optimization strategy that is a little too restrictive and that's not the intention we want to implement controls. But then at the same time, allow the teams to do what they need to do to achieve the business objectives.

And then the second concept is the use of AWS manage services. AWS has released over 3300 significant services and features since 2022. And yes, this number needs to be updated. But the point is these services are purpose built. They provide you with the tools for the job and will help you achieve performance scalability, reliability and more.

We also have thousands of integrated software vendors available from AWS marketplace using these tools, services and products. You can accelerate the experimentation and innovation that your organization executes versus having to build these solutions from scratch or custom. It's a little bit more expensive in the long term if you'll have to maintain this for the long term.

And so as we go through this session, we're actually going to touch upon the four different categories here, talk about some of the managed services that you can implement within your environment.

The last part of understanding and planning is making sure that you build and understand how you want to build your environment on AWS. This will come, this will be important as you get to the point of where you're implementing controls within your multi-account environments.

So as we talked about services, there's a couple of services that I assume you're familiar with if they're not familiar, just to give you an explanation. AWS Organizations allows you to have multiple accounts under essentially a single entity or an organization. Um the benefit of this is you can manage these accounts across your organization. You can add permissions and manage permission essentially.

Um and there's also a cost that all the cost of the accounts are consolidated into a single bill. Now, this for cost savings. If you're utilizing a number of different resources and the resources offer a volume discount because you have a singular bill, you can achieve those volume discounts by having everything under the hood.

Now, AWS Control Tower, if you're not familiar with it, it's built on top of AWS Organizations and it's meant to help get you to a best practice multi-account environment on AWS, sometimes known as a landing zone.

Um so there's a number of things to set up that we're gonna talk about today. Um Control Tower automates a lot of these best practices when you start your environment or you add a Control Tower on top of the organization that you've built.

Now again, I'm I'm assuming you have an organization, but I want to make sure that everybody in the audience is level set with what elements the organization has that will become important as we're talking about implementing controls.

So quick recap is your management account, manages the organization. It's the administrator account, the organization, it's where you're going to enable services and apply policies.

Organizational units are essentially units that are made up of accounts within your organization. It's the structure of the bones of your organization where your member accounts will live. And that's again where you will apply policies and manage services and then the member accounts, all of the accounts that are underneath and within your organization.

Now, this is an organization structure that we recommend for all customers. If you don't have a specific structure built, keep this in mind if you do have a structure again, I'm making sure we're all on the same page as we start to talk about these controls and where they're being applied within this best practice organization.

First and foremost at AWS is security. Your security account should be managed within a security organizational unit. The sandbox organizational unit is where you'll have accounts for your developers to learn and test things out in a safe environment, disconnected from your network this is where you might want to consider some budget limits and being able to pay attention to what costs are being drummed up in that sandbox organizational unit.

And as I mentioned, Control Tower before, if you enable Control Tower within your environment, it sets up these two organizational units for you. So it gives you that basic structure utilizing these organizational units.

The infrastructure, organizational unit is where we suggest having your operations, teams and your sort of central IT services accounts that are managing the backbone of your organization.

And the workloads OU is likely where you're gonna have a lot of your costs because that's where all of your production accounts, your production workloads as you add applications and services. That is where most of those accounts are going to reside within your workloads, organizational units, you can have OU to separate your production sandbox, your production and development environments there.

Um but this is where you might have a lot of cost introspection when you're trying to tackle those costs, you know, within your workloads organizational unit.

So to quickly recap, it's important that you understand your business objectives as you approach cost optimization so that you make the right decisions about where you want to tackle costs. I know it's basic, but it's important to be sure that you're being very prescriptive on how you tackle this.

And then the second is establish the structure for a multi-account environment because that's where we're going to be putting cost controls and getting insights based on how your environment is set up.

So this brings us to our second stage to visualize and measure costs. We have set up the foundations for your multi-account environment.

And now we're going to talk about a couple of best practices for implementing cost visibility.

We'll first talk about how to set up cost tools and the permissions needed with it. And then the second Andrew is gonna cover the multi-account service features that are natively integrated with the services.

And we start with something that I believe most folks might already know - it's consolidated billing because we have set up AWS Organizations. It's very important to set up consolidated billing because this gives you one single invoice for the organization to pay. And it also lets you have visibility into the spend and costs within each member account.

And if you're using Savings Plans and Reserved Instances, this also allows you to benefit from the shared volume discount model. And you can set this up within the management account of the AWS Organizations.

And then because you're having multiple teams and your financial teams, it will also be important to set up billing only permissions. And this means that you'll need to follow the principle of least privilege - meaning you might be providing only read only permissions to a select group of individuals within your financial teams or you may decide to export a subset of the data to another account and then let the financial teams review it.

And we have a couple of cost analysis tools within AWS. You can use Cost Explorer, which will provide the cost and spend for individual services as well as the member accounts within your organization. It's simple and easy to use and it's automatically available.

The second is the Cost and Usage Report. What we have found is that most of our organizations like to have a deeper overview and gather the details of how each service is being used. And this allows them to build out custom dashboards and custom queries. So it's a little bit more flexible than what you would get with Cost Explorer.

So with the Cost and Usage Report, you can also call APIs so that you can create reports, you can delete a report and retrieve reports. It's quite simple to set up within the management account and it will save all of its reports over to S3 within the management account.

You'll need to make sure that there is proper versioning so that you're not incurring extra costs with the Cost and Usage Report. And by setting it up, this will also integrate with Amazon Athena, Amazon QuickSight and Redshift.

In the QR code over there to the bottom right, you will actually see that it takes you over to a Cost and Usage Report library of queries. This should help you get started with running queries with your Cost and Usage Report. It gives you queries that you can run on analytics, ML, cost optimization queries and so on. You'll need to make sure that you edit the queries to be more specific to your business.

And the next step is to build a custom dashboard. And yes, you can build a custom dashboard from scratch based on the Cost and Usage Report or you can take advantage of a good starting point with the Cost Intelligence Dashboard that we provide. This can be easily deployed into your AWS environment with CloudFormation. And it's built on native AWS services that include AWS Glue, S3, Athena and QuickSight.

We have actually seen a lot of customers save thousands of dollars even from a simpler dashboard like this. It shares with you the monthly costs and it's really great to give a high level overview of your spend on AWS.

And then we also have multiple other Cloud Intelligence Dashboards. I'm not going to go through all of them, but I'm going to point out a few that I think you should be aware of - the Curious Dashboard.

And this one's going to give you in depth insights as well as recommendations on how you can optimize your resource usage across your multi-account environment.

The EC2 Dashboard will allow you to understand how you're using your On Demand instances and then give you some recommendations on whether you should be using Spot or Graviton instances.

And then we also have some other dashboards. When Andrew talks about some of the native integrated services, you'll notice that they provide similar recommendations. But the difference here is that these are custom dashboards and you can edit the queries and the dashboard to meet the specific needs of your organization.

And yes, the QR code over here takes you to the Well Architected Lab which walks you through how to set up each one of these dashboards and dives deeper into them.

And then for all of these organizations, we have to take into consideration the business organization and the perspective. And so this means that you will need to define cost categories. An organization may have multiple business units, might have multiple departments within the business unit as well as multiple teams.

And for financial operations teams, they'll want to understand how to allocate costs to each team and understand how the IT services are being used. The nice thing about cost categories once you define them is that they feed into some of our cost analysis tools which include Cost Explorer and Cost Usage Report. You can also split the charges across the cost categories.

We support multiple dimensions and I have listed out a few here - region, service and account - but you can use these dimensions to create, to group together. So for example, if you have 10 accounts that belong to a team, you can use that as a dimension to create a cost category called for the particular team.

Alright, we're gonna talk, we've talked about a lot of visual dashboards, but setting up your visibility is really important first step. So if you have that, that's great. If not, we've just provided a whole ton of different resources that you can investigate and identify where it works well for your needs and what your team's needs as well.

We're gonna talk about a few additional services that are specifically built to give you a multi account view and some of them specifically related to costs.

So there's a number of different services that are enabled with Organizations and it means that these services are able to see your organization, it sees your structure, it sees the accounts within your organization which will allow you to have a centralized view of findings across accounts. This is important for costs, but also important for something like security findings as well.

And it also can you can use them to ensure that standards and controls are in place as well across the services that you're utilizing.

So when it comes to setting up multi-account features in your organization, there's two steps that most customers should take, which is setting up the service for your organization. So in the management account, you kick off that service you say, I want it to be able to see my organization and then registering a delegated administrator account for management.

This goes back to ensuring the least privileges in your management account. Now, you can essentially delegate one of the member accounts in your organization the privilege to review the findings from the service to manage the service on behalf of your organization. That way your engineers, developers, dev ops, whoever it may be managing that service, they can go to their account to manage it for the organization as opposed to having to access the management accounts.

So again, it's something we recommend is you set up organization services is identify where within the organization they're going to be managed and then delegate the administration of the service to that member account so that they can manage it on behalf of the organization.

There's three different services we're gonna talk about today that are specifically built around cost optimization. So let's start with Compute Optimizer.

Now your compute resources might be the biggest thing on your bill. I'm not sure. But I assume in most customers cases that is the case. And Compute Optimizer is specifically built to help you optimize the use of your compute resources.

So because it's integrated with Organizations, it takes a look at the resources that you're using across your organization over a period of time and it can give you specific ideas or cost estimates and some optimization techniques that you can use to right size those costs or identify the biggest cause of inefficient use of computer resources across your organization.

So here's something you might see if you're in the console, you've set it up for your organization. You can see the instances you're using. You can tell if you're over, under provisioning them, auto scaling groups, Lambda. It covers all the different compute resources that you're utilizing and you can even get down to the instance level.

Again, if you can identify across your accounts, you can identify which instance has the biggest possibility of creating cost savings.

Now, we talked about your organization structure to bring you back to our operations or our infrastructure organizational unit. We recommend that there's an operations account within that infrastructure OU and that's where your operations team will review findings, manage Systems Manager and they can also manage the findings from Compute Optimizer within that delegate within that member account that's delegated as the delegated administrator for Compute Optimizer.

So again, if you don't have your organization set up, we recommend having an operations tooling account and we recommend having that be the delegated administrator for Compute Optimizer.

Cost Optimization Hub is new as of re:Invent this year, it was announced just yesterday. Cost Optimization Hub takes the findings from Compute Optimizer and it gives you further guidance around Savings Plans or Reserved Instances or further insight on how you can better optimize your compute resources instead of just changing instance types.

So it uses Compute Optimizer under the hood, but it can give you more billing specific recommendations.

Now, I mentioned that Cost Optimization Hub is a billing feature and given that billing is still in the management account, this is one where you want to set up, read only permissions for your the team who needs this information within the management account. And that should be the only thing that they have access to.

So since it's a billing feature, it's still in the management account, you can't delegate administration of it yet, but that is where it will stand and that's where you should again, make sure you have permission boundaries around it.

S3 Storage Lens - storage might be the other high cost that you have. It has a very similar function to Compute Optimizer in that it helps you optimize the use of storage across your organization.

So again, you have an organization wide view, a multi-account view of how storage is being utilized. It can give you a sense of what you should do with that storage.

It can even give you a sense of how to protect the storage as well. So not only does it give you give you cost optimization recommendations, it can give you security recommendations for your s your storage. This is something that you might see if you're using Storage Lens. It gives you a view of how much storage is being used over time. There's different tabs for cost efficiency and data protection. And again, that gives you that organization multi-account wide view so that you can dive in and identify cost saving opportunities across your storage.

Now, the two services that i mentioned before, we get to config the two services that i mentioned, they don't have a cost to utilizing them. They might have some costs for some of the insights, but to set them up and to set them up across your organization, there isn't a cost associated with them. So we highly recommend that even if you haven't explored it, you absolutely do explore it. It's something that you can do so at no cost and see what insights it gives you.

Alright. So AWS Config. We use AWS Config to evaluate the configuration of resources, identify the relationship of the resource to other resources. Um a lot of our customers are using it to track inventory across the multi-account environment and um as well as identify unused resources. So let me give you a few examples.

Um uh customers use it to identify unused EBS volumes, Elastic IP addresses and sometimes you can use AWS foot config to take it even further where as soon as an EC2 instance is terminated, you can implement AWS Config where it can modify the properties of the EBS volume and market for deletion. And then to ensure consistency across the organization, to ensure that all of your resources are following the cost optimized principles like an S3 bucket using lifecycle policies. Again, use AWS Config rules to identify where the misfigure are within your multi-account environment.

We offer a collection of Config rules which we call conformance packs and within the conformance packs, you'll find a group of config rules that can help you ensure that your environment is meeting some of the requirements around security, uh cost optimization, resilience and performance. And more, the nice thing about Config two is that you can feed in all of this information into CloudWatch S3 to to build out your own custom dashboards as well as store historical information on how the configuration has changed over time.

Here are just a few different examples. Genesis, which was very uh um concerned about how they were optimizing resource usage within their AWS environment was able to use AWS Config to detect and clean up unused resources. Netflix, which wanted to have better inventory management and have visibility within their environment about the resources used AWS Config to implement a more up to date inventory management tool.

So let's talk about the key takeaways of this very second stage of visualize and measure costs. The first was to set up the multi-account features for a w services for visibility and this is where we set up consolidated billing and andrew talked about the number of different services, this included the s3 lens compute optimizer cost optimization hub. And then the second is to use the tools to detect and enforce consistency. And here we're referring to AWS Config which you can use for inventory management.

Alright. So we have our environments, we've set up our plan, we know we want to tackle, we have insights that help us understand what we want to tackle. We have our dashboards and we have some services that are giving us insights. Now, let's talk about what we want to implement and iterate.

Now what you want to implement and iterate will be heavily dictated by what findings you have and what you're able to see in terms of where you want to tackle costs based on your business plan. So there's three different specific things that I'm going to talk about that are related to implementing elements within your multi-account environment that can help you to continually cost optimize over time. We're gonna talk about service control policies. We'll talk a little bit about tags and how they're utilized and how tag policies can be used as well. And then we also recommend self service well, architected patterns for resource creation, essentially identifying what is a cost optimized resource building that blueprint for any of your users or developers to use and ensuring that they only use that blueprint when it comes to adding new resources within your environment. Ensuring that you have the cost optimization in place on those resources.

Now, before we dive into a specific example, when it comes to approaching cost optimizations initiatives, you're working with teams, your environment is built that team in a way that teams are using it. If you're building a new environment where you know, teams are going to come onto it, they're going to come onto it when you've sort of built it out and you have everything in place. You can build these cost controls in place. Uh it's something new, you can ensure that everybody's on board. And then as they're adding accounts and resources, they're used to these cost optimization controls that you put in place.

If you have an existing environment and you're trying to put these in place, recognize that there may be some abrupt changes that will happen in how developers are provisioning resources, for example, or how they're utilizing the costs within their teams. So it's worth having an audit period or spending some time to help them get used to the warning signals of the actions that would potentially not be allowed in your better cost optimized environment. So you work with them and establish an audit period and then you start to implement those cost controls in place.

Now let's introduce how service control policies can be used as a cost control. If you're not familiar with service control policies at its core, you can control granular actions that take place within accounts across your organization, they can specific limit api actions within an account. So this is an sep example right here. It's a very basic example that says any developer who's working in an account where this sep is applied, they can only create a micro instance.

Now talking about organization structure is important again, because when you're applying policies at higher levels of the organization, they are being applied to lower levels of the organization as well. So typically you want to consider applying policies at that organizational unit level because that will dictate the actions that take place across the accounts within that specific organizational unit.

Um so something like a micro instance, sep would not be something you want to put at the root level because it would limit all your developers across your entire environment from kicking off instances that are not t two micro. Now again, control tower has a whole control tower library and they utilize some service control policies under the hood that are, they're called preventative control, preventive controls. So if you're using control tower, take a look at the preventative controls that they use. What's happening in the back end is seps are being applied to your environment.

So within our business objectives, we want our developers to have a sandbox environment where they can learn and grow and innovate. We've seen that in our sandbox organizational unit, there's some costs there that we don't necessarily agree with or we think that they might be too high for their use case. And so we've identified that that's where we're going to start to implement a cost optimization control.

So i'm gonna show you a demo of something that i recommend when it comes to implementing cost controls for your sandbox environment. Within this demo, we're going to set up budget alerts so that the accounts that are within the sandbox organizational unit are not going to be able to have costs higher than the budget alert that we set. And not only that, they will essentially quarantine the accounts and limit any actions from being taken again um within that account until the budget limit is reset.

So let me show you and walk you through what's gonna go on. So this is my organization again. I'm going to point out the sandbox organization unit is what i'm focused on today within the sandbox organizational unit. I've created some nested oues specifically for sandbox accounts that are ready for use. And then i'm going to have another ou for sandbox accounts that are used. This will come important because the accounts are going to be moved to that used account once they hit a certain budget threshold limit.

So right now, there's no accounts there, all my sandbox accounts are ready for use. Um and we're going to apply a service control policy specifically on that sandbox used organizational unit so that it will limit actions taken for any account that's there. So essentially any account that gets moved there, i'm gonna put a no access policy. So this is a simple deny star star any action i take will not be allowed.

Um i can see that this, this policy is something that i already apply to a different organizational unit within my organization. Uh specifically, it's in the suspended ou. So i have a queue of accounts that are used. I don't want them to do anything else. They're just sort of sitting there. So you can see that the policy has been applied there as well. But i want it to be applied to my sandbox use organizational unit because i'm going to use that as a cost control.

So let me go ahead and apply it there and i can make sure that it's applied to that organizational unit, which it is again, actions for any account there should not be taken. So let's jump into one of the member accounts and this will show how essentially a budget alert can be created. Um this is taking place in the member account. We'll talk at the end how you can do this in a more scalable way across your environment.

So i already have some budget alerts that have been set up for testing purposes. Let me go ahead and create another one. Now, this is gonna be a monthly cost budget. So essentially i'm setting a budget for my sandbox accounts, meaning they cannot exceed a certain threshold in any given month. Give it a name real quick so that i can make sure i pay attention to it. I'm going to set it at one cent for the purpose of this demo. Again, not something i recommend in a production sandbox environment, but just for the sake of triggering that budget alert early on, you can set it for services. I'm doing it for everything. This is the sandbox environment

So I just want a sort of a blanket setting and then I'm setting an alert threshold so that I can identify when that has been hit. So I'm setting, I have a shared account that I'm using my sandbox users are using so that when I happen to hit that budget limit, I'm aware that that has taken place and that unbox account will essentially be quarantined. I have an S MS notification. So that's what's going to be kicked off when I hit that limit. That will come important because in the management account, I want them to be able to see that happening and then take the action of moving the account.

Now, if you want to do this on an account by count level, I'm showing you here that there's additional, there's specific actions you can take that the budget alerts will do for you. You can attach a policy that denies any action. You can attach a service control policy to the accounts. You can also automatically stop the instances that are happening in that account. So essentially, once that budget alert is triggered, it will stop actions from taking place or apply policies for me.

I want to move the account to a different OU where the SAP is already applied. And that's my preference here. So back to my management account, I have an SQSQ. It's subscribed to that notification when the budget alert is being hit. So again, when an account hits that budget, I'll see an email SMS will be kicked off the queue will see that queue. And then with an SQS, there's a Lambda trigger that specifically will, will identify which account that notification is coming from. And then it just moves the account to the OU it, it moves it to that used sandbox OU so that anytime an account again hits that budget limit, it moves it to the sandbox.

So you and then at that point in time, they will be quarantined. There will be no additional cost coming from that account because it can't take any additional actions due to this Lambda trigger. So I've just hit my budget limit. I get an alert that tells me, hey, you've hit your budget limit that this is 100% of your threshold. So let me go back to that member account and I can see that it's now in my sandbox OU Lambda moved it to the right organizational unit. Um that's exactly what I wanted to happen, there's an SEP there. So let's go on the member account and see if I can do anything else. There's already some red boxes that I'm seeing across the console. Let's see if we can kick off a simple instance, more red boxes that doesn't look good and clearly at this point, I mean, even if I try to, I'm not able to kick off any instances.

So essentially, again, the account is quarantined and there aren't any additional costs that can be generated by this account. Um now you want to consider a process whereby the budgets will reset every month. Do you want to consider a process whereby they're moved back to the sandbox ready OU for developers to utilize? And because I'm talking about this in a multi-account context, it doesn't necessarily make sense for you to do this every time you create another sandbox account, you can put all this information in a stack set. You can apply the stack set to your sandbox organizational unit and then any additional accounts that you add to that sandbox organization unit as you have more developers or have need for more of those accounts, they'll have those same settings applied, they'll have the budget alerts applied and the notifications that you create.

And so again, you're, you've done this, once you've set up a stack that's set up on this organizational unit. So as you add additional accounts, they're all gonna have the same cost controls in place. So this is the type of thing that we're talking about when it comes to cost controls within your multi-account environment, identifying your business need that you have, identifying the action you want to take and then having your environment set up in a way that you can apply controls in that place that limits the cost over time.

Now, that was one example of an EP used as a cost control. Let's talk about a couple of other examples real quick. Just for you to consider implementation within the OU, you can limit the OU to only specific services that need to be utilized in that OU. So again, security services for the security OU workloads that you might have a broad base but only approved services that you recognize. But that's a version of which you can ensure that only the right services with the right costs are utilizing the OU that you have in your environment.

Regions have different costs. So you can use service control policies to limit actions and resources being created in only approved regions requiring tags upon resource creation will be important as we talk about tags real quick here, specifying allowed and sizes which we shared an example of in the slide before and then quarantining accounts, of course, to limit all of the actions in an account once it's hit a limit or once the account is suspended and no longer in use and waiting for a deletion again.

The Control Tower. Control Tower has a whole library of controls. Specifically, they have some controls related to costs or optimizing costs within your environment. If you don't use Control Tower, you can still access this information and and identify what Control Tower is doing and implementing it within your organization. If you use Control Tower, this is here to easily implement within your Control Tower environment that you've built on your organization.

Now, tagging strategies are an important part of cost consideration and cost visualization as well. If you don't have a tagging strategy in place for your resources, I highly recommend that you identify what that tagging strategy is. Identify the information you want to get out of your resources and enforce tagging on those resources as well so that you get consistent cost information based on the tags that you have on your resources.

So if you haven't identified a tagging strategy, take a look at this paper, build your plan around tag building tags within your environment and implement them on your resources. Now, tag policies is a number another organizational policy that you can apply to your environment to define which are the appropriate tags to use. Now, you want to pair tag policies again with service control policies because service control policies can ensure that tags are on the the resource before the resource is provisioned. So tag policies defines the proper tags. Service control policies ensure that tag is present before resource is created.

And then finally, eight of us config we mentioned before, eight of us config can help you identify the resources that don't have the proper tags and can help you to dive in and remediate those resources. So we spoke about different controls and now we move on to well architected patterns for resources and this is all about introducing some efficiency and productivity to your development teams.

Previously, we spoke about the controls to tagging strategies to service control policies. But what if the development teams could simply start off with a well architected and cost optimized pattern. And so what we've often seen with organizations, they've successfully built out a central library of infrastructure as code templates that they have shared across to their development teams.

So instead of um a data scientist taking weeks of effort to build out ac id pipeline, they simply start off with the pre approved and preconfigured infrastructures, code templates and launch a model building pipeline. Um so yes, like infrastructures code could be cdk terraform or cloud formation. A key tenant to remember here is that you have to ensure that these are repeatable use cases. It doesn't help if it's only a one off solution. And when you start building out these library of templates, you may iterate over it, maybe add some trackers and identify which templates are being used more frequently and decide to invest more time into that. But you should just get started with it the 2nd 3rd point here is the governed infrastructures code.

Here, we're referring to AWS Service Catalog and we're encouraging the use of self service across your multi-account environment. You can take a, a CloudFormation template, a Terraform template and build it into a Sage uh Service Catalog product and share it across your multi-account environment. What this gives you is version control over the products. And it also allows you to specify which individuals within the organization can actually launch a template.

And here in this slide, we have had administrators distribute approved products to developers, data scientists, your builders. And then they've been able to combine the service, catalog products into a template and then launch it this aligns with the same theme of providing developers with increased productivity gains leading to cost optimization strategies.

Something to uh that we have also seen is that something interesting is um for some of our large enterprises where we have had cloud central teams of three or four members actually build out a centralized uh library of infrastructure as code templates shared across thousands of developers. So it's a quite a powerful tool now to summarize what we have learned, we're going to start with a few key takeaways from starting with the understand and plan stage.

We first started with establishing a structure for your multi-account environment. So this was using organizations and Control Tower and then we moved into the visualize and measure stage where we set up cost dashboards to so that you can have like cost visibility and understand how your resources were being used. And then we spoke about detecting and enforcing consistency with AWS Config. And lastly, we went into the implementation stage where we spoke about the use of tag policies, the use of service control policies and the best practices to accelerating what your development teams do.

So I know that it would have been awesome if we could have spent the entire hour talking about implementing cost optimization. But again, returning like bringing this full circle, a lot of your cost optimization is depend on how you're set up and it's depend on what cost you want to tackle based on the visibility you have. So the two like the specific principles we talked about implementation is using cost controls mainly with policies and identifying the processes that will use those optimized cost controls and then ensuring that you have cost optimized resources available for your developers to utilize and ensuring they know the right channels in which they can provision those resources as well. Those are two very broad bits of guidance that all customers can utilize. A lot of the additional cost optimization initiatives that you will take will likely be related to again what you identify as you build your plan, have better visibility for your costs, share the visibility of your costs, with your, with your teams, bringing them on board with the plan and then implementing those controls in place

So quickly recap the resources. If you didn't get shots of them earlier, these are the resources that we shared throughout the, the, the the presentation. And then finally, we want to thank you for spending your evening here with us talking about cost controls of customer multi-account environment. Please do submit a session survey as something that we pay attention to and that we look to, to help our presentation skills and to help you in future years to hear about the things that you want to hear about. But thanks for joining us this evening. I hope you enjoy the rest of your week every event. Thank you.