guide12 min read

FinOps Lab Thursday: AWS Database Savings Plans — Up to 35% Off Your Data Layer

CloudCostChefs TeamCloudCostChefs Team

AWS Database Savings Plans: A New Tool for FinOps

AWS re:Invent 2025 delivered a gift for FinOps practitioners: Database Savings Plans. Let's break down this new cost optimization tool.

What Are Database Savings Plans?

The same commitment-based discount model you know from Compute Savings Plans, now applied to database services. You commit to a consistent amount of database usage (measured in $/hour) for a 1-year term with no upfront payment:

Commit to a consistent hourly spend for 1 year (1-year term only, no 3-year option)
Save up to 35% for serverless, up to 20% for provisioned instances
Flexibility to apply across engines, instance types, deployment options, and regions

Covered AWS Database Services

Database Savings Plans automatically apply to eligible usage across these AWS database services:

Amazon Aurora (MySQL & PostgreSQL)
Amazon RDS (all engines)
Amazon DynamoDB
Amazon ElastiCache
Amazon DocumentDB
Amazon Neptune
Amazon Keyspaces (Cassandra)
Amazon Timestream
AWS Database Migration Service (DMS)

Available in all AWS Regions except China Regions.

Discount Rates by Service Type

Different database deployment models receive different discount rates:

Service TypeDiscount RateExamples
ServerlessUp to 35%Aurora Serverless v2
Provisioned InstancesUp to 20%RDS, Aurora provisioned, ElastiCache
DynamoDB On-DemandUp to 18%DynamoDB on-demand throughput
DynamoDB ProvisionedUp to 12%DynamoDB provisioned capacity, Keyspaces

The Real Flexibility Story

Database Savings Plans automatically apply to usage regardless of engine, instance family, size, deployment option, or region. This means:

Change instance types: Move from db.r7g to db.r8g instances and keep your discount

Shift regions: Migrate workloads from EU (Ireland) to US (Ohio) without losing savings

Modernize engines: Move from RDS for Oracle to Aurora PostgreSQL or from RDS to DynamoDB while maintaining discounts

Important Limitations

Before you commit, understand what Database Savings Plans don't cover:

  • Storage costs - Only compute/capacity charges are covered, not storage or backup costs
  • Older instance generations - Plans exclude previous-generation instance types
  • EC2 instances - Cannot move spending between compute and database services
  • 3-year terms - Only 1-year commitments available (no longer-term discount option)

Why This Matters

Database costs are often the "hidden ingredient" in cloud bills. They're:

  • Sticky (hard to turn off without application changes)
  • Growing (data accumulates faster than you plan)
  • Overlooked (compute gets all the attention)

For many organizations, databases represent 20-30% of their AWS bill. A 35% discount on that chunk is significant.

Lab Experiment: Calculating Your Savings

Let's run the numbers:

ScenarioMonthly DB Spend35% SavingsAnnual Savings
Small$10,000$3,500$42,000
Medium$50,000$17,500$210,000
Large$200,000$70,000$840,000

How to Purchase Database Savings Plans

AWS makes it simple to evaluate and purchase Database Savings Plans through two methods:

1Recommendations View

AWS Cost Management Console analyzes your historical usage and recommends optimal commitment levels. Navigate to AWS Billing and Cost Management → Savings Plans → Recommendations.

2Purchase Analyzer

For custom analysis, use the Purchase Analyzer to model different commitment scenarios and see projected savings before you commit.

3CLI & API

Automate purchases using the AWS CLI or API for infrastructure-as-code workflows and programmatic management.

Chef's Implementation Recipe

1Audit Current Usage

Pull 3-6 months of database usage data. Look for:

  • • Consistent baseline usage
  • • Seasonal patterns
  • • Growth trends

2Identify Commitment Level

The savings plan should cover your baseline usage — the minimum you know you'll need. Don't commit to peak usage.

3Calculate Break-Even

With a 35% discount on committed usage, you break even if you use ~65% of your commitment. Below that, you might be better staying on-demand.

4Consider Flexibility Needs

Savings Plans offer more flexibility than Reserved Instances. If you might change database engines or instance types, Savings Plans are likely better.

When to Use vs. Reserved Instances

Use Savings Plans WhenUse Reserved Instances When
You want flexibility across servicesYou have stable, predictable workloads
You're unsure about future instance typesYou can commit to specific configurations
You value simplicityMaximum discount is the priority

The Catch

1-year commitment means you're locked in. If your database needs change dramatically, you're still paying.

Chef's Pro Tip

Layer your commitments:

  • Use Savings Plans for 60-70% of expected baseline
  • Keep 30-40% on-demand for flexibility
  • Re-evaluate quarterly as usage patterns become clearer

The Bottom Line

Database costs have been harder to optimize than compute. This changes that. If you have consistent database workloads, Database Savings Plans should be on your Q1 FinOps agenda.

Time to cook up some savings on your data layer.

#finops#aws#database-savings-plans#cost-optimization#reinvent-2025#rds#aurora