RDS Extended Support cost: lower the bill before the upgrade lands | CloudYali<br>Skip to main content<br>Back to Blog

Almost every team I talk to with an aging RDS cluster on Extended Support has the same story: the upgrade is on the roadmap, blocked by application work, and AWS is charging a per-vCPU surcharge that compounds while they wait. Most of those teams either don't know about the levers that work without the upgrade, or assume they have already been pulled. They usually haven't. Here is what the bill actually looks like, and what you can do about it before the upgrade lands.<br>What you are paying for, exactly<br>The fee itself is straightforward on paper. For RDS for MySQL and PostgreSQL on provisioned instances, AWS charges $0.10 per vCPU per hour during years one and two of Extended Support, and that doubles to $0.20 per vCPU per hour in year three. For Aurora Serverless v2, it is priced per Aurora Capacity Unit per hour at $0.085 in years one and two and $0.17 in year three (us-east-1 and us-east-2; rates vary slightly by region). It is an additive surcharge on top of your normal instance cost, billed for every hour the cluster is running, and it shows up as its own line item in your Cost and Usage Report under something like Region-ExtendedSupport:Yr1-Yr2:PostgreSQL12.<br>If you are on MySQL 5.7 or PostgreSQL 11, you have been getting hit at the year 1-2 rate since 2024, and as of March 1 2026, both versions rolled into year 3 pricing, which means the surcharge on those clusters doubled overnight. PostgreSQL 12 entered year 1 pricing in March 2025, so customers running that version are currently in the year 1-2 band. PostgreSQL 13 joined the year 1 band on March 1, 2026, so if you are running 13 the surcharge has been on your bill for the last two months and most teams have not noticed yet. After three years on Extended Support, the version is automatically force-upgraded.<br>The multiplier most teams underestimate<br>Here is where almost every team I talk to underestimates the size of the bill, including teams that already know about Extended Support and have factored it in.<br>The per-vCPU charge applies to every running database instance in the cluster. Not just the primary. That means the Multi-AZ standby is charged for its full vCPU count, every read replica is charged for its full vCPU count, and they all stack on the same Extended Support line in your CUR.<br>Take a fairly ordinary production setup. A 16 vCPU primary, one read replica at the same instance class, and Multi-AZ enabled. The instance count from the team's mental model is one. The vCPU count being billed on Extended Support is 48, because all three running instances carry the charge independently. At the year 1-2 rate, that is roughly $3,500 a month in surcharge alone, before any compute, before storage, before backups. At the year 3 rate, it is $7,000. None of it discounted by any commitment you might have signed.<br>What about RIs and Database Savings Plans?<br>Neither covers Extended Support. The surcharge is a separate CUR line billed independently of any commitment you have signed. RIs lock in compute, not the surcharge. Database Savings Plans, which AWS launched in December 2025, apply to instance usage in the same way and leave the surcharge at full rate.<br>There is also a quieter catch with DBSP that hurts Extended Support customers specifically. The plan covers eligible RDS usage on whatever instance you run, but the deepest combined savings come from running Graviton3 instances (M7g, R7g), which stack hardware price-performance gains on top of the DBSP discount. Graviton3 RDS classes require MySQL 8.0.28 or higher and PostgreSQL 13.4 or higher. If you are on Extended Support, your engine version is by definition too old for Graviton3, which means the most valuable form of DBSP coverage is locked behind exactly the upgrade you are trying to delay.<br>The levers that work without the upgrade<br>OK, so the bill is bigger than the version-upgrade timeline. What can actually be pulled while the upgrade is still on the roadmap? These are in rough order of impact-to-effort, but every cluster is different and the order of operations depends on your topology.<br>Right-size the cluster, but honestly

When right-sizing is safe, and when it is not. The instance role drives the decision more than any single utilization metric.The instinct here is to look at CPU on the primary and call it a day. CPU alone is a bad signal. The right diagnostic is sustained peak across four dimensions: CPU, memory pressure (freeable memory and buffer cache hit ratio together), IOPS utilization, and connection count against max_connections. If all four sit comfortably below the instance ceiling over a full month, including the edge cases that do not show up at the P99 mark but do show up at month-end batch, backup windows, schema migrations, and any quarterly reporting workload, there is room. If any one of them is touching the ceiling, leave the primary alone.<br>The replicas are usually...