Contents
Key takeawaysDo Savings Plans cover RDS?How RDS and Aurora pricing worksFour pricing changes, rankedReserved Instance coverageAurora I/O-Optimized crossoverEngine and configuration choicesNon production spendPrice first, migrate laterWhat we have seenCheck your own positionDatabase spend and the commitmentWhat to do nextFAQCompute Savings Plans do not touch RDS or Aurora, and the newer Database Savings Plan discounts steady instances far less than a Reserved Instance. Close coverage gaps, test Aurora I/O-Optimized and clean up non production before you commit.
- Compute Savings Plans skip databases. They cover EC2, Fargate and Lambda only, so RDS and Aurora need a discount of their own.
- Reservations still discount deepest. Database Savings Plans, launched in December 2025, top out at 20 percent on provisioned instances, while RDS Reserved Instances reach up to 69 percent.
- Coverage runs far below need. Production databases we benchmarked held 40 to 60 percent Reserved Instance coverage, well short of what steady workloads justified.
- Aurora I/O-Optimized is the second fix. Test it on every cluster where I/O charges pass roughly a quarter of Aurora spend, because it folds I/O into the instance price.
- Non production spend has no owner. Schedule and rightsize idle test and development instances before sizing any commitment.
- Pricing fixes come first. Pricing changes landed in under a quarter, while engine migrations took 9 to 18 months and stalled about half the time.
Do Savings Plans cover RDS and Aurora?
Compute Savings Plans do not. They discount EC2, Fargate and Lambda and apply 0 percent to RDS and Aurora, yet nothing on the invoice says so. Until December 2025 the only commitment discount for a database instance was a Reserved Instance.
On December 2, 2025, AWS launched Database Savings Plans. They cover Aurora, RDS and the other AWS database services, run for one year, and need no upfront payment. That is a real change, but it does not make the old assumption safe.
Why a Database Savings Plan does not replace Reserved Instances
The discount is shallower, as the table below shows. A provisioned database that runs every hour of the year is still cheaper on a reservation, and the plan runs for one year only.
- Instance generation. Database Savings Plans cover Generation 7 and newer instances only. A fleet still on db.r5 or db.r6g gets nothing from them.
- No stacking. A Database Savings Plan and a Reserved Instance cannot discount the same workload.
- License charges. For SQL Server the plan discounts the instance price only. Windows and SQL Server license charges stay at on demand rates.
- Where the plan fits. Aurora Serverless v2 and fleets that will change engine, family or Region during the year.
| Compute Savings Plan | Database Savings Plan | RDS and Aurora Reserved Instance | |
|---|---|---|---|
| Covers RDS and Aurora | No | Yes, Generation 7 and newer | Yes, all current instance families |
| Term | 1 or 3 years | 1 year | 1 or 3 years (No Upfront is 1 year only) |
| Top discount AWS quotes | Not applicable | Up to 20 percent provisioned, up to 35 percent serverless | Up to 69 percent (RDS); Aurora up to 45 percent for 1 year and 66 percent for 3 years |
| Best fit | Compute | Serverless and changing fleets | Steady production instances |
The compute side of this choice is in Savings Plans versus Reserved Instances.
Negotiating AWS 3: The Discount Stack
How is AWS RDS and Aurora pricing built?
An RDS or Aurora bill is a stack of separate meters, and commitment discounts reach only part of it. The meter that is growing tells you which fix comes first.
- Instance hours. The largest meter, charged for each primary, Multi-AZ standby and read replica.
- Storage. RDS bills the storage you allocate. Aurora bills what the cluster uses, and on current versions that falls when you drop tables.
- I/O. Aurora Standard charges $0.20 per million read and write requests. Aurora I/O-Optimized removes that meter in exchange for higher instance and storage rates.
- Backups. Backup storage beyond the free allowance and manual snapshots keep billing, even while an instance is stopped.
- License included. For Oracle and SQL Server, the commercial license can sit inside the hourly rate.
- Extended Support. An engine version past its end of standard support adds a per vCPU hour charge from the following day. RDS for MySQL 8.0 moved onto Extended Support on August 1, 2026.
The storage and I/O differences are covered in our RDS for MySQL and Aurora comparison.
AWS RDS and Aurora negotiation guide
The coverage model, the Aurora crossover worksheet and commitment sizing for the database line.
Get the white paper →Which pricing changes cut the database bill most?
Four changes, ranked by the impact we observed, do most of the work. None of them needs an engine migration.
| Change | Typical reduction | Effort | Where it applies |
|---|---|---|---|
| Reserved Instance coverage | 25 to 45 percent against on demand | A purchase order | Every steady state database |
| Aurora I/O-Optimized | 25 to 40 percent | A configuration change | I/O heavy Aurora workloads |
| Graviton instances | 10 to 20 percent off compute | An instance family change | MySQL, PostgreSQL, MariaDB |
| Non production cleanup | 20 to 35 percent of that tier | Scheduling and rightsizing | Development, test, sandbox |
Start with Reserved Instance coverage. It is pure price, it needs no engineering, and a coverage review takes about a week. Nothing else on the list is as cheap or as certain. The Aurora configuration switch comes second, because its crossover point is predictable.
How much Reserved Instance coverage should production databases carry?
Steady state production databases usually justify 80 to 90 percent Reserved Instance coverage. In the accounts we benchmarked, actual coverage sat at 40 to 60 percent, and the gap billed at on demand rates inside a total that looked optimized.
The rest stays on demand on purpose, to absorb instances you expect to resize or retire during the term.
A worked example of closing the coverage gap
Say your production RDS and Aurora instances would cost $60,000 a month at on demand rates, and your reservations average a 35 percent discount. The table compares today's 50 percent coverage with 85 percent.
The third row buys the same 85 percent as a Database Savings Plan at an assumed 15 percent, the choice you face each time a reservation expires.
| Scenario | Usage covered | Cost of covered usage | Uncovered, at on demand | Monthly bill |
|---|---|---|---|---|
| 50 percent Reserved Instance coverage (today) | $30,000 | $19,500 | $30,000 | $49,500 |
| 85 percent Reserved Instance coverage | $51,000 | $33,150 | $9,000 | $42,150 |
| 85 percent Database Savings Plan at 15 percent | $51,000 | $43,350 | $9,000 | $52,350 |
Raising coverage saves $7,350 a month, or $88,200 a year, without touching a single database. Buying the plan instead would leave the bill $2,850 a month above even today's partly covered position.
Reserved Instance terms that shape the purchase
- Size flexibility. RDS Reserved Instances flex across sizes within a family for Aurora, MySQL, MariaDB, PostgreSQL, Db2 and Oracle BYOL. License included Oracle and SQL Server do not, so buy those at the exact size.
- Multi-AZ. The reserved rate applies to Single-AZ and Multi-AZ usage of the same engine and instance family.
- Payment options. No Upfront is sold on a one year term only. A three year term needs Partial Upfront or All Upfront.
- No exit. RDS Reserved Instances cannot be transferred, sold or cancelled. Buy against the rightsized fleet you will keep.
When does Aurora I/O-Optimized pay for itself?
It usually pays once I/O charges pass roughly a quarter of your Aurora spend. Aurora Standard bills compute, storage and I/O separately. In US East (N. Virginia), I/O-Optimized drops the I/O meter, charges about 30 percent more per instance hour, and bills storage at $0.225 per GB month instead of $0.10.
On I/O heavy workloads the switch cut Aurora bills 25 to 40 percent in the accounts we reviewed, in line with AWS's own guidance.
A worked example of the crossover
Take three hypothetical Aurora clusters, each holding 10,000 GB. All figures are monthly.
| Monthly cost | Light I/O | Borderline | Heavy I/O |
|---|---|---|---|
| Standard: instances | $10,000 | $8,000 | $6,000 |
| Standard: storage at $0.10 per GB | $1,000 | $1,000 | $1,000 |
| Standard: I/O at $0.20 per million | $2,000 | $3,000 | $8,000 |
| Standard total | $13,000 | $12,000 | $15,000 |
| I/O share of spend | 15 percent | 25 percent | 53 percent |
| I/O-Optimized: instances, about 30 percent higher | $13,000 | $10,400 | $7,800 |
| I/O-Optimized: storage at $0.225 per GB | $2,250 | $2,250 | $2,250 |
| I/O-Optimized total | $15,250 | $12,650 | $10,050 |
| Result of switching | $2,250 more | $650 more | $4,950 saved (33 percent) |
The borderline cluster sits exactly on the rule of thumb and still loses $650 a month by switching, which is why each cluster needs its own test.
At these US East (N. Virginia) rates, the break even sits where I/O cost equals 30 percent of instance cost plus 125 percent of storage cost. For the borderline cluster that is $3,650 of I/O a month, so storage heavy clusters cross over later.
Switching rules to know before you test
- You can move a cluster from Standard to I/O-Optimized once every 30 days, and back to Standard at any time.
- On NVMe based instance classes the switch restarts the engine, so book a maintenance window. Other classes switch without downtime.
- Existing Aurora Reserved Instances keep applying after the switch.
- Measure I/O per cluster with the CloudWatch metrics VolumeReadIOPs and VolumeWriteIOPs, which give the request count for each cluster directly.
What else in Aurora and the engine choice changes the bill?
Most of the remaining variance comes from settings chosen at build time and never revisited.
- Serverless v2 floor. Serverless v2 suits spiky workloads. A floor set too high erases the benefit, since a steady workload on a high ACU floor costs more than a reserved provisioned instance doing the same job.
- Storage growth. Storage scales automatically, which makes archive and partition discipline a cost control rather than housekeeping.
- Read replicas. Every replica is billed compute. Review replica counts each quarter against actual read traffic.
- Graviton. Open source engines on Graviton are the lowest cost stable state on the platform, with no licensing question attached.
- Engine version. Track end of standard support dates next to reservation expiries, so upgrades land before Extended Support charges start.
License included or bring your own license?
License included puts the Oracle or SQL Server license into the hourly rate, so you pay for it again every hour the instance runs. In return you get a clean compliance position on those workloads.
BYOL consumes licenses you already own but keeps those workloads inside the vendor's audit perimeter. Many accounts pay license included while holding shelfware BYOL would have consumed, so run both models against your license shelf before renewal. The Oracle side is in Oracle Database licensing on AWS.
How much of the RDS line is non production spend?
Idle and oversized development and test instances made up 25 to 35 percent of the RDS line before cleanup. The tier persists because it has no owner.
Production databases have teams who defend them. A test instance created for a project that ended has no advocate and no accuser, so it runs until someone removes it, and until then it counts as demand in the next commitment forecast.
What scheduling can and cannot do
- Seven day limit. A stopped RDS instance restarts automatically after 7 days, so stopping needs a scheduler that repeats the stop.
- Charges that continue. Stopping ends instance hour charges. Provisioned storage, Provisioned IOPS and backup storage keep billing.
- Instances that cannot stop. An instance with a read replica, a read replica itself, and RDS for SQL Server in Multi-AZ cannot be stopped. Those need rightsizing or deletion.
- Serverless for test. Since November 2024, Aurora Serverless v2 accepts a minimum of 0 ACUs and pauses itself when connections stop, which suits test databases used a few hours a week.
Should you migrate engines to cut the database bill?
Only after the pricing changes are done. In the accounts we benchmarked, Reserved Instance coverage, the Aurora configuration switch and non production cleanup recovered 25 to 45 percent of the database line in under a quarter with no project risk. Engine migrations took 9 to 18 months and stalled about half the time.
Why we would not start with a switch to open source
The usual advice is to start with an engine migration to open source and treat everything else as noise. We think that gets the order wrong. A migration can be the right strategic call, but its savings arrive only if the project finishes.
Price the current fleet first. Those savings land within a quarter and force the migration case to beat an optimized baseline. Let the migration stand on strategy, portability or license exit.
What have we seen in recent AWS database reviews?
Across roughly 20 to 30 AWS database environments we benchmarked in 2024 and 2025, the database line was the least optimized block of the bill. Three patterns repeated.
- Assumed coverage. A compute Savings Plan was assumed to cover databases, so the discount question was treated as closed.
- Coverage never measured. Reserved Instance coverage was never compared with steady state hours, so no one saw how far it trailed what the workloads justified.
- Forecasts built on waste. Commitment forecasts used the unoptimized run rate, idle test and development instances included.
The first pattern is easy to repeat with the new plans, because buying a Database Savings Plan also feels like closing the question.
How do you check your own RDS and Aurora position?
Start in Cost Explorer and finish in CloudWatch. Together these fit inside the week the coverage review takes.
- Reserved Instance coverage report. In Cost Explorer, filter to Amazon RDS and read coverage by instance family and engine. Compare it with the instances that ran every hour of the last quarter.
- Reservation usage. The companion Cost Explorer report shows reservations you pay for but no longer use, usually after a resize or engine change.
- Savings Plans recommendations and Purchase Analyzer. Model a Database Savings Plan against recent usage before anyone buys one.
- Compute Optimizer. Gives rightsizing recommendations for RDS for MySQL, RDS for PostgreSQL and Aurora.
- CloudWatch. VolumeReadIOPs, VolumeWriteIOPs and VolumeBytesUsed per Aurora cluster for the I/O test, and CPUUtilization and DatabaseConnections to find idle test instances.
- RDS console. The engine version of each instance, checked against the RDS release calendar for end of standard support dates.
How should database spend feed the AWS commitment?
Database spend draws down the commitment like any other service, so the database growth curve belongs in the commitment model. Build that curve after rightsizing, never before.
Commit against unmanaged database growth and you pay for the waste twice, once in the bill and once in the commitment sized around it.
Price the line, rebaseline, then commit. Commitment sizing sits in our renewal strategy, the support line in the support brief, and the year round controls in the vendor management guide.
| When | What to do | What it produces |
|---|---|---|
| Week one | Coverage review. Close the gap on everything that runs continuously. | A reservation purchase list |
| Month one | Configuration and cleanup. Test the Aurora I/O crossover, move supported engines to Graviton, and schedule or rightsize the non production tier. | An optimized run rate |
| Before the commitment | Rebaseline, then build the three year database forecast on the optimized run rate. | A database forecast you can sign against |
| Every quarter after | Check replica counts, reservation expiries and engine end of support dates. | Coverage that stays in range |
What to do next
- Measure coverage. Filter the Reserved Instance coverage report to RDS and close the gap on steady state hours before anything else.
- Assign each workload an instrument. Keep steady provisioned instances on Reserved Instances, and put serverless and changing Generation 7 fleets on a Database Savings Plan.
- Test the Aurora I/O crossover per cluster. Switch where the break even confirms it.
- Move supported engines to Graviton. Review read replica counts against actual read traffic at the same time.
- Schedule and rightsize non production. Delete what has no owner.
- Check engine versions. Upgrade anything approaching end of standard support before Extended Support charges begin.
- Rebuild the commitment forecast on the optimized run rate. Hold reservation purchases and the commitment discussion together. The AWS practice runs the model with you, and the wider library sits in the AWS hub.
Frequently asked questions
Do Savings Plans cover RDS and Aurora?
Compute Savings Plans do not. Database Savings Plans, launched on December 2, 2025, do, on a one year term with no upfront payment and only for Generation 7 and newer instances. Before that launch, assuming the compute plan covered databases was the single largest miss we found on AWS database bills.
What Reserved Instance coverage should production databases hold?
Usually 80 to 90 percent for databases that run every hour. Leave uncovered anything you plan to upgrade to a newer generation or move to Graviton within the term, because an RDS Reserved Instance cannot be cancelled or sold.
When does the Aurora I/O-Optimized configuration pay?
When your monthly I/O charge exceeds about 30 percent of your instance cost plus 125 percent of your storage cost, at US East list rates. Test cluster by cluster, since one busy cluster can justify the switch while its neighbors stay on Standard, and you can switch back at any time.
How much of the RDS line is non production waste?
Before cleanup it was 25 to 35 percent of the RDS line in the accounts we benchmarked. The quickest finds are test databases with flat CPU for weeks, replicas left behind after a project, and test instances sized to match production.
Is an engine migration the best way to cut the database bill?
Not for savings alone. A migration can make sense for portability or to exit a commercial license, but measure its business case against the fleet after the pricing fixes. That comparison usually shrinks the projected saving and changes the priority.
What does license included cost against BYOL?
License included costs more per hour because the Oracle or SQL Server license is inside the rate, and for SQL Server that portion gets no Database Savings Plan discount. BYOL is cheaper per hour when you own spare licenses, but those deployments stay subject to the vendor's audit rights.
Does Graviton reduce the database bill?
Yes, for MySQL, PostgreSQL and MariaDB. Moving those engines to Graviton took 10 to 20 percent off compute with no licensing change. Do it before buying three year reservations, because a reservation bought on the old instance family will not follow the workload.
How does database spend affect the AWS commitment?
It draws down the commitment like any other service. Size the database share on the optimized run rate, and decide Reserved Instance purchases in the same discussion, since they change the run rate you are forecasting.