How AWS Database Savings Plans Change the Economics of Your Data Layer

Cloud infrastructure is one of the largest and fastest-growing components of COGS for SaaS companies. If you run on AWS, you've likely already worked with engineering to bring some structure to your compute spend through Savings Plans and Reserved Instances on EC2 and related services.

A significant share of your AWS bill lives in the data layer: production databases and data services that run continuously and scale with customer usage. Until recently, that spend mostly stayed on demand, with limited commitment options and higher effective rates.

AWS just changed that. Database Savings Plans allow you to commit to spend on key managed database and data services for one year in exchange for lower prices on that usage. For a CFO, the implication is straightforward: a big portion of the AWS bill that used to behave like volatile, on demand COGS can now be brought under contracted, discounted pricing while allowing engineering teams more architectural flexibility.

Finance teams are under pressure to improve gross margin and make cloud COGS more predictable against plan. Database Savings Plans create a new lever that extends commitment economics into the data layer and complements the commitments you already have on compute.

This post will explain what Database Savings Plans are in simple terms, show why they matter for margins and forecasts, describe how to think about commitments across compute and data as a single portfolio, and outline how Cloud Capital helps companies capture the upside while managing commitment risk.

What AWS Launched, in Plain English

Like their Compute Savings Plans, AWS Database Savings Plans allow companies to commit to a steady amount of eligible database and data services usage per hour for one year in exchange for lower prices on that usage.

The plan covers multiple services across instance families and regions, including Aurora, Relational Database Service (RDS), DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and Database Migration Service (DMS), and remains flexible as you scale or change your architecture. 

AWS advertises potential savings of up to 30-35 percent on serverless offerings and 20% on instance-based services, compared with on-demand rates. The more consistently you use these services, the closer your realized discount can get to the headline range.

Database Savings Can Improve Margins and Forecasts

Cloud Spend as a Top Lever

Growth-stage SaaS CFOs are being asked to improve gross margin and efficiency without killing growth. Cloud infrastructure, and particularly AWS, is one of the largest and most adjustable cost lines you can influence in the medium term.

Many companies already use Compute Savings Plans and RIs to bring architectural flexibility and savings to EC2 and similar services. But a meaningful slice of the bill has remained on demand, especially in the data layer.

Databases are a Large, Stable, Under-Optimized Line Item

In many SaaS environments, compute ends up around half of AWS spend. Managed databases and data services often contribute 20 to 30 percent, and can be higher for data or AI heavy products.

These database and data services run continuously for production workloads, scale with customer and product usage, and have often stayed mostly on on demand pricing because engineering teams were cautious about rigid reservations.

How Database Savings Plans Change the Economics

A meaningful portion of that database and data services spend can now be covered by one-year commitments that behave more like compute Savings Plans. This allows companies to move more of a large, predictable cost into contracted discounts and improve the effective unit cost of core data services without re-architecting applications.

In practice, for customers with reasonably stable database usage and well-sized commitments, effective discounts on the covered database slice often land in the high teens to mid twenties percent range.

Database Savings Plans are especially attractive if you have meaningful, relatively stable database usage. They are less compelling if most of your workloads are very spiky or short-lived, in which case it can be better to stay on demand or wait until usage patterns settle.

Here's a clear numeric example:

Start with a total AWS bill of $100k per month, or $1.2M per year. Eligible managed databases and data services represent about 25 percent of that, or $25k per month.

In a simple commitment scenario, you commit half of that data layer, $12.5k per month, under Database Savings Plans with a 20 to 30 percent effective discount on that slice. That equates to roughly $30k to $45k in annual savings.

For a growth-stage SaaS company, that typically means:

• $30k to $45k per year in lower AWS COGS
• Roughly 1 to 2 points of gross margin improvement, depending on revenue scale

Predictability and Savings

Database Savings Plans reduce the expected bill and also make more of that bill contracted and predictable. That narrows the range of cloud COGS outcomes relative to plan.

If cloud COGS surprises are one of your top headaches, Database Savings Plans are a rare chance to convert more of that into planned, contractual discounts instead of hoping usage behaves.

Think of Database Savings Plans as a way to treat more of the data layer like other contracted cost structures that finance leaders already manage, such as long-term vendor agreements or committed volume contracts.

How to Think About Commitments Across Compute and Data

Companies can now commit spend across compute through Savings Plans and Reserved Instances, and eligible databases and data services through Database Savings Plans and certain remaining reservation programs. The total amount of committable spend has increased.

That creates more opportunity, and also more ways to waste money if you do not look at compute and database commitments as a single portfolio.

The main risks are straightforward:

• Under-commit, and too little committed spend leaves a large portion of usage at higher on-demand rates.
• Over-commit, and too much committed spend means paying for discounts you do not fully use. That shows up as a form of waste in COGS.

Buying in silos creates another problem. If compute, databases, and other services each have their own unmanaged commitments, the company can pay for commitments that sit partially unused while leaving other parts of the bill uncovered.

There's also the issue of ignoring existing commitments. AWS only applies one type of discount to each unit of usage. If you add Database Savings Plans on top of existing RIs or Savings Plans without modeling them together, some commitments can remain underutilized.

There is more opportunity to save on AWS today, and also more ways to waste money if you do not look at compute and database commitments as a single portfolio.

This is why Cloud Capital treats commitments across compute and databases as one portfolio decision instead of a set of separate technical choices.

Cloud Capital Helps With AWS Database Savings Plans

Once you see the opportunity in Database Savings Plans, the hard part is sizing and managing commitments without creating new risk or new work for your team. This is where Cloud Capital comes in.

Cloud Capital acts as a financial partner that turns AWS commitment programs, including Database Savings Plans, into lower and more predictable cloud COGS. We sign and manage long-term commitments with AWS on your behalf. You pay Cloud Capital for your actual AWS usage at agreed discounted rates, and Cloud Capital carries the obligation to AWS.

In practical terms, that means you gain the economic benefits of commitments on your data layer and compute while Cloud Capital absorbs the risk of over-commitment at the AWS level.

The goal is simple: increase overall discount coverage on the right workloads, minimize money spent on commitments you do not fully use, and smooth the profile of your cloud COGS over time.

What CFOs Should Do Next

Start by asking your team a few questions:

• How much of our AWS bill comes from databases and data services that are eligible for Database Savings Plans?
• Of that amount, how much appears stable enough over the next 12 months to consider commitments?
• How are we managing AWS commitments today across compute and databases? Is there a unified view or separate decisions by team?
• Do we have any underutilized commitments today?

If you already work with Cloud Capital, ask your contact how Database Savings Plans can be incorporated into your commitment portfolio, and what additional savings and margin improvements may be available in the data layer.

If you’re evaluating options, have Cloud Capital use your existing AWS billing data to estimate how much incremental savings and margin improvement Database Savings Plans and portfolio based commitment management could unlock over the next 12 months. 

Book time with our team.

Database Savings Plans are a significant new lever on a large, stable cost line. Cloud Capital is set up to translate that lever into concrete, measurable improvements in COGS and margin.