RDS extended support: priced per vCPU (2026)

RDS Extended Support is priced per vCPU per hour, which means the same out-of-support database costs four times more on a 16-vCPU instance than on a 4-vCPU one. It also enrols you automatically, and the setting that turns it off triggers a major version upgrade on the spot.

What is RDS Extended Support?

Paid time on a database version the community has stopped supporting. The RDS Extended Support documentation describes it as allowing you "to continue running a database on a major engine version past the RDS end of standard support date for an additional cost."

What you get for the money is narrower than standard support and worth reading before deciding it is a safety net:

• "Security updates for critical and high CVEs for your DB instance or DB cluster, including the database engine"
• "Bug fixes and patches for critical issues"
• "The ability to open support cases and receive troubleshooting help within the standard Amazon RDS service level agreement"

Critical and high only. A medium-severity CVE on an out-of-support engine is not covered, which makes Extended Support a migration runway rather than a destination. AWS frames it the same way: "This paid offering gives you more time to upgrade to a supported major engine version."

How is it priced?

Per vCPU per hour, and per ACU for serverless. From the Amazon RDS pricing page: "For provisioned instances on Amazon Aurora, RDS for MySQL, and RDS for PostgreSQL, RDS Extended Support is priced per vCPU per hour", and "For Aurora Serverless v2, RDS Extended Support is priced per Aurora Capacity Unit (ACU) per hour consumed by your database."

That model is the thing to internalise, because it is the opposite of how AWS prices the same idea for Kubernetes. Read the rates on the pricing page; the shape is what changes your decisions:

The per-vCPU model means consolidation makes it worse, not better. Moving three small out-of-support databases onto one large instance keeps the same total vCPU count and the same Extended Support bill. The only thing that reduces it is upgrading the engine or shrinking the instance, and Cost Optimization Hub does recommend on RDS instances, so a rightsizing recommendation there has a second, larger effect on this line than it appears to.

For the flat-fee comparison and the Kubernetes version calendar, see EKS extended support at $0.10 to $0.60 per cluster hour.

Does AWS enrol you automatically?

If you opted in at creation, yes, and then it charges from the next day. "If you enabled RDS Extended Support during the creation or restoration of a DB instance, then after the RDS end of standard support date, Amazon RDS will automatically enroll the DB instance in RDS Extended Support."

AWS's worked example makes the timing concrete: "the RDS end of standard support date for RDS for MySQL version 5.7 is February 29, 2024 ... In this case, Amazon RDS automatically enrolls your databases in RDS Extended Support on February 29, 2024, and you can continue to run RDS for MySQL version 5.7. Starting March 1, 2024, Amazon RDS automatically charges you for RDS Extended Support."

Note also what enrolment does not do: "Automatic enrollment into RDS Extended Support doesn't change the database engine and doesn't impact the uptime or performance of your DB instance." Nothing observable happens. The only signal is the bill.

What happens if you turn it off?

This is the sentence to read before touching the setting:

If you disable the enrollment status of a DB instance or DB cluster that is already past its standard support end date, the instance or cluster automatically upgrades to the next supported major version.

So on a database already past end of standard support, disabling Extended Support is not a billing change. It is a major version upgrade, initiated immediately. Anyone treating the flag as a cost lever on a running production database is scheduling an unplanned engine upgrade, and major version upgrades are the class of change that breaks application queries.

Before the end of standard support date, the same flag is harmless: you are choosing whether to enrol later. The behaviour changes depending on which side of the date you are on, and the documentation only states the dangerous half once.

The enrolment options at creation and restore time are documented separately, in creating a DB instance with Extended Support and restoring one, and the wider behaviour in the Extended Support overview.

The setting itself is one parameter, and the change is immediate: "You can also change the enrollment status of an existing DB instance or DB cluster at any time by modifying the EngineLifecycleSupport parameter using the AWS CLI or RDS API. This change takes effect immediately with no downtime. For Aurora and Multi-AZ DB clusters, modify the setting at the cluster level."

How long can you stay?

Three years, then AWS upgrades you regardless. "RDS Extended Support is available for up to 3 years past the RDS end of standard support date for a major engine version. After this time, if you haven't upgraded your major engine version to a supported version, then Amazon RDS will automatically upgrade your major engine version."

Three years is generous compared to the twelve months Kubernetes gets, and it is long enough that the deadline outlives the team that made the decision. Which is the real risk here: a per-vCPU charge accruing for three years on a database nobody owns any more.

How do you find out whether you are paying it?

Check the enrolment parameter across every instance and cluster, in every Region:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws rds describe-db-instances --region "$r" \
    --query 'DBInstances[].{id:DBInstanceIdentifier,engine:Engine,version:EngineVersion,
             class:DBInstanceClass,support:EngineLifecycleSupport}' \
    --output text 2>/dev/null | sed "s/^/$r  /"
done

Then confirm against the bill, because the parameter tells you the intent and the usage type tells you what is actually being charged:

SELECT line_item_usage_type,
       line_item_resource_id,
       SUM(line_item_usage_amount) AS vcpu_hours,
       SUM(line_item_unblended_cost) AS cost
FROM   cur
WHERE  billing_period = '2026-07'
  AND  line_item_product_code = 'AmazonRDS'
  AND  line_item_usage_type LIKE '%ExtendedSupport%'
GROUP  BY 1, 2
ORDER  BY cost DESC;

Dividing cost by vCPU-hours gives the effective rate, which is the quickest way to sanity-check the charge against the pricing page. If the query returns rows you did not expect, the version calendar is the next stop: the PostgreSQL release calendar and the MySQL version management page carry the end of standard support and end of Extended Support dates per version.

One thing this charge will never do is show up as a new service or a changed configuration. Like its Kubernetes equivalent, it is a different rate on the same resource, so a month-over-month service total moves with no usage change behind it. Comparing effective rates rather than totals is what surfaces it, the same technique as breaking apart EC2 - Other.