RDS Extended Support pricing: what you pay and how to exit

RDS Extended Support pricing has one number worth memorizing: $0.100 per vCPU-hour. That is the US East year one and two rate AWS quotes for a PostgreSQL or MySQL instance that stays on a major version past its RDS end of standard support date, metered like compute, billed beside the instance, out of reach of Reserved Instance discounts, and doubled in year three. Enrollment is automatic, so nobody in your organization has to approve the spend for it to start. As of October 2026 the meter is running for two large cohorts: RDS for PostgreSQL 13 since March 1, 2026, and RDS for MySQL 8.0 since August 1, 2026. Postgres 14 fleets join them on March 1, 2027.

What the meter bills, exactly

The unit is the vCPU-hour, and the count comes from the instance class, not from utilization. A db.m6g.2xlarge has 8 vCPUs whether it is saturated or idle, so it accrues 8 × $0.100 every hour it exists on an out-of-support major. AWS states the charge applies to every instance in a Multi-AZ deployment, which means the standby you cannot query is billed at the same rate as the primary. A read replica is its own DB instance running the same engine version, so it meters too.

Consider a team running one db.m6g.2xlarge Multi-AZ Postgres 13 database. That is 16 billed vCPUs: 16 × $0.100 × roughly 730 hours comes to about $1,168 per month, or roughly $14,000 per year, added to an instance whose behavior did not change in any way on March 1. In year three the same arithmetic doubles.

Two properties make this line item unusually slippery in cost reviews. First, Reserved Instances do nothing: the AWS pricing FAQ states that RI discounts do not apply because "RDS Extended Support charges are independent of instance charges." A fleet that looks fully covered by RIs can still grow an uncovered five-figure line. Second, the charge lands under its own usage type rather than inflating the instance rate. Vantage documents the format as Region-ExtendedSupport:Yr1-Yr2:PostgreSQL12, so a Cost Explorer view grouped by usage type finds it in seconds, while a dashboard that only tracks instance-hours never will.

The calendar decides when, not your configuration

Nothing about your instance opts you in. The engine version crosses a date in AWS's release calendar, RDS enrolls the database in Extended Support, and charges begin the day after the end of standard support. These are the dates that matter right now:

The MySQL 8.0 row deserves a pause. Community end of life was April 30, 2026, and RDS standard support ran through July 31, 2026, so every RDS MySQL 8.0 instance, the default engine version for most of a decade, has been accruing Extended Support charges since August 1. This is the largest cohort the program has ever enrolled at once, and for many teams it is the first time the line item appears on a bill nobody was watching for it.

Postgres 14 is next. Community support ends on November 12, 2026, RDS carries it under standard support through February 28, 2027, and the meter starts March 1, 2027.

Year three doubles the rate, and year four is not yours to schedule

Extended Support runs for up to three years past the end of standard support. In US East (Ohio), AWS quotes year three at $0.200 per vCPU-hour, double the year one and two rate. After the window closes, AWS's documentation is plain: if you have not upgraded, "Amazon RDS will automatically upgrade your major engine version." Postgres 11 shows the full arc: its Extended Support ends on March 31, 2027, at which point the remaining instances get upgraded on AWS's schedule, not their owners'.

That end state is the right frame for the whole program. Extended Support is a loan against an upgrade you still owe. You pay interest at $0.100 per vCPU-hour, the rate doubles after two years, and at the end of year three the principal, the upgrade itself, is collected by force, against whatever application compatibility issues you deferred, during a maintenance window you did not pick. What you buy in the meantime is real but narrow: patches for critical and high CVEs, critical bug fixes, and the ability to open support cases. New community minor versions are not part of it, because the community has stopped producing them.

How the charges stop, and the disable trap

Charges stop automatically when you upgrade to a major version under standard support or delete the database. There is no ticket to file and no toggle to remember after an upgrade, which is the one genuinely friendly part of the design.

The unfriendly part is the enrollment flag itself. Every instance carries an EngineLifecycleSupport attribute, and the value open-source-rds-extended-support means enrolled. Two behaviors around this flag surprise people. First, disabling it is only safe before the deadline: AWS documents that if you disable enrollment on an instance that is already past its end of standard support date, RDS automatically upgrades it to the next supported major version, effective immediately. Past the date, the setting works as a dead-man switch, not a billing opt-out. Second, the flag survives upgrades silently. AWS's own worked example is a MySQL 5.7 instance upgraded to 8.0 in July 2024: charges stopped, enrollment stayed enabled, and billing resumed on August 1, 2026 when 8.0 crossed its own date. The flag does not expire, so a fleet that paid for Extended Support once will pay again without any further decision.

The upgrade target is a pricing decision

Because charges restart whenever the target version ages out, how far you jump matters as much as whether you jump. A Postgres 13 fleet that upgrades to 14 in November 2026 stops paying for exactly four months; the meter restarts on March 1, 2027 when 14 enters its own Extended Support. AWS's charges page models precisely this trap with Postgres 11 and 12: upgrade in April 2024, charged again from March 1, 2025.

The arithmetic favors the longest jump your testing tolerates. On the current calendar, landing on Postgres 16 buys standard support through February 2029, 17 through February 2030, and 18 through February 2031. The jump is wider, but the width is mostly inventory work rather than risk, and the 14 to 18 path is well understood, including the statistics-preservation change in 18 that removes the worst part of the first post-upgrade hour. On the MySQL side the only standard-support target is 8.4, which runs through July 2029.

Audit the fleet before the invoice does

One command answers who is enrolled:

aws rds describe-db-instances \
  --query 'DBInstances[].{id:DBInstanceIdentifier,engine:Engine,version:EngineVersion,lifecycle:EngineLifecycleSupport}' \
  --output table

Run describe-db-clusters as well for Multi-AZ DB clusters, where the setting lives at cluster level. One reading note: the field reports enrollment, and enrollment alone costs nothing. An instance can show open-source-rds-extended-support while its version is still under standard support, in which case it is a future liability rather than a current charge. Cross-check the version against the release calendar, then check Cost Explorer grouped by usage type for anything containing ExtendedSupport to see what is billing today. In the console, the RDS Extended Support column in the database list shows the same thing once enabled under Preferences.

Cloud SQL now runs the same model

This program has stopped being an AWS peculiarity. Google's Cloud SQL enrolls MySQL and PostgreSQL instances in extended support automatically when a major version reaches its Cloud SQL end of life, three months after community EOL, has charged for it since May 1, 2025, and caps it at three years, after which instances are upgraded automatically during maintenance. The grace era in which a managed database could sit on an EOL major indefinitely at no extra cost is over across providers, and planning as if it will come back is the expensive assumption.

When paying is the right call

Extended Support is not a mistake in every column of the spreadsheet. Three situations justify it. A vendor application certified only against the old major, where the upgrade is blocked by someone else's test matrix. A database with a decommission date inside the window, where a year of fees is cheaper than a migration that will be thrown away. And a large estate being upgraded in sequence, where paying on the tail while the head moves is the alternative to doing twenty upgrades badly at once.

The common failure is none of these. It is the default path: nobody decides anything, enrollment happens on a calendar date, and the fee becomes a permanent fixture because it is too small to page anyone and too distributed to own. The test is simple: price the exit once. If a rehearsed upgrade removes $14,000 a year of fees, the meter rarely survives honest math past its first renewal. If a certification or a decommission date genuinely blocks the exit, pay, but as a line item with an owner and an end date rather than as a default.

Where Datapace fits

Everything above assumes you can answer two questions quickly: which databases are on which engine versions, and what depends on each one. In practice that inventory is the hard part. The instance list lives in AWS, the version calendar lives in AWS's docs, and the knowledge of what breaks if a major version moves lives in people's heads and stale wiki pages. Datapace is building the context layer between your databases and your AI: resolved meaning about the estate, validated by the people who own the data, with the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. An Extended Support audit is an estate question before it is a billing question; that inventory is the estate documentation use case.

Sources

1. AWS, Amazon RDS Extended Support with Amazon RDS (automatic enrollment, scope of updates, three-year limit, automatic major version upgrade afterward).
2. AWS, Amazon RDS Extended Support charges (charges begin the day after end of standard support, Multi-AZ standbys billed, charges stop on upgrade or delete and restart on the target version's date, disable behavior and the --engine-lifecycle-support CLI option).
3. AWS, Release calendar for Amazon RDS for PostgreSQL (PostgreSQL 11 through 18 standard support, year 1 and year 3 pricing start dates, Extended Support end dates).
4. AWS, MySQL on Amazon RDS versions (MySQL 5.7, 8.0 and 8.4 release calendar, including 8.0's August 1, 2026 year 1 pricing start).
5. AWS, Amazon RDS for PostgreSQL pricing ($0.100 per vCPU-hour year 1 example in US East (N. Virginia), $0.200 year 3 in US East (Ohio), Reserved Instance discounts not applying, all Multi-AZ instances charged).
6. AWS, Viewing the enrollment of your DB instances in Amazon RDS Extended Support (EngineLifecycleSupport values, enrollment versus charging, the MySQL 5.7 to 8.0 restart example).
7. Google Cloud, Cloud SQL extended support (automatic enrollment at Cloud SQL EOL, charges since May 1, 2025, three-year cap, automatic upgrade afterward).
8. Emily Dunenfeld, Vantage, Amazon RDS Extended Support Explained, February 27, 2025 (the Region-ExtendedSupport:Yr1-Yr2:PostgreSQL12 usage type format and per-region rate tables).