Amazon RDS Support: Expert 24×7 DBA Cover for 8 RDS and Aurora Engines

The practical consequence is that AWS Support and Amazon RDS Support answer different questions. AWS Support confirms that the instance, the storage volume and the Multi-AZ pair are healthy. It does not explain why a checkout query that took 40 milliseconds last month now takes four seconds, why autovacuum cannot keep up with one table, or why the replica you promote during a failover is missing the last few minutes of binlog. Most of our clients hold both AWS Support and Amazon RDS Support, and the escalation path between them is written into the runbook.

Everything Amazon RDS Support recommends is anchored in a named measurement: a Database Insights wait-event profile, a pg_stat_statements or performance_schema ranking, a CloudWatch metric, or a timed drill. Engine and feature coverage follows the Amazon RDS User Guide, and the deprecation calendar for every engine is re-verified at the start of each Amazon RDS Support engagement rather than recalled.

The Extended Support arithmetic is simple and still surprises people in every Amazon RDS Support assessment we run. On the published RDS for PostgreSQL rate for US East (Ohio), a Multi-AZ DB instance with 8 vCPUs carries 16 billable vCPUs, so Extended Support adds 16 × 730 × $0.100, about $1,168 a month in years one and two and double that from year three. That is an illustrative calculation on AWS's published rate, not a quote; your Region, engine and instance mix set the real number.

Three dates matter most right now. RDS for MySQL 8.0 left standard support on 2026-07-31 and bills Extended Support until 2029-07-31, per the RDS for MySQL version calendar. RDS for MariaDB 10.6 reaches end of support on 2026-12-31 with no paid runway, as the RDS for MariaDB version page shows. RDS for PostgreSQL 14 leaves standard support on 2027-02-28, according to the RDS for PostgreSQL release calendar.

The script below is the first thing Amazon RDS Support runs in a new account. It lists every instance in a Region with its engine version, vCPU count, billed copies, end-of-standard-support date and an estimate of the current monthly Extended Support charge. It is read-only and takes the rate as an input, because rates differ by Region and year.

#!/usr/bin/env python3
# rds_es_exposure.py — read-only: estimates Extended Support exposure for every RDS/Aurora instance in a Region.
# Needs rds:DescribeDBInstances and ec2:DescribeInstanceTypes. Rates and dates are inputs, not facts baked in:
# re-check both against the AWS release calendars and the pricing page for your Region before quoting a number.
import sys, datetime, boto3

REGION = sys.argv[1] if len(sys.argv) > 1 else "us-east-2"
RATE = float(sys.argv[2]) if len(sys.argv) > 2 else 0.100   # USD per vCPU-hour, years 1-2 (published, US East Ohio, RDS PostgreSQL)
EOSS = {                                                     # end of standard support, from the AWS calendars (2026-09-30)
    ("postgres", "11"): "2024-02-29", ("postgres", "12"): "2025-02-28", ("postgres", "13"): "2026-02-28",
    ("postgres", "14"): "2027-02-28", ("postgres", "15"): "2028-02-29", ("postgres", "16"): "2029-02-28",
    ("mysql", "5.7"): "2024-02-29",   ("mysql", "8.0"): "2026-07-31",   ("mysql", "8.4"): "2029-07-31",
}
rds, ec2 = boto3.client("rds", region_name=REGION), boto3.client("ec2", region_name=REGION)
vcpu_cache = {}

def vcpus(db_class):
    ec2_type = db_class.removeprefix("db.")
    if ec2_type not in vcpu_cache:
        try:
            info = ec2.describe_instance_types(InstanceTypes=[ec2_type])["InstanceTypes"][0]
            vcpu_cache[ec2_type] = info["VCpuInfo"]["DefaultVCpus"]
        except Exception:
            vcpu_cache[ec2_type] = None          # serverless or classes without an EC2 twin: report, do not guess
    return vcpu_cache[ec2_type]

today = datetime.date.today().isoformat()
print(f"{'instance':32} {'engine':18} {'version':10} {'vCPU':>4} {'copies':>6} {'EOSS':10} {'USD/month':>10}")
for page in rds.get_paginator("describe_db_instances").paginate():
    for db in page["DBInstances"]:
        engine = db["Engine"].replace("aurora-postgresql", "postgres").replace("aurora-mysql", "mysql")
        major = db["EngineVersion"].split(".")[0] if engine == "postgres" else ".".join(db["EngineVersion"].split(".")[:2])
        eoss = EOSS.get((engine, major), "-")
        cpu = vcpus(db["DBInstanceClass"])
        copies = 2 if db.get("MultiAZ") else 1  # Multi-AZ DB instance bills the standby; cluster members are listed individually
        cost = cpu * copies * 730 * RATE if (cpu and eoss != "-" and eoss < today) else 0.0
        print(f"{db['DBInstanceIdentifier'][:32]:32} {db['Engine'][:18]:18} {db['EngineVersion'][:10]:10} "
              f"{cpu or 0:>4} {copies:>6} {eoss:10} {cost:>10,.0f}")

On PostgreSQL engines Amazon RDS Support ranks statements by total time rather than by mean, because the query that runs forty thousand times at 30 milliseconds usually matters more than the report that runs once at four seconds. The same session checks transaction-ID age per database, which is the one PostgreSQL failure that RDS will not rescue you from.

-- RDS for PostgreSQL / Aurora PostgreSQL: where the time goes, and how close each database is to wraparound
SELECT
    queryid,
    calls,
    ROUND(total_exec_time::NUMERIC / 1000, 1)  AS total_s,
    ROUND(mean_exec_time::NUMERIC, 2)          AS mean_ms,
    shared_blks_read,
    LEFT(query, 80)                            AS query_head
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

SELECT
    datname,
    AGE(datfrozenxid)                                        AS xid_age,
    ROUND(100.0 * AGE(datfrozenxid) / 2147483648, 1)         AS pct_of_wraparound_limit
FROM pg_database
ORDER BY xid_age DESC;

On MySQL-family engines the Amazon RDS Support equivalent is the statement digest table in performance_schema, ranked the same way. Rows examined against rows sent is the fastest index-health signal we know on InnoDB, and it is the column we sort by second.

-- RDS for MySQL / MariaDB / Aurora MySQL: statement digests ranked by total time (timers are in picoseconds)
SELECT
    schema_name,
    LEFT(digest_text, 80)                    AS digest_head,
    count_star                               AS execs,
    ROUND(sum_timer_wait / 1e12, 1)          AS total_s,
    ROUND(avg_timer_wait / 1e9, 2)           AS avg_ms,
    sum_rows_examined,
    sum_rows_sent
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 15;