RDS extended support cost is a fee per vCPU-hour that AWS charges from the day after an engine version's end of standard support, on top of the instance; EKS charges six times the hourly price for a cluster in extended support, Cloud SQL has charged a fee per vCPU-hour for versions past their end of life since 2025-05-01, AKS requires the Premium tier for long-term support, and Azure Database for PostgreSQL bills extended support from 2026-09-01. The saving comes from the upgrade that ends the fee, or from a deliberate decision to pay it until a date. The fix belongs to the team that runs the database or cluster, because a major upgrade has to be tested.

Symptom

The bill shows a second line for the same resource beside the instance. On AWS it is, under AmazonRDS, a line whose lineItem/UsageType names extended support and the year band, beside the InstanceUsage line of the same lineItem/ResourceId, and under AmazonEKS the cluster hour at the extended support rate instead of the standard rate. On Azure it is the Premium tier's cluster management meter under Azure Kubernetes Service and, from 2026-09-01, an extended support meter under Azure Database for PostgreSQL. On Google Cloud it is a SKU of its own for extended support beside the vCPU and RAM SKUs of the Cloud SQL instance. The term is in the glossary under extended support; what the services charge regularly is in managed databases and containers and Kubernetes.

a second linea higher rateA database or cluster on aversion past itsstandard supportHow does itreach the bill?Beside InstanceUsage or thevCPU and RAM SKUs of thesame resource: extendedsupport with its year band,the extended support meter,a SKU of its ownThe EKS cluster hour at theextended support rate, theAKS Premium tier's clustermanagement meter
Extended support shows as a second line beside the instance or as a higher rate on the cluster hour

How to detect it

AWS

The engine versions and the enrolment status per instance and cluster:

aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,Engine,EngineVersion,EngineLifecycleSupport,DBInstanceClass,MultiAZ]' --output table
aws rds describe-db-clusters --query 'DBClusters[].[DBClusterIdentifier,Engine,EngineVersion,EngineLifecycleSupport]' --output table

EngineLifecycleSupport reads open-source-rds-extended-support or open-source-rds-extended-support-disabled. The fee starts the day after the end of standard support, applies to the standby of a Multi-AZ instance too, ends with the upgrade to a supported version or the deletion, and starts again when the target version later enters extended support itself; AWS lists for MySQL 5.7 in US East (Ohio) USD 0.100 per vCPU-hour in the first and second year and USD 0.200 in the third (read on 2026-10-21, extended support charges, RDS for MySQL pricing). On EKS a version gets 14 months of standard support and then 12 months of extended support, the cluster then costs USD 0.60 instead of USD 0.10 per hour, and the upgrade policy is EXTENDED by default (version lifecycle, EKS pricing):

aws eks describe-cluster --name <cluster> --query 'cluster.[version,upgradePolicy.supportType]'
aws eks describe-cluster-versions --query 'clusterVersions[].[clusterVersion,status,endOfStandardSupportDate,endOfExtendedSupportDate]' --output table

Trusted Advisor and Compute Optimizer do not check extended support. In billing data the case shows as the second line per resource (AWS Cost and Usage Report).

Azure

The clusters with version, tier and support plan, and the database servers with their major version:

az aks list --query "[].{name:name, rg:resourceGroup, version:kubernetesVersion, tier:sku.tier, plan:supportPlan}" -o table
az postgres flexible-server list --query "[].{name:name, rg:resourceGroup, version:version, state:state}" -o table

AKS offers one year of community support per version and then one year of long-term support, which requires the Premium tier and the AKSLongTermSupport support plan; a cluster whose version has left community support can no longer switch LTS off without first moving to a supported version (long-term support for AKS). Azure Database for PostgreSQL enrols servers on unsupported versions in extended support automatically from 2026-08-01, bills it from 2026-09-01 for running servers only and pro rata until the upgrade, and offers no opt-out other than the upgrade (extended support for PostgreSQL). Azure Advisor has no cost recommendation for it. In the cost export the case shows as the cluster's Premium meter or the server's extended support meter (Azure cost exports).

Google Cloud

The Cloud SQL instances with their version:

gcloud sql instances list --format="table(name,databaseVersion,settings.tier,settings.availabilityType,region)"

Google has charged extended support since 2025-05-01 for instances on major versions past their end of life, on top of the instance price, per vCPU and hour for dedicated cores, at a higher rate from the third year and without committed use discounts; the exit is the upgrade (extended support for Cloud SQL, Cloud SQL pricing). The recommenders do not rate the version. In the billing export the case shows as the extended support SKU per resource.name (Google Cloud billing export).

How to fix it

  1. Work out the fee per month per resource: vCPUs times hours times rate, times two for Multi-AZ, and estimate the upgrade effort beside it. The decision "upgrade or pay until a date" is taken with both figures and recorded; paying only comes with an end date.
  2. Plan the upgrade the way the provider provides it: on RDS a major upgrade in place or a blue/green deployment, after a test of extensions and parameters; on Aurora and RDS the enrolment can be switched off with aws rds modify-db-instance --db-instance-identifier <instance> --engine-lifecycle-support open-source-rds-extended-support-disabled, which lifts an instance past the support end to the next supported version at once. On EKS aws eks update-cluster-config --name <cluster> --upgrade-policy supportType=STANDARD, possible only while the cluster is in standard support, with an automatic upgrade at the end of standard support (disable extended support); otherwise aws eks update-cluster-version --name <cluster> --kubernetes-version 1.34 after upgrading add-ons and nodes. On AKS az aks upgrade --resource-group <rg> --name <cluster> --kubernetes-version <version> and then az aks update --tier standard --k8s-support-plan KubernetesOfficial once LTS is no longer needed. On Cloud SQL an in-place major version upgrade or a migration.
  3. Where the upgrade cannot be done before the cut-off date, time-box the fee: a date in the calendar, a budget alert on the line, and on EKS the upgrade policy that lifts the cluster at the end of extended support anyway.
  4. Remove the cause: a version rule in the cost policy that allows new instances and clusters only on versions with at least a year of standard support left, and the providers' support calendars in the cost review.

The fee ends with the completion of the upgrade, to the day on RDS, pro rata on Azure; the upgrade itself has no dry run, so a test in a copy comes first.

yesnoPer resource: the fee permonth against theupgrade effortUpgrade beforethe cut-off date?Test in a copy first:the upgrade has no dry runUpgrade the provider's way:in place or blue/green,the EKS upgrade policyPay with an end date: a datein the calendar, a budgetalert on the lineRemove the cause: a versionrule in the cost policy, thesupport calendars inthe cost reviewThe fee ends with thecompleted upgrade
Fee against upgrade effort decides, a paid fee always carries an end date, and the version rule stops the next one

Risks and side effects

  • Switching the RDS enrolment off after the support end is not an opt-out but an immediate upgrade; whoever wants to avoid the fee plans the upgrade themselves.
  • A major upgrade changes behaviour: extensions have to be updated, parameters and query plans change, Kubernetes removes APIs. A test in a copy and a rollback path are part of it.
  • EKS lifts a cluster automatically at the end of extended support, with no notice of the time and only the control plane; nodes and add-ons stay behind and are manual work afterwards.
  • LTS on AKS is tied to the Premium tier, which costs more than Standard; whoever only needs time pays the tier for every cluster management hour.
  • Reservations and Savings Plans do not cover the extended support fee; on Cloud SQL committed use discounts do not apply to it, by the pricing page's account.

How to verify the saving

Before: per resource, the extended support line in the last full month, vCPU-hours times rate, and the instance line beside it. After: the same resource in the first full month after the upgrade, with an unchanged instance line and without the second line; on EKS the cluster hour at the standard rate. The fee per month is the estimate, the team's decision makes it accepted, the upgrade implemented, and the following month's invoice realises it in the pattern of estimated, accepted, implemented, verified. The number of resources on versions without standard support is the figure that then stays at zero.

Sources

Read on 2026-10-21. Amazon RDS Extended Support, RDS Extended Support charges, Amazon RDS for MySQL pricing, Kubernetes version lifecycle on EKS, Disable EKS extended support, Amazon EKS pricing, Long-term support for AKS, Extended support for Azure Database for PostgreSQL, Extended support for Cloud SQL, Cloud SQL pricing.