AWS RDS Extended Support Is Doubling in 2026 — Here's What You Owe and How to Stop It

What AWS RDS Extended Support Is and Why It Exists

AWS RDS Extended Support is a paid programme that allows you to continue running end-of-life database engine versions on RDS after their standard maintenance window closes. When a database engine version reaches end of life, AWS stops releasing minor patches and security updates for it under the standard support model. Extended Support buys you continued security patches and engine bug fixes — at a cost — while you plan and execute the upgrade to a supported major version.

The programme exists because major version upgrades carry real risk and take real time, and AWS does not want to force mass outages by simply stopping patching overnight. The trade-off is deliberate: Extended Support is priced to make staying on old versions progressively more expensive, so teams have a financial incentive to upgrade rather than let technical debt compound indefinitely.

Which RDS Engine Versions Are in Extended Support Right Now

As of May 2026, the RDS engine versions in Extended Support include:

• MySQL 5.7: end of standard support October 31, 2023 — now in Year 3

• MySQL 8.0: end of standard support April 30, 2026 — now in Year 1

• PostgreSQL 11: end of standard support November 9, 2023 — now in Year 3

• PostgreSQL 12: end of standard support November 14, 2024 — now in Year 2

• PostgreSQL 13: end of standard support November 13, 2025 — now in Year 1

MySQL 8.0 entering Extended Support in April 2026 caught many teams off guard — it is a widely deployed version that engineers assumed was still current.

PostgreSQL 12 and 13 are also accruing Extended Support charges, though at Year 1 and Year 2 rates respectively.

If you are running any of these engine versions, you are paying Extended Support fees on every instance, every hour.

-- Query to check your RDS engine version from any PostgreSQL instance
SELECT version();

-- For MySQL:
SELECT VERSION();

-- In AWS CLI: list all RDS instances and their engine versions
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,Engine:Engine,Version:EngineVersion,Class:DBInstanceClass}' \
  --output table

How Much Extended Support Is Actually Costing You — The Math

Extended Support is charged per vCPU per hour on top of the normal instance cost. 7 and PostgreSQL 11. At Year 3, this doubles the effective cost for many instance types.

2xlarge has 8 vCPUs. 11 × 8,760 hours = $7,709 per year, per instance. A common production setup — two primary instances plus two read replicas — means 32 vCPUs and $30,835 per year in Extended Support fees alone.

4xlarge (16 vCPUs) costs $15,418/year in Extended Support. 7 clusters, the Extended Support fee applies to every instance in the cluster independently. To find your exact charges, open AWS Cost Explorer, filter by Service: Amazon Relational Database Service, and look for the usage type containing ExtendedSupport.

The line items will show your actual vCPU-hours being billed.

# Calculate your Extended Support cost
# Year 3 rate: $0.11/vCPU/hour

VCPUS_PER_INSTANCE=8          # db.r6g.2xlarge = 8 vCPUs
INSTANCE_COUNT=4              # 2 primaries + 2 read replicas
HOURS_PER_YEAR=8760
RATE=0.11

ANNUAL_COST=$(echo "$VCPUS_PER_INSTANCE * $INSTANCE_COUNT * $HOURS_PER_YEAR * $RATE" | bc)
echo "Annual Extended Support cost: $$ANNUAL_COST"
# Output: Annual Extended Support cost: $30835.20

# AWS CLI: find Extended Support line items
aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-05-01 \
  --granularity MONTHLY \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --metrics BlendedCost

Related: why your AWS RDS bill might be high, the AWS RDS cost optimization playbook, the Database FinOps guide

Path 1: In-Place Major Version Upgrade on RDS

The lowest-friction path to eliminating Extended Support charges is an in-place major version upgrade on RDS. AWS supports major version upgrades through the console, CLI, and Terraform for most engine combinations. 0 first).

For PostgreSQL 11, the supported paths include 11 → 13 → 15 → 16 or 11 → 14 → 16 depending on your current minor version. The upgrade process involves a brief outage — typically 5 to 20 minutes for the engine version switch itself, depending on database size and parameter group changes. AWS performs parameter group compatibility checks before the upgrade, and any incompatible settings must be resolved first.

The critical pre-upgrade steps are: run the AWS RDS Upgrade Prechecks, test the upgrade in a staging environment with a recent snapshot, and verify your application works against the target version before touching production. 0, the most common breaking changes are: removed functions (PASSWORD(), ENCODE(), DECODE()), changes to utf8mb3 vs utf8mb4 defaults, and stricter SQL mode by default.

# Pre-upgrade: create a snapshot
aws rds create-db-snapshot \
  --db-instance-identifier prod-mysql-57 \
  --db-snapshot-identifier pre-upgrade-snapshot-$(date +%Y%m%d)

# Run upgrade prechecks (MySQL 5.7 → 8.0)
aws rds describe-db-upgrade-prechecks \
  --db-instance-identifier prod-mysql-57 \
  --target-engine-version 8.0.36

# Perform the upgrade (applies during maintenance window)
aws rds modify-db-instance \
  --db-instance-identifier prod-mysql-57 \
  --engine-version 8.0.36 \
  --allow-major-version-upgrade \
  --apply-immediately  # remove this flag to schedule during maintenance window

Path 2: Migrate to Aurora — Bigger Jump, Bigger Payoff

r-class instances at meaningful I/O volume, migrating to Aurora during the upgrade is worth evaluating alongside a simple version bump. 0. Aurora PostgreSQL 16 is wire-compatible with PostgreSQL 16.

The migration eliminates Extended Support exposure on the current version and delivers architectural benefits: Aurora's distributed storage layer eliminates storage I/O bottlenecks, read replicas share storage and eliminate replication lag from write-heavy workloads, and failover completes in under 30 seconds instead of the 1–2 minute RDS failover. For I/O-intensive workloads, Aurora's storage architecture frequently reduces total AWS spend even at Aurora's higher per-instance pricing — because you eliminate provisioned IOPS and gp3 baseline costs. The migration path uses AWS Database Migration Service (DMS) for live data replication with minimal cutover downtime, or a logical dump-restore approach for smaller databases where a longer maintenance window is acceptable.

# Option A: Snapshot restore to Aurora (fast, ~30 min downtime for cutover)
# 1. Create final snapshot of RDS instance
aws rds create-db-snapshot \
  --db-instance-identifier prod-postgres-11 \
  --db-snapshot-identifier final-pre-aurora-migration

# 2. Restore snapshot to Aurora cluster
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier prod-aurora-cluster \
  --snapshot-identifier final-pre-aurora-migration \
  --engine aurora-postgresql \
  --engine-version 16.2

# 3. Add primary instance to the cluster
aws rds create-db-instance \
  --db-instance-identifier prod-aurora-primary \
  --db-cluster-identifier prod-aurora-cluster \
  --db-instance-class db.r8g.2xlarge \
  --engine aurora-postgresql

Related: our database engineering service

Path 3: Blue/Green Deployment for Zero-Downtime Upgrades

AWS RDS Blue/Green Deployments are the safest path for mission-critical databases that cannot tolerate a maintenance window. The Blue/Green feature creates a staging replica of your production database (Green), applies the major version upgrade to the Green environment, and then performs a switchover that redirects all connections with typically under 60 seconds of application interruption. The advantage over a direct in-place upgrade is that you can test the upgraded Green environment against real production traffic patterns — using read replica promotion or a shadow traffic approach — before committing to the switchover.

If the Green environment behaves unexpectedly, you can delete it without touching production. After switchover, the original Blue environment is retained as a rollback point. 0 and for RDS PostgreSQL cross-version upgrades.

The feature is included in standard RDS pricing — no additional charge beyond the doubled instance cost during the switchover period.

# Create a Blue/Green deployment for zero-downtime upgrade
aws rds create-blue-green-deployment \
  --blue-green-deployment-name mysql57-to-80-upgrade \
  --source arn:aws:rds:us-east-1:123456789:db:prod-mysql-57 \
  --target-engine-version 8.0.36

# Monitor the Green environment creation
aws rds describe-blue-green-deployments \
  --filters Name=blue-green-deployment-name,Values=mysql57-to-80-upgrade

# After testing Green environment, perform switchover
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-1234567890abcdef0 \
  --switchover-timeout 300  # seconds before rollback if switchover fails

How to Find Your Extended Support Exposure Before the Next Bill

The fastest way to audit your Extended Support exposure is through the AWS CLI combined with Cost Explorer:

• List every RDS instance: list every RDS instance and its engine version to identify which instances are on Extended Support versions

• Calculate the vCPU count: calculate the vCPU count for each instance using the instance class

• Multiply by the Extended Support rate: multiply by the appropriate Extended Support rate for the year of support you are in

AWS also provides a Cost Explorer filter specifically for Extended Support charges — filter by Usage Type containing 'ExtendedSupport' to see the exact dollar amount you paid last month.

For teams with multiple accounts, use AWS Organizations and the management account's Cost Explorer to aggregate across all member accounts.

Setting a Cost Explorer alert for the ExtendedSupport usage type gives you early warning if additional instances inadvertently end up on extended support versions.

# List all RDS instances with end-of-support engine versions
aws rds describe-db-instances \
  --query 'DBInstances[?contains(`["5.7","8.0","11","12","13"]`, EngineVersion)].{
    ID:DBInstanceIdentifier,
    Engine:Engine,
    Version:EngineVersion,
    Class:DBInstanceClass,
    MultiAZ:MultiAZ
  }' \
  --output table

# Check Extended Support charges in Cost Explorer (last 3 months)
aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-06-01 \
  --granularity MONTHLY \
  --filter '{
    "And": [
      {"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}},
      {"Dimensions":{"Key":"USAGE_TYPE_GROUP","Values":["RDS: Extended Support"]}}
    ]
  }' \
  --metrics BlendedCost

Related: what's new in PostgreSQL 18

One Client's $52,000 Annual Reduction in Six Weeks

A fintech client came to us after noticing their RDS bill had increased by $4,300/month between January and March 2026 without any infrastructure changes. 7 instances entering Extended Support Year 3. 2xlarge instances across two environments — production and staging — totalling 48 vCPUs.

11/vCPU/hour, the annual Extended Support charge was $46,217. Including the Year 2 charges from the previous 12 months, they had already spent over $23,000 on Extended Support before noticing the line item. Our engagement: Week 1, we ran upgrade prechecks on all six instances and identified three incompatible stored procedures using the deprecated PASSWORD() function.

0 upgrade on staging. Week 3, we upgraded production across two maintenance windows — three instances per window, 12 minutes each. Week 6, we upgraded the remaining read replicas and disabled Extended Support billing entirely.

Total downtime across both production maintenance windows: 24 minutes. xlarge rightsizing that delivered 18% better price-performance).