AWS re:Invent 2025 - [NEW LAUNCH] Deep dive into AWS Database Savings Plans (DAT326)

🦄 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 - [NEW LAUNCH] Deep dive into AWS Database Savings Plans (DAT326)

In this video, Adam Driver and Rick Ochs introduce AWS Database Savings Plans, announced at re:Invent. This new offering provides up to 35% discount on Aurora serverless with one-year commitments and no upfront payment, covering nine database services including RDS, Aurora, DynamoDB, and ElastiCache across Intel and Graviton instances. Unlike Reserved Instances requiring three-year commitments for specific instance types, Database Savings Plans offer flexibility to switch between database engines, instance types, regions, and deployment models (serverless vs provisioned). The session demonstrates the recommendation algorithm using golden section search to maximize savings, shows live demos of the Billing and Cost Management console including the new Purchase Analyzer tool, and explains migration strategies from Reserved Instances. Key features include automatic application to highest-discount resources first, 7-day return policy, and incremental purchasing options for staggered coverage.

; 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 Database Savings Plans and Speaker Introductions

Good morning, and we are really excited for you to be here. We're going to deep dive into the Database Savings Plans that was just announced yesterday during Matt's keynote. Hopefully you had a chance to hear that it was the actual last item before the buzzer beater. We are really excited to dive deep with you today. It was one of the number one requested features for quite some time. The compute savings plan went live about six years ago, and we've added SageMaker, but the demand for this Database Savings Plans has been extraordinary because customers see a lot of value in it and also want flexibility.

My name is Adam Driver, by way of introduction—not the actor Adam Driver, but the Adam Driver that works at AWS. I've been here for five years, and my role is a leader in our solution architecture team, primarily focused on databases. I've been living and breathing databases for quite some time, and I've been doing it here at AWS for the last five-plus years. With me on stage today, I have Rick Ochs, and I'll let him introduce himself.

Hi everyone. My name is Rick. I lead the optimization products team, which includes products like compute optimizer, right-sizing recommendations, Savings Plans recommendations, cost optimization hub, Savings Plans analyzer, and RI recommendations. I also sit on the FinOps Foundation Technical Advisory Council, representing AWS's perspective and our customers' perspective on the FinOps framework and how it evolves over time.

We're going to be your hosts for the next forty-five to fifty minutes. I love audience participation, and we were talking to some people earlier. It would be great to get a show of hands to understand who in the room is with a FinOps group. That's a good quantity there. How about DBAs or people that are supporting databases, maybe doing some reserved instances? A couple of no hands went up, so I'm assuming you do both or there's some combination there.

Let's continue with audience participation. How many people is this your first re:Invent? That's almost half from what I can see. All right, so I don't want everyone else to feel left out. If everybody who is not at their first re:Invent can put their hand up, please, and then put it down if it's your second or your third. You can start putting it down for fourth, fifth. We're going to see who's the longest. Let's go to sixth, seventh, eighth. I see two hands remaining. Ninth. Oh, they both went down. Congratulations. If you have other questions, we have two people that have been doing this for nine years with us, so thank you. They can hopefully help answer some questions.

Session Agenda: Coverage, Flexibility, and Best Practices

Let's dive into the agenda. We're here to talk about how this is going to work, what it covers, and more importantly, some tools and technologies and best practices to actually make this work for you and really maximize your savings. On the left side of the agenda is where we're going to cover Database Savings Plans. There's a lot of excitement here because the coverage will really drive the engines, the instance types, as well as the provisioned versus serverless options. These are really cool capabilities that the Database Savings Plans will cover, and most importantly, the portability and flexibility.

If you leave here with nothing, think about having flexibility to turn new database engines on, change the usage, change how they're deployed, and have that Savings Plan cover that. As you make choices and architectural decisions, we know that changes across regions, the instance types, as well as the deployment model across dev, test, and production are critical for you to maximize that. We also want to make sure we cover the distinct differences between reserved instances. A lot of the database customers that I speak to are buying specific reserved instances for an engine type for a workload and really locking in that three-year commitment to maximize the savings.

We think there's some additional flexibility to go with that, and Rick is actually going to cover if you're heavy on reserved instances, how do you migrate or what is your plan to move to a Database Savings Plan if that's the path you choose. On the right side, you will learn and hear things you probably already know, but you'll see it in the technology. We're going to show you some live demos that actually walk through the recommendation part, talk about the math behind the scenes, and allow you to see some scenarios that we've prepared to walk through things to maximize that utilization and coverage.

Last but not least, we definitely want to make sure you leave with some best practices. So why did we create the Database Savings Plans?

Why Database Savings Plans Were Created and What They Cover

We definitely received customer feedback about wanting portability and flexibility. We wanted to make sure you had a pricing savings model that would automatically drive savings, not requiring you to recalculate it and figure it out, but instead providing trustworthy recommendations to allow you to drive a one-year commitment. So again, flexible, automatic, and consistent. That pricing model will drive savings. It's different than the reserved instance of a three-year commitment. This is a one-year commitment with no upfront payment. Lastly, there's no waste because everything that isn't covered is billed at on-demand rates. So you're really removing your waste and maximizing your investment.

Let's talk about coverage. Everybody always wants to know what it covers and what things it may not cover in terms of corner cases. The database savings plan supports both Intel and Graviton instances across generation seven and eight. It covers both serverless managed services as well as your provisioned deployment models. This broad coverage ensures that regardless of your current architecture or changes to the architecture and future choices, you can benefit from this database savings plan.

Here's a good slide to take a picture of. This is details by database service. There were a lot of DBAs in the room, and I hope you're using the right database engine and maybe multiple database engines. On the left side of this slide, you can see the database services that we currently support with this database savings plan. There are two columns for discount: one if it's deployed by a specific instance type, and the other if it's serverless or a more managed capability. There are also specific details that talk about which generation of seven or eight and how it's covered and what the maximum is.

Aurora PostgreSQL at the top has a twenty percent discount for instance deployments and thirty-five percent for serverless. That is the highest discount on the chart at thirty-five percent. We want to make sure that RDS SQL Server, including bring your own license, is covered for database instance usage. Aurora DSQL is serverless only at eighteen percent. DynamoDB, a very popular database, is between eighteen and twelve percent. On-demand throughput is eighteen percent, whereas provisioned throughput is twelve percent. That's why you have two numbers in some of those columns. We're really excited because the savings plan covers all of those database services listed on the slide. This is very powerful and will definitely move the needle on flexibility and maximize savings for customers.

The Power of Flexibility and Portability Across Database Services

So why is this flexibility and portability that I've mentioned a few times important? It's important because it allows you to make a commitment and then make changes and choices along the way. Your requirements are changing, your demand and capacity are changing, and you don't have to manage multiple commitments. With a reserved instance, you have flexibility on how you do that. We really believe you should be able to move usage between database services, switch your engines, and bounce between serverless and provisioned across your development, test, and production environments.

The ability to change is really important because we're constantly becoming more resilient. You can move across availability zones within regions, which is something you're doing today. But the savings plans will allow you to have that coverage and flexibility. Reserved instances require specific reservations for particular instance types. The database savings plan allows you to be more dynamic and have an evolving architecture that maximizes and meets your business requirements today while allowing you to adapt to those in the future. So again, flexibility, portability, and the ability to move, switch, change, and adopt allows you some really good choices going forward with the database savings plan.

The next slide shows the maximum saving at thirty-five percent. Which service was that? From the last slide, thank you, Aurora. We're really excited about that.

It's a one-year commitment, which is different from reserved instances that require a three-year commitment, and there's no upfront payment. There are some advanced pay options, but the key takeaway is the savings. On-demand pricing applies to anything not covered by the database savings plan. We're really excited about driving that flexibility.

Database Savings Plans vs. Reserved Instances: When to Use Each

How does this work compared to reserved instances? I've touched on this, and I want to call out the big differences. First, database savings plans work with your existing specific pricing programs in place. They can be utilized with your discount and pricing agreements for additional savings. However, database savings plans and database reserved instances cannot be combined on the same workload, so there has to be a choice based on the workload in terms of how you're providing that discount across dev, test, and prod environments.

Let's talk in more detail about when you should use one or the other. The common question we get is if you're using a lot of reserved instances, how do you migrate? What is your strategy to get to the database savings plan if that's where you want to end up? On the left, we've laid out very clearly that you should use the savings plan if you want to move between database services and instance types. We also want the ability to adopt new technology quickly and try a new database service without managing separate commitments, which is a classic reason to use the database savings plan. The goal is to simplify your cost management across all these database services.

However, it makes sense to use reserved instances if you have a stable, predictable, known workload on specific instance types that you've already implemented and it's not very spiky. If you know exactly what it is, it makes sense to have a three-year longer commitment that maximizes even further discounts. You do need a reservation for reserved instances, whereas with the database savings plan you don't.

The Savings Plan Lifecycle: Purchase Decision Process and Recommendation Algorithm

At this point, I'm going to turn it over to Rick. We've covered what it is, what the coverage is, and some of the flexibility. Rick will dive a little deeper. Thanks, Adam. Sure. As we were building database savings plans, we talked to a lot of customers about how they do their purchasing strategies and planning for compute savings plans and instant savings plans to learn about the pipeline, workflow, and process of how you make the purchase decision, how you do your purchase analysis, and how you track the success of these purchases after you've made them.

We have a lifecycle slide here that shows the process. First, you determine what savings plan you're going to purchase and how much. In this specific case, there are fewer decisions to make because it's already one year with no upfront payment, but how much you purchase is still a really big part of the puzzle to solve. Once you add that to cart and make the purchase, it becomes a tracking game where you need to track coverage, utilization, and the discount you're receiving from that savings plan to make sure it's meeting the needs and expectations you had when you made your purchase.

As you track your coverage and utilization, which we'll get into in more detail in a few slides, you may find that you want additional savings plans. Perhaps there's more on-demand spend to cover or more savings to capture. Tracking the coverage and utilization will help you decide when it's time to go back to the beginning of this pipeline and make new purchase decisions for savings plan opportunities. We have a couple of different options or methods for purchasing new savings plans. We have a recommendation product.

This is the same product that if you're used to compute savings plans today, it's the same product, same experience, and same console location. Hopefully for those of you experienced and comfortable with the savings plan product experience, this won't be a new thing for you. The idea is to make this easy and comfortable so there's not a lot of overhead with managing and purchasing commitments. Those recommendations are a great starting point for you. The recommendations will look at all of your historical on-demand usage and find the most optimal, highest discount purchase amount for you based on that historical usage, and you can just click add to cart and you're off to the races saving money. For more advanced users, you probably want to test out different purchase amounts, maybe look at different specific periods of time in your history, and we have a new product we announced last year at re:Invent called Savings Plans Purchase Analyzer.

This has been a very popular tool for our FinOps customers that are doing a lot of analysis and purchasing decisions who maybe want to layer different savings plans together or stagger their purchases. This product helps because it'll show you the same kind of information: how much you're going to buy, how much discount you're going to get, the coverage and the utilization for any purchase amount you want. So that's maybe a more advanced approach, but what's interesting is you can easily transition from the recommendations to Purchase Analyzer and test out different purchase amounts quickly and easily by moving between the two product experiences.

So as we discussed, the first question is what are you going to purchase? In this specific case, Database Savings Plans, but we really want to know how much savings plan. Is there any other details? Is it specific? Are you going to buy for a specific linked account? Are you going to buy a savings plan for your payer account which will cover all of the usage and all of your linked accounts? So that decision—what are you purchasing, whether that's maybe a reserved instance or a savings plan—then it goes to how much to purchase, which we have a recommendation and Savings Plans Analyzer products for, and then tracking usage. In the Billing and Cost Management console we have coverage and utilization reports for savings plans so you can track over time continuously how much savings you're getting and what percentage of your usage is covered by your commitments.

A question that we get a lot is how do we determine the math with that recommendation? I know we produce a recommendation, but what's the math behind that? And is it trustworthy? That's a great question. So we get that question from a lot of FinOps teams that are trying to figure out whether they should build a spreadsheet and look at their on-demand cost themselves and download the CUR and look at it. The idea behind the recommendation is we want to do that for you. It's a lot of heavy lifting and a lot of math. In our recommendation algorithm we use something called a golden section search algorithm, which is actually a very common algorithm you can find by searching online. What it's doing is testing a bunch of different purchase sizes and finding the one with the highest amount of savings.

It doesn't necessarily mean that it's finding the low usage amount because as your usage accrues over time you're going to have peaks and dips, especially with serverless because you may be having spiky workloads during the day and during nights and weekends you have no load, or maybe you're a company that has a lot of usage on weekends and nights. These spikes and dips in your usage mean that a recommendation will find how much of those spikes and dips you should cover for the maximum dollar amount of savings. So the recommendation in this graph is sort of in the middle there, and if you purchase more than the recommendation, you'll actually net a little bit less savings, and if you purchase less than the recommendation, you will also net a little bit less savings. So the recommendation is designed to find mathematically the highest dollar amount of savings that's available based on your historical usage.

You can pick in the recommendation 7, 30, or 60 days lookback period. So if you have changes in your environment recently, you can pick the window of time that is more representative of what you believe will be your future usage. And even with custom dates, it's not just fixed. So in Savings Plans Analyzer you can do custom dates, which is a nifty trick, and I'll demo that as well. So as an example we made a little bit of an image to show that we analytically graph out how much savings or what the total cost is and find the absolute lowest point of cost for what specific purchases you can make, and that's what our Savings Plans recommendation algorithm does.

Understanding the Console Experience and How Savings Plans Apply to Usage

It's very important that we're transparent with how the recommendation is generated by showing the utilization graph and the cost graph so that way you can always double check the math yourself. But what's really cool is we actually take a little bit of your monthly bill and code that we run to publish the bill, and we run the part of it that calculates your savings plans being applied against your resources. So we actually run a part of the end of month bill computation when we generate the recommendations to double check that it's going to yield exactly the savings, as long as your usage is similar to what it was in the lookback period.

So what changed? What's new in the console? How many of you are familiar with the recommendations or savings plan analyzer products in the console today? Good number, yeah, okay, awesome. I like seeing that. You'll see now as of yesterday at 8 a.m., a new option in the recommendations and purchase analyzer. You'll see Database Savings Plans is now an option for you to click and get those recommendations. The recommendations are already generated and available on all of your accounts where there is eligible on-demand usage.

So you can select that and you'll immediately see these recommendations populate on the bottom, and then you can click view details on these recommendations. Now there's a lot of colors and graphs on the slide, so we're going to go through it individually. You'll see the first graph on a new recommendation is how much you're currently covering with existing savings plans, how much the recommendation is advising you to purchase to cover additional on-demand, and what is the remaining on-demand that is not ideal to cover with a commitment because the discount or savings is not positive. So that is the left graph, and you can just track over time and understand like, okay, here's how much I'm going to have left over and here's how much coverage I'm going to get.

Note that your FinOps teams will love you if you make a lot of these purchases because the bill month over month gets much more stable and consistent when you convert your on-demand spend to a flat hourly rate savings plan. So your finance people will love this. The people that read the bill and try to make sense of it and explain it, having a nice consistent flat rate hourly fee is much easier to handle because you have less variability in your spend.

On the right side of the screen we have the coverage graph. This will show you how much of your on-demand spend is being covered by this newly recommended commitment, and it will also show you what your current coverage is. So if you already have some savings plans for databases, maybe not, but although I did have some customers yesterday already make savings plan purchases, which is pretty cool, you'll see your current coverage and then what the coverage would be if you purchased the newly recommended savings plan.

So coverage is very important for those of you in the audience that are FinOps. You know, a lot of companies target a certain average coverage percentage. They want to cover 70, 80, 90 percent of their on-demand spend. They want to leave a little bit left over for maybe if they're going to run an optimization campaign like migrating to Graviton or going to serverless. Those are important elements of how to make your decision.

And then on the bottom right you'll see how much of the savings plan will be consumed or used, and there may be dips in this graph. It's important to note that it's okay to have dips in utilization and have a little bit of savings plan go unused. I'm always drawn to this utilization chart in the lower right, and what Rick just touched on, for those of you that might not be in FinOps, why wouldn't I just do a blanket coverage and ensure that I had 100 percent coverage or 105 percent coverage, Rick?

Yeah, it's so because you can either optimize for max coverage or utilization, and you kind of have to pick which one's more important to you. But if you maximize your utilization, it means you're buying a smaller savings plan that's always going to be fully used. It means you have a lot more leftover on-demand spend that you're paying the full on-demand price for instead of having it under commitment. So we do talk to customers that they see an unused savings plan and they're like we don't want that. But you actually get more savings if you purchase the recommended amount, which doesn't always have 100 percent utilization. Makes a lot of sense.

Okay, so we talked a little bit about how the recommendations work. Now we're going to talk about how savings plans apply to your usage. When you're using purchase analyzer or recommendations or even when your bill, your month-end bill process is running, savings plans will apply to the highest discount resources first. This is really important because, as Adam mentioned, serverless has a higher discount. 35 percent for RDS and Aurora is an amazing discount. We want to make sure you get absolutely every dollar of that higher discount first.

What that means is that 35 percent Aurora serverless pricing will always consume the savings plan first, and then it'll go down the list in the discount amount, meaning first we consume 35 percent Aurora serverless, then ElastiCache, and then DynamoDB, and it steps down by the discount percent. So as you purchase more and push your savings plan coverage higher, you get diminishing returns as you get closer to your break-even point or your highest ROI.

You will get the highest savings with smaller savings plans, but the recommendation will calculate all of that and tell you what the ideal purchase amount is for Database Savings Plans.

Customer Strategies: Laddering Purchases and Migrating from Reserved Instances

How do we see customers using savings plans today? This is important because many companies have invested time, analysis, and effort into coming up with purchasing strategies and plans for how to approach fairly expensive and important investments for the future of their cloud spend.

What we see is laddering or incremental purchasing becoming a very popular method for FinOps teams. This means you can purchase a savings plan right now before you leave the conference and start saving immediately. It does not have to be the full recommended purchase amount. It can be a smaller amount, and you will immediately get some savings, especially if you are running serverless with a pretty high discount amount, the highest discount amount, because it will be applied first. You can always purchase more.

There is really no downside to staggering or layering purchases together because you can always revisit your strategy. If utilization changes or grows, you can make another purchase. All of the savings plans will work together and apply to all of your usage together. Purchasing incrementally, whether that is monthly, quarterly, or even weekly as some customers do, is really beneficial because you will not have one giant expiration of a commitment twelve months from now that you have to wait for.

You will have staggered expirations of your commitments in case your usage drops. This is a nice way to get even more flexibility out of your savings plan purchases by laddering and staggering them together to build up to the amount of coverage you want for your spend.

How do we move from reserved instances to savings plans? We know many customers use reserved instances for RDS, which are one or three year commitments that you can make to receive a discount for a specific instance type in a specific region or zone. What we heard is that many customers really like migrating to Graviton or moving to the newest instance family and generation to get better CPU performance, which also allows you to use things like compute optimizer and right-size recommendations.

Making sure that you have the flexibility to make those changes is key. If you are going to migrate, maybe change database services, go to serverless, that flexibility was critical. Deciding your overall commitment strategy of where you are going to be making reserved instance purchases for those stable workloads that are not going to change for a long time and then using savings plans to layer on top for all of your usage that may be more flexible or change over time is important. You can do both. You can use your reserved instances for your stable long-term workloads, but for usage that maybe you need more flexibility or you have plans to move to Graviton or do optimization programs, that savings plan flexibility is really important for you.

Deciding on a commitment strategy is important. You need to establish what your utilization looks like over time, what your spend looks like over time, and how much of that you want to cover.

As you go through this process, the most important part of Database Savings Plans is that it is not one service, it is nine services of usage. This allows you to stack the usage from all of these services together and cover more of it. Say your DynamoDB usage is dipping, but maybe your RDS usage is increasing certain hours of the week. By stacking all of this usage together, you can cover more of that usage with a single savings plan or multiple savings plans.

We believe this will allow you to purchase and cover more of your usage with more discounts. Especially for serverless, which did not have a discount offering previously, this is a brand new discount offering. We believe this will save a lot for our customers and we are really excited to see it in action. Combining usage for all of your database services together will allow you to make bigger purchases and achieve more savings.

You can look at the individual services and usage for each service, or you can combine and look at all of that usage together. You can make Database Savings Plans purchases for those services individually, or you can combine them, which is what we do in the recommendations and savings plan analyzer tool.

Moving from reserved instances to savings plans, one of the interesting migration strategies would be to wait for them to expire for each service. Then you take that on-demand usage once it frees up and comes off of a reserved instance, and you can start to put together a purchase plan and gather that utilization information. Maybe if you would like to repurchase reserved instances for those stable workloads and then convert the rest to savings plans, you could consider purchasing for maybe an 80% target. Get your coverage and your highest discount usage done first, and then you can leave that 20% for maybe future plans on modernization, right sizing, or switching to Aurora IO optimized, which is another great option.

One way to think about this is to track the expiration dates of your reserved instances for each of your services. In the RI inventory console in the cost management console, you can track the expiration dates of all of your reserved instances and then make a plan for aggregating all of that usage together for all of those services and then start covering them with savings plans. By tracking all of that, we can convert all of the usage from all of these different services into one pool of usage and spend for all of these database services and track and manage them to make your purchases.

We talked a little bit about staggering. Here's a visual example. As your reserved instances expire or as you work with a lot of your different engineering teams and understand what resources they're running and how they're running them, you can incrementally add and increase the amount of savings plan coverage over time by making those purchases. As your RIs expire over time, you can either repurchase RIs or convert to savings plan spend. By doing so, you can increase the amount of spend that is covered by a discount or a commitment over time, yielding a higher total amount of savings.

We feel that with reserved instances, a lot of customers were hesitant to make that purchase because you maybe didn't have high confidence in knowing the future. Maybe a new instance type comes out that you would like to optimize or migrate to, or you're not sure if this workload is going to exist in six months. The flexibility of Database Savings Plans will provide some sort of insurance so you know you can utilize that discount with any other resource type.

Live Demo: Navigating Recommendations, Purchase Analyzer, and Coverage Reports

Once you've made your purchases in the console, you can go to the Billing and Cost Management cost and utilization reports. Here's an example of what it looks like after you've made your purchases and you would like to track how much of that spend is being covered by a new savings plan. This is really important because if your coverage starts to dip, that's a great opportunity to go and analyze whether you would like to make additional purchases or maybe some engineering teams spun up some new resources and they're utilizing those resources for a brief period of time.

Maybe they're testing something out, maybe they're kicking the tires on a different service, or scale testing or load testing. Understanding why the coverage has a dip is important because it may not be a moment where you want to make a purchase for that. It may be something where an engineering team is testing something or trying something else.

We're going to switch over to demo now. Here's the Billing and Cost Management console. For those of you in the FinOps space, I'm sure you're very comfortable and familiar with this. For those of you with a more of a database background or non-financial background, this is the location that all of our FinOps customers spend a ton of time to look at and understand their costs, their spend, and usage data details.

You'll also see we have a product called Cost Optimization Hub that provides Aurora IO optimized recommendations, RDS right-size recommendations, and idle recommendations to help you optimize and save even more. In the Billing and Cost Management console on the left side, you'll see recommendations and Purchase Analyzer. These are the same products you're experiencing today or have used over the last several years for Compute Savings Plans and Instance Savings Plans purchases. We're not introducing a new product experience here; we're improving these existing products to include Database Savings Plans.

As you saw in the slides, we now have a new Database Savings Plans option in the recommendations. Once you select Database Savings Plans, we will show you a recommendation that we've already generated for you. In this case, you can save $315 a month on a recommended purchase. You can choose whether you want a recommendation for the payer level or a specific linked account, and whether you want it based on 7, 30, or 60 days of usage.

We also have options for Savings Plans term and payment option. Those options only apply to Compute and Instance Savings Plans. For Database Savings Plans, they're locked at one year with no upfront payment. In this case, I've increased my usage significantly in the last week in preparation for re:Invent, so I'm going to pick 7 days because I believe that usage is more representative of what I expect to have in my environment going forward.

Looking at this recommendation, I can see some spikes in my usage. I've actually been running some serverless workloads in my environment for the last week or so to show what it looks like to have a highly dynamic environment. If you look at the recommendations in your payer account or for an account with a lot of usage, you'll see lots of spikes and dips, especially if you're running serverless or if you're doing RDS auto-pausing. Does anybody in the audience pause your RDS instances for cost savings for up to 7 days at a time? It's really important that the analysis and the recommendations account for those dips and peaks in your usage.

Over the last 7 days, I can save about $2,000 a month or 9% of the cost just on my last 7 days of usage. However, you'll see these dips actually go below the purchase amount, so I want to understand what's happening here. I can click over to the coverage graph. This is the same graph we showed earlier in the slides. I want to know what percentage of the spend or usage I have that will be covered by this new recommendation. I can see that it dips between 76% and 100%, which represents my peak and my low usage over time, and that's what a new Savings Plan would cover when it comes to my spending.

Then I want to track how much of the Savings Plan is being consumed. Am I leaving any of that Savings Plan on the table? I would advise you not to think of it as waste because you still get a higher amount of savings. Let me give you an example. Say you turn an instance off on the weekends for 20% of the time, but you have a 25% discount option to save. It's still worthwhile to buy a commitment or a discount vehicle because that 5% extra savings will yield you a lower total bill, even though your commitment might not be used 100% of the time. That's perfectly fine because the whole idea with optimization is to ultimately lower the bill.

We want to see that number as low as possible with no impact on performance and availability of your workloads for your customers. Seeing utilization below 100% is okay; don't run from it. Some FinOps teams chase this down to zero and want zero unused commitments, but we recommend targeting your total savings amount or your coverage amount instead. If I scroll down, you can see some additional details. These won't really change a lot for Database Savings Plans, but you can see if this recommendation is at the payer level, the lookback period, the average hourly utilization by percent if you want to target a specific percentage, and the same with coverage. You can see an average coverage percent here. Many FinOps teams will target a specific number here because they want to cover a certain percentage of their spend to minimize risk and maximize flexibility.

The out-of-the-box experience generates recommendations for you in your console. However, if I have usage patterns that are more representative of my actual needs, I can click over here to access the Purchase Analyzer. Now I have much more control over the engine that populates and calculates the recommendation. I can come in here and change the lookback period to any custom range I want. I was running a lot of server lists with higher usage between the twenty-eighth and the first, and I had some usage over the weekend, so I can pick this specific date range. Then I can run the recommendation engine again.

We're going to run the analysis, and it will take a few seconds because it runs a portion of your month-end billing process code, which applies and simulates how the savings plans will apply. Once that runs, you get that same set of graphs. In this case, it's telling me there is a flat rate purchase of $29 an hour that will fully cover everything. That's a pretty big savings plan, and it's going to save me over $5,000 a month and an estimated 21% off my spend. The more serverless you're using, the higher discount amounts you'll have, and it will be consumed first, so you'll see this number go up.

However, I know that I had some dips over this period of time, and I want to understand that. So I can come into the Utilization tab to understand how much of that new savings plan is going to be consumed. This may be an opportunity for optimization as well. If I have some periods of low utilization, I can schedule ETLs or backup jobs or other usage in those time periods to consume that savings plan and maximize my discounts even more. That's what it looks like to customize your lookback period. But what if I'm not sure if that's the amount I want? $29 an hour is a big commitment, and I would have to go get approval from finance. However, I have auto-approval for anything under $15 an hour, so I'm just going to type in $15 an hour and run that same exact analysis. It will calculate all of the savings plans per hour coverage, utilization, and savings amounts.

Here we can see the leftover on-demand usage that's still going to be out there. This is great if you have a strategy of purchasing savings plans incrementally. We hope that before you leave the conference, you can engage your FinOps team or go on the console and think about making a purchase right away. It doesn't need to be the full recommended amount, but you can start saving with the highest discount amounts on your server lists and other high-discount savings services pretty quickly by making a smaller purchase. Leaving a little bit of that on-demand usage for additional future analysis, optimization programs, or campaigns still leaves you that flexibility to make more optimization and FinOps decisions later.

You can make these smaller purchases and use Purchase Analyzer to make sure you're still netting good savings. In this case, because we purchased a lesser amount, we're still getting most of the savings. We're still getting $3,200 of the savings even though the commitment we made is quite a bit less. Again, you still yield a very high amount of savings when you buy smaller savings plans because it consumes the highest discount first. Once you do these analyses and have different lookback periods, I'm actually going to switch to a 7-day lookback and see what the system recommends I purchase based on the last 7 days. Once you make these decisions, you can quickly come in here, refresh the recommendation, and get the latest data from the most fresh usage. Then you can click the Add to Cart button right here and make your purchase. In this case, we're recommending a $22 purchase for $2,400 a month in savings, and you can quickly just add to cart and make your purchase.

Once the purchase is complete, another question came up: what if I made a mistake? What if I overpurchased? What if I'm afraid of making the purchase because I find out we were doing a migration and I wasn't aware of it?

You have 7 days to return a savings plan as long as it's within the same month. I recommend generally that if you're not 100% positive on your purchase, do not purchase at the end of the month because once the month rolls over, we close the bill. However, you have a 7-day window to return any savings plan under $100 an hour. This is a really nice feature that protects you from any mistakes or fat fingers, or anything like that if you accidentally added another 0 in the purchase. This 7-day return button is something we launched a couple of years ago, and it helps increase the confidence that it's okay if you fat finger something. You're not going to have to engage support. You can just return that savings plan.

Even if you make the purchase and begin to track coverage and utilization and it's not looking right, your coverage is way too high or your utilization is way too low, you can return that savings plan and purchase a different amount. Moving on to coverage and utilization report, say we've made the purchase. Then I can come in here and look at coverage. This will show you what percentage of your on-demand spend is covered by the purchases you made. My coverage is really low because I made a purchase and then I returned it because I wanted to have nice big recommendations for the demo. So my coverage is pretty low, but you can come in here and track how much of your spend is being covered by commitments and discounts.

You can also look at what resources are consuming what commitments. In this case, I've got a bunch of compute spend here and everything, but you'll see these line items for these different services and which services are consuming which amount of your savings plan spend. You can filter and click through different service types to understand which ones are contributing the most to the savings you're achieving from your savings plans. Alternatively, we have the utilization report which will show you what percentage of your savings plans are being consumed like we showed earlier in the slides.

Closing Remarks and Call to Action

That's it for our demo. I'm going to switch back to the PowerPoint and invite Adam back up on stage here. Let's give a round of applause. He covered a lot of ground with that, really well done. I think these technologies that are in place in the billing console are incredibly helpful, and hopefully you saw something new, at least the icon for database savings plans if you haven't seen that before because it went live yesterday.

As we close this presentation, we'll be around following the presentation if there are any questions. Feel free to come on up. Our recommendation and call to action is definitely to access it. As Rick just covered, no mistakes, right? You can do that return within 7 days, but identify it, share it with your teams, access it, try it, see what the recommendations are doing, isolate that custom range where you know you have something interesting going on in your environment and see what the recommendation comes back with.

So that's access it, try it. We think that is incredibly important. As always, we want your feedback from the session, which you probably have on your phones to fill out a quick survey. We also have some websites and I know Rick and myself will make ourselves available to answer any questions that you might have. Send feedback. We'd love to hear how this is working for you because it is a really important launch for us that some people in the room have been waiting for 9 years. Thank you for attending. It was great doing this with you, Rick. I appreciate it and enjoy the rest of your re:Invent. Thanks everyone.

---

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