RDS Extended Support

Understand when (and when not) to rely on RDS Extended Support for out-of-date engine versions.

Why it matters

RDS Extended Support lets you keep running older major engine versions past their standard end-of-support date, in exchange for an additional per-vCPU charge.1 It can reduce upgrade pressure in the short term, but it also adds a new recurring cost line and defers necessary modernization work.

How Extended Support works

  • Scope – Available for specific MySQL and PostgreSQL major versions for up to three years beyond the standard support window.1
  • Enablement – You enable Extended Support at create/restore time; when the standard support period ends, eligible DB instances automatically transition into Extended Support without a separate outage event.1
  • What you get – Continued security updates for critical/high CVEs and critical bug fixes, plus the ability to open support cases under the usual RDS SLAs.1

If you do nothing for the full Extended Support period, RDS can ultimately upgrade the major engine version for you, so this should be treated as a temporary safety net, not a permanent operating mode.

Cost characteristics

  • Extended Support is billed in addition to normal RDS instance, storage, and I/O charges.
  • Pricing is per vCPU-hour; example public pricing shows per-vCPU rates that increase over the three-year Extended Support window, with the third year typically the most expensive.2
  • For large instance sizes or fleets of databases, this uplift can become very expensive very quickly, because you pay the surcharge on every vCPU-hour.

Because of this, Extended Support should generally be avoided if at all possible and treated as a last-resort, short-term risk and cost mitigation tool while you complete upgrades, not as a normal operating mode.

When Extended Support might make sense

Extended Support can be reasonable when:

  • You have critical production workloads on older engine versions and cannot safely complete a major upgrade before standard support ends.
  • Application or driver compatibility work is non-trivial and you need extra time to test and validate the new engine version.
  • The cost of Extended Support for a limited period is clearly lower than the risk and effort of rushing an upgrade.

When to avoid relying on Extended Support

Extended Support is a poor fit when:

  • You are early in the support window for your current engine version and have ample time to plan an upgrade.
  • You have many instances or high-vCPU footprints, and the incremental per-vCPU charges would significantly increase your run-rate costs.
  • You have already delayed upgrades multiple times and risk treating Extended Support as a substitute for lifecycle management rather than a bridge.

In these cases, investing in planned upgrades and automation usually provides better long-term cost and operational outcomes.

Practical approach

  1. Track engine version lifecycles

    • Maintain an inventory of RDS instances and their engine versions, and compare them against AWS’ published standard support and Extended Support timelines.1

  2. Prioritize upgrades

    • Use the timelines to prioritize upgrades for engines approaching end-of-support, focusing first on the highest criticality and highest vCPU instances.

  3. Use Extended Support selectively

    • If you must use Extended Support, time-box it: decide in advance how long you are willing to pay the premium while upgrades are completed, and monitor both cost and progress.

  4. Automate version management

    • Incorporate engine version tracking and upgrade planning into your regular operations (for example, via IaC, configuration management, or internal lifecycle policies) so you rely on Extended Support only in exceptional cases.

Resources

Footnotes

  1. Amazon RDS Extended Support documentation ↩ ↩2 ↩3 ↩4 ↩5

  2. Example cost breakdowns in MySQL 5.7, AWS, and Extended Support ↩