Amazon RDS Extended Support: the charge you get for not upgrading, and how to avoid it

When a MySQL or PostgreSQL major version reaches the end of standard support, Amazon RDS keeps it running but adds a per-vCPU charge on top of the instance price. Here is how to find affected databases and plan the upgrade.

Since 2024, Amazon RDS and Aurora no longer force an upgrade when a database engine's major version reaches the end of standard support. Instead, the database is enrolled in RDS Extended Support automatically and keeps running, and a new line appears on the bill: a charge per vCPU per hour, on top of the normal instance price. The rate goes up in the third year. On a database with 8 or 16 vCPUs, the extra charge can be as large as the instance itself.

Many teams only notice when the line shows up in Cost Explorer. This guide shows how to find the databases that are in Extended Support or about to enter it, how much it matters, and how to plan the upgrade.

Which versions are affected

Each engine major version has a published end of standard support date. MySQL 5.7, PostgreSQL 11 and Aurora MySQL version 2 (compatible with MySQL 5.7) were the first versions to move into paid Extended Support, and later versions follow on the dates in the AWS release calendars: Amazon RDS for MySQL release calendar, Amazon RDS for PostgreSQL release calendar and the Aurora equivalents in the AWS documentation. The dates move rarely, but check the calendar for your exact engine and version rather than relying on memory.

1. List your databases and their versions

Console: RDS › Databases, and add the Engine version column.

CLI (repeat in each region you use):

aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,Engine,EngineVersion,DBInstanceClass,EngineLifecycleSupport]' \
  --output table

aws rds describe-db-clusters \
  --query 'DBClusters[].[DBClusterIdentifier,Engine,EngineVersion,EngineLifecycleSupport]' \
  --output table

The EngineLifecycleSupport column shows open-source-rds-extended-support when a database is enrolled in Extended Support (the default for databases created since the feature started), and open-source-rds-extended-support-disabled when it was created with Extended Support turned off.

2. See what it costs you today

In Cost Explorer, filter by Service = Relational Database Service and group by Usage type. Extended Support charges appear as their own usage types containing ExtendedSupport. Grouping by Resource (with resource-level data turned on in Cost Explorer) shows which databases they belong to.

The cost scales with the instance's vCPU count, not with how busy the database is. A large, mostly idle reporting replica on an old version costs as much in Extended Support as the busiest production primary of the same size, so the replicas are often the cheapest place to start.

3. Plan the upgrade

A major version upgrade is the real fix. The safest way to do it on RDS is a blue/green deployment: RDS copies the database into a "green" environment, upgrades the copy, keeps it in sync through replication, and switches traffic over in about a minute when you are ready.

aws rds create-blue-green-deployment \
  --blue-green-deployment-name orders-db-upgrade \
  --source arn:aws:rds:us-east-1:123456789012:db:orders-db \
  --target-engine-version 8.0.39 \
  --target-db-parameter-group-name orders-mysql80

Before the switchover:

• Read the upgrade notes for the target version. MySQL 5.7 to 8.0 changes default authentication, reserved words and some SQL behaviour; PostgreSQL major upgrades can change query plans and need extensions upgraded.
• Create a parameter group for the new version with your current settings carried over; the old group can't be used with the new version.
• Test the application against the green environment, which has its own endpoint, before you switch.
• Switch over with aws rds switchover-blue-green-deployment in a quiet window, then keep the old environment for a few days before deleting it.

Upgrade the smaller, less critical databases first. They teach you what the larger ones will need.

4. Don't fall into it again

• Know the dates: put each engine's end of standard support date in your team calendar a year ahead, and plan upgrades like any other dependency update.
• Choose deliberately for new databases: --engine-lifecycle-support open-source-rds-extended-support-disabled on create-db-instance or create-db-cluster means a database that reaches the end of standard support is upgraded automatically instead of enrolled in Extended Support. That suits development and test databases, where a surprise upgrade is cheaper than a surprise bill.
• Stay on supported minor versions: turning on automatic minor version upgrades keeps databases current within a major version and makes the next major upgrade smaller.

Cloud Health Check flags every RDS and Aurora database running an engine version in paid Extended Support, or close to it, in each connected AWS account, together with a few hundred other cost and security checks. You can see a sample report on demo data without connecting a cloud account.

Questions about your own account? Email contact@parlak.us or try Cloud Health Check on sample data.