ClouDigest ClouDIY ClouDebrief

ClouDebrief: Database Savings Plans

-



Every year at AWS re:Invent, the spotlight naturally goes toward AI, bigger models, faster chips, smarter agents. 

But amidst all the AI buzz, there was one announcement that made existing AWS customers sit up, lean forward, and whisper:

“Finally… something that helps me save money today.”

And that crowd favorite was the introduction of Database Savings Plans (DSP), a flexible new pricing model that can reduce database costs by up to 35% when you commit to a consistent amount of usage (in $ per hour) over a one-year term, with no upfront payment.

What Is Database Savings Plans?

The Problem Before DSP

Before Database Savings Plans, saving money on AWS databases required juggling multiple, different mechanisms:

Example:
If you moved your RDS MySQL instance from db.m5.large to db.r7g.large or switched from RDS for Oracle to Aurora PostgreSQL, your existing reservations might no longer match. You’d lose your committed discount and start paying full on-demand price again.

In short: flexibility was expensive.

Database Savings Plans (DSP)

Database Savings Plans simplify all of this with a single, elegant idea:

Commit to a consistent amount of database usage (in $/hour) for one year → get discounted pricing (up to 35%) on eligible database usage.

Unlike older models, this discount:

  • Applies automatically to both serverless and provisioned database usage
  • Is not tied to a specific engine, instance family, size, deployment option, or AWS Region
  • Requires a 1-year commitment but no upfront payment by default

What DSP Works Across (Official Scope)

According to AWS, Database Savings Plans automatically apply to eligible usage for:

Database Savings Plans are available in all AWS Regions except the China Regions.

Flexibility: Engines, Regions, and Instance Types

With Database Savings Plans, AWS explicitly calls out that you can:

  • Change between Aurora db.r7g and db.r8g instances
  • Shift a workload from EU (Ireland) to US (Ohio)
  • Modernize from Amazon RDS for Oracle to Amazon Aurora PostgreSQL
  • Move a workload from RDS to Amazon DynamoDB

In all of these cases, as long as the usage is eligible and within your committed amount, you still benefit from the Database Savings Plans discounted rates.

What You Can Save

Officially, AWS states that Database Savings Plans can reduce your database costs by up to 35% compared to on-demand pricing, depending on how consistently you use your committed amount of database usage across supported services.

The more your actual usage aligns with your commitment, the closer you get to those maximum savings.

How DSP Works

  1. Choose a 1-year commitment in $/hour.
    For example: “We’ll commit to using $8/hour of eligible database usage on average.”
  2. AWS tracks eligible usage every hour.
    This includes serverless and provisioned database usage across supported services, engines, instance families, sizes, deployment options, and Regions (except China).
  3. Discounted rates are applied up to your commitment.
    All eligible usage up to $8/hour is charged at the Database Savings Plan rates.
  4. Any usage above your commitment is billed at on-demand rates.
    If one hour you consume $10/hour of eligible usage, $8 is billed at the discounted rate and $2 at the regular on-demand rate.

In other words:

DSP lets you modernize, migrate, and scale across engines, Regions, and deployment models — while keeping your discount intact, as long as you stay around your committed usage.

How to Choose and Monitor a Database Savings Plan

AWS provides several tools to help you decide on and manage your commitment:

  • Savings Plans Recommendations – suggests a commitment amount based on your historical usage for maximum savings.
  • Savings Plans Purchase Analyzer – lets you simulate different commitment levels and see how they affect savings, coverage, and utilization.
  • AWS Pricing Calculator – helps estimate on-demand costs so you can decide what level of commitment makes sense.
  • Coverage and utilization reports – available in the Billing and Cost Management Console to track how well you’re using your Savings Plans.

You can purchase Database Savings Plans directly from the AWS Billing and Cost Management Console or by using the AWS CLI.

How DSP Interacts with Existing Discounts

There is one important rule to keep in mind:

  • For the same workload, you cannot combine Database Savings Plans with Amazon RDS Reserved Instances or Amazon DynamoDB reserved capacity.
  • You can, however, use different mechanisms for different workloads. For example:
    • Use a Reserved Instance for one stable RDS workload
    • Use Database Savings Plans to cover a mix of Aurora, DynamoDB, and ElastiCache for other workloads

Your eligible usage automatically applies to your Database Savings Plan commitment at the discounted rate. Anything beyond your commitment is charged at on-demand prices.

Why This Is a Game-Changer for Existing Customers

Let’s walk through a few real-world scenarios to see what changes with Database Savings Plans.

 Example 1: Before DSP  - “Oops, we lost our discount”

Your team runs an RDS MySQL instance on db.r6g.large. Over time, traffic increases and you decide to:

  • Upgrade to Aurora db.r7g or db.r8g, and
  • Move the workload from EU (Ireland) to US (Ohio) to be closer to users

Before DSP:

  • Your existing RDS Reserved Instance might not match the new instance family/size.
  • Migrating from RDS to Aurora could mean your old reservation no longer applies.
  • Changing Regions often meant “starting over” from a reservations perspective.

After DSP:

  • You commit to a certain $/hour under Database Savings Plans.
  • You can move from RDS for Oracle to Aurora PostgreSQL or even to DynamoDB, and your discount still follows, as long as the usage is eligible.
  • Shifting workloads across Regions (for example, EU to US) still keeps you inside the same DSP umbrella.

Your commitment now follows your architecture — not the other way around.

Example 2: Hybrid Database Environments

A typical SaaS platform might use:

  • Aurora PostgreSQL for core transactional data
  • DynamoDB for high-throughput, key-value workloads
  • ElastiCache for low-latency caching
  • DocumentDB for document-oriented logs or metadata
  • DMS for ongoing migrations or replication

Before DSP:

  • Each service had its own reservation or discount model.
  • Planning savings meant coordinating multiple reservation purchases.
  • Migrating between services introduced financial friction.

After DSP:

  • A single Database Savings Plan can cover all of these services.
  • Your main question becomes: “Is our combined eligible usage roughly hitting our committed $/hour?”
  • Architectural decisions can favor what’s best technically, not just what matches existing reservations.

This is especially powerful for teams embracing polyglot persistence — choosing the best database for each microservice.

Example 3: Moving to Serverless

Serverless databases are increasingly popular, especially for:

  • Spiky or seasonal workloads
  • New applications with uncertain demand
  • Teams that want to reduce operational overhead

Historically, there were fewer structured commitment discounts focused specifically on serverless database usage.

With Database Savings Plans:

  • Serverless and provisioned database usage are both covered under one model.
  • You can gradually shift parts of your workloads to serverless while still benefiting from your DSP commitment.
  • Cost optimization no longer forces you to choose between flexibility and savings.

Existing Customers Loved This Announcement

Some announcements are futuristic. Database Savings Plans are immediately valuable.

DSP directly addresses pain you feel every month when the AWS bill arrives:

  • Lower database costs without harsh lock-in penalties
  • Freedom to move between database engines (for example, RDS Oracle → Aurora PostgreSQL → DynamoDB)
  • Freedom to migrate between Regions
  • Freedom to scale up or down and modernize architectures
  • Discounts that follow your architecture, not constrain it
  • One unified way to think about database cost optimization across many services

It gives customers exactly what they’ve been asking AWS for:

“Let us modernize without being punished by your pricing model.”

Comments

Post a Comment

Popular posts from this blog

ClouDesign: Architecting Serverless

-
Image
  Serverless Solution Architecture Introduction AWS provides a comprehensive suite of serverless services that allow developers to build secure, scalable, and cost-efficient applications. In this article, we will design a serverless architecture. We will look at common packages that usually come together for a given use case. ClouDatum: DynamoDB global tables replicate data across multiple AWS Regions in less than one second. API Gateway can process over 10,000 requests per second per API. DynamoDB DAX can improve read performance by up to 10x compared to standard DynamoDB reads. Cognito user pools can scale to handle millions of users without manual intervention. The goal here is to design architecture using serverless services offered by AWS. Also, the architecture might vary from each individual's POV. We should try to understand the core use case, which service is usually good to opt for and where. Let us start with our first case. 1. Mobile App: MyTodoList  Understandin...
Read more

ClouDIY: Bootstrapping Linux Servers – Part 2

-
ClouDIY: Bootstrapping Linux Servers – Part 2 Advanced tools and services for Linux system administration (based on RH134) 1. Shell Scripting Basics Shell scripts allow you to automate tasks such as backups, user setup, or software installation. They're simply text files containing a sequence of shell commands. #!/bin/bash echo "Welcome" whoami Explanation: The first line tells Linux to use the Bash shell. echo displays text, and whoami prints the current user. Tip: To run the script, first make it executable: chmod +x script.sh ./script.sh  Loops and Conditions Scripts often need to make decisions or repeat actions. You can do this using if statements and loops . If statement: Checks if a file exists before taking action: if [ -f "/etc/passwd" ]; then echo "File exists" fi For loop: Repeats a command for each item in a list: for i in 1 2 3 do echo $i done This loop prints the numbers 1 to 3, one per line. grep, awk,...
Read more