Every RDS for MySQL 8.0 database has been paying Extended Support since August 1, 2026, PostgreSQL 13 since March, and Aurora MySQL version 2 doubles its rate on December 1. What it costs, how to find it on your bill, the restore that quietly enrols you, and how to upgrade out.
When a major database version reaches the end of standard support on RDS or Aurora, AWS doesn't force an upgrade. It enrols the database in RDS Extended Support, security patches for a few more years, and starts charging for it the day after standard support ends. Nothing breaks and nothing asks for approval, which is exactly why it shows up months later as a line on the bill nobody recognises.
The charge is per vCPU per hour on provisioned instances, on top of the instance price. For RDS for MySQL in US East it is $0.100 per vCPU-hour in the first two years and $0.200 from year three. It applies to every instance running the old version — including the standby in a Multi-AZ deployment.
From the RDS for MySQL, RDS for PostgreSQL and Aurora MySQL release calendars, October 2026.
And two that are coming: RDS for PostgreSQL 14 leaves standard support on February 28, 2027 (the PostgreSQL community ends it on November 12, 2026), so charges start on March 1. Aurora MySQL version 3 — MySQL 8.0-compatible — runs on a longer calendar than RDS: standard support continues until April 30, 2028. If you run MySQL 8.0 on Aurora rather than RDS, you are not paying yet.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Cost Explorer: filter to RDS and group by usage type — Extended Support appears as its own usage type, separate from instance hours. Look across every account in the organisation; this tends to hide in the ones nobody watches.
Every instance reports its enrolment: aws rds describe-db-instances returns EngineVersion and EngineLifecycleSupport for each one. Run it per Region.
The RDS API also reports the support dates for each major engine version, which is easier to put in a scheduled check than a calendar reminder.
Restoring an old snapshot — for a test, an investigation, a staging refresh — creates a database on the old version, and by default it is enrolled in Extended Support and charged like any other. To stop that, create and restore with --engine-lifecycle-support open-source-rds-extended-support-disabled (EngineLifecycleSupport in the API, and in CloudFormation and CDK). Do it in the templates that create databases, not by hand.
RDS supports 8.0 to 8.4 directly, and 8.4 is in standard support until July 31, 2029. The change most likely to bite is authentication: 8.4 disables the mysql_native_password plugin by default, so older clients and drivers that can't speak caching_sha2_password fail to connect. Inventory your clients, upgrade drivers first, and test the application against a restored copy before anything else.
Skip versions rather than stepping through them: PostgreSQL 17 is in standard support until February 2030 and 18 until February 2031. Check extensions first — each has its own supported versions per engine release — and re-run ANALYZE after the upgrade, because planner statistics do not carry across.
RDS Blue/Green Deployments build an upgraded copy kept in sync with production, let you test against it, then switch over in about a minute. For most teams this is the safest way to take a major version upgrade, and it turns the decision from "when can we afford an outage" into "when have we finished testing".
Day 1: list every RDS and Aurora database across all accounts and Regions with its engine version, Extended Support status and monthly cost.
Day 2: set the Extended Support opt-out in every template that creates or restores databases.
Days 3–4: upgrade non-production first, with the application running against it; fix drivers, extensions and parameter groups.
Day 5: Blue/Green the production databases, cheapest-to-get-wrong first.
Then: a scheduled check that flags any version within six months of its end of standard support.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Every AWS Extended Support Charge in 2026–2027: RDS, Aurora, EKS, ElastiCache and OpenSearch
AWS now charges for running old versions on five managed services, each with its own formula: per vCPU for RDS and Aurora, six times the control plane rate for EKS, an 80–160% premium for ElastiCache, and up to the full instance price for old OpenSearch domains. The rates, the dates, and how to find every charge on your bill.
Read
Database Savings Plans vs RDS Reserved Instances: Which Commitment to Buy in 2026
Database Savings Plans cover Aurora, RDS, DynamoDB, ElastiCache and more with one hourly commitment, up to 35% off, on a one-year term with no upfront payment. RIs still discount more for workloads that will not change. How to choose, and how to avoid buying both for the same database.
Read
As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.