AWS Extended Support: what it costs and how to find everything you're about to pay for

Disclosure: I build Expiry Radar, a tool that tracks dates like these. Nothing below needs it: the script uses only the AWS APIs.

When a managed service version reaches the end of standard support, AWS doesn't stop your cluster or database. It moves it to Extended Support and adds a line to your bill. No ticket, no page, no failed deploy. For a version you forgot about, the first sign is often the Cost Explorer graph.

This post covers what Extended Support costs for EKS, RDS, Aurora and ElastiCache, which versions are already in it (some of you have been paying since August), how to find every affected resource across all regions and accounts with one read-only script, and how to get warned for free next time.

All prices are us-east-1 list prices from the AWS Price List API as of November 2026. Other regions differ a little.

What Extended Support is, and why nobody notices it

AWS gives each version a fixed standard-support window. After it ends, the resource keeps running on the old version, now in Extended Support, and you pay a surcharge on top of the normal price. When Extended Support ends too, AWS upgrades the resource for you, on its schedule.

Three things make it easy to miss:

1. Enrollment is automatic. EKS clusters default to upgradePolicy.supportType = EXTENDED. RDS and Aurora instances created through the CLI or API are enrolled by default (the console checkbox is off by default, the API default is on, so the same team can end up with both).
2. The warning goes to the wrong place. AWS Health does announce these changes, usually at least 180 days ahead for major versions, but per account and by email to the account's contacts. In a multi-account setup that's often a shared mailbox nobody reads.
3. The charge is a line item, not an incident. Nothing breaks, so nothing pages anyone.

What it costs

Details that change the math:

• RDS charges every copy. The Multi-AZ standby and every read replica on the old major version pay the surcharge too. Reserved Instance discounts don't apply to it.
• ElastiCache reservations don't cover the premium either. It's a separate On-Demand line.
• OpenSearch has started too: from 7 November 2026, Extended Support for several old Elasticsearch and OpenSearch versions is charged at the same rate as the instance itself. MSK and Amazon MQ have no paid extended support; they auto-upgrade after end of support.

Three worked examples

A month is ~730 hours.

One EKS cluster on 1.34 after 2 December: $0.50 × 730 = $365 a month extra, $4,380 a year, per cluster. The control plane fee goes from $73 to $438. A dev, staging and prod cluster on the same old version is ~$1,100 a month.

RDS for PostgreSQL 14, db.r6g.xlarge (4 vCPU), Multi-AZ, after 28 February 2027: 2 instances × 4 vCPU × $0.10 × 730 = $584 a month, and $1,168 a month from year 3. Add a read replica of the same size and it's another $292 (then $584).

ElastiCache for Redis OSS 6, three cache.r6g.large nodes, after 31 January 2027: 3 × $0.165 × 730 = $361 a month, $723 from year 3.

None of these are big numbers alone. They add up across environments, and they keep running until someone upgrades.

The dates that matter now (November 2026)

Already in Extended Support, so possibly already on your bill:

Coming up:

I keep the full table, with links to the AWS documentation for each service, at expiry-radar.com/aws-end-of-support. The source of truth is the AWS APIs below, which is also what the script uses.

Find everything you're about to pay for

AWS exposes the dates through APIs, so you don't need a spreadsheet:

# EKS: every version with its support dates aws eks describe-cluster-versions --include-all \ --query 'clusterVersions[].[clusterVersion,endOfStandardSupportDate,endOfExtendedSupportDate]' \ --output table # RDS and Aurora: standard and extended support end dates per major version aws rds describe-db-major-engine-versions --engine postgres \ --query 'DBMajorEngineVersions[].[MajorEngineVersion,SupportedEngineLifecycles[].LifecycleSupportEndDate]' 

That tells you the dates. It doesn't tell you which of your clusters and databases are affected, in which region and account, and what they will cost. So I wrote a script that does:

It's a single Python file, read-only, with boto3 as the only dependency. It:

• walks every enabled region of the current account, or every account in your AWS Organization with --org-role;
• reads support dates from the live AWS APIs (EKS and RDS), and from the AWS documentation for ElastiCache, which has no lifecycle API;
• counts vCPUs per instance class, Multi-AZ standbys and replicas, and ElastiCache nodes per replication group;
• knows when a resource has opted out (EKS supportType: STANDARD, RDS open-source-rds-extended-support-disabled), so it shows an auto-upgrade instead of a charge;
• prints a table, or --csv for a spreadsheet.

pip install boto3 python3 aws-extended-support-report.py # this account, all regions python3 aws-extended-support-report.py --org-role ExtendedSupportReader python3 aws-extended-support-report.py --all --csv > extended-support.csv 

Example output (made-up resource names, run on 12 November 2026):

ACCOUNT REGION SERVICE RESOURCE VERSION STD ENDS STATUS EXTRA/MONTH 123456789012 eu-west-1 RDS old-wiki (db.t3.medium) mysql 5.7 2024-02-29 EXTENDED, year 3 $292 123456789012 eu-west-1 EKS data-platform 1.31 2025-11-26 EXTENDED, forced upgrade in 14d $365 123456789012 eu-west-1 ElastiCache rate-limit (1 x cache.m5.large) redis 5 2026-01-31 EXTENDED $91 123456789012 eu-west-1 RDS analytics (db.r6g.2xlarge) postgres 13 2026-02-28 EXTENDED $584 123456789012 eu-west-1 EKS ci-runners 1.32 2026-03-23 EXTENDED $365 123456789012 eu-west-1 RDS legacy-cms (db.m6g.large) mysql 8.0 2026-07-31 EXTENDED $146 123456789012 eu-west-1 EKS payments-prod 1.34 2026-12-02 extended in 20d $365 123456789012 eu-west-1 ElastiCache sessions (2 x cache.r6g.large) redis 6 2027-01-31 extended in 80d $241 123456789012 eu-west-1 RDS orders-db (db.r6g.xlarge, Multi-AZ) postgres 14 2027-02-28 extended in 108d $584 123456789012 eu-west-1 RDS reporting-1 (Serverless v2, per ACU) aurora-postgresql 14 2027-02-28 extended in 108d ? 123456789012 eu-west-1 EKS staging 1.35 2027-03-27 auto-upgrade in 135d $0 Extended Support you are paying now: ~$1,843/month Starting within 365 days unless you upgrade: ~$1,190/month 1 resource(s) without an estimate (Serverless v2 or unknown instance type). 

The staging cluster above opted out of Extended Support, so instead of a charge it gets an automatic upgrade on 27 March, which may be the bigger surprise.

Permissions

The script only reads. If you run it across the organization, don't assume OrganizationAccountAccessRole: it has administrator access. Deploy a small role to every account (a CloudFormation StackSet works well) with this policy:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeRegions", "ec2:DescribeInstanceTypes", "eks:ListClusters", "eks:DescribeCluster", "eks:DescribeClusterVersions", "rds:DescribeDBInstances", "rds:DescribeDBClusters", "rds:DescribeDBMajorEngineVersions", "elasticache:DescribeCacheClusters" ], "Resource": "*" } ] } 

and a trust policy that allows only your management account (or whichever account you run it from) to assume it. The account you run from needs organizations:ListAccounts and sts:AssumeRole on that role.

Caveats, so you can trust the numbers as far as they go: prices are us-east-1; Aurora Serverless v2 is billed per ACU, which depends on load, so it shows ?; AWS's docs say Aurora is charged per vCPU without spelling out readers, so the script charges every instance, the same way RDS charges replicas; and Aurora MySQL 2 has no published year-3 rate, so it stays at the year 1–2 rate.

What to do with what you find

EKS

1. Check what blocks the upgrade before you touch anything. EKS runs upgrade checks for you, including deprecated API usage by your workloads:

 aws eks list-insights --cluster-name <name> --filter categories=UPGRADE_READINESS 

Run aws eks start-insights-refresh --cluster-name <name> first if the results are old.

1. Upgrade one minor version at a time. The control plane can only move one minor version per upgrade, so a 1.31 cluster needs three upgrades to reach 1.34. Upgrade the add-ons (VPC CNI, CoreDNS, kube-proxy) to versions that support the target, then the control plane, then the nodes.
2. If a cluster is on 1.31 now, do it before 26 November. After that, AWS upgrades the control plane on its own schedule and you can't roll back. Your node groups stay on 1.31 while the control plane moves on.
3. Decide per cluster whether you want Extended Support at all. For a cluster you'd rather auto-upgrade than pay for:

 aws eks update-cluster-config --name <name> --upgrade-policy supportType=STANDARD 

This only works while the cluster is still in standard support.

RDS and Aurora

1. Test the upgrade on a copy. Restore a snapshot, upgrade it, run your test suite against it. For PostgreSQL, extensions are the usual blocker; RDS checks them before a major upgrade and fails early.
2. Use Blue/Green Deployments to upgrade production with a short switchover instead of a long in-place upgrade. It supports major version upgrades for MySQL and PostgreSQL (with logical replication limits on PostgreSQL, so read the prerequisites).
3. Opt new databases out explicitly if you'd rather be forced to upgrade than pay:

 aws rds create-db-instance ... --engine-lifecycle-support open-source-rds-extended-support-disabled 

Put it in your Terraform/CloudFormation modules, because the API default is "enabled". Current AWS docs say you can also change it on existing instances with modify-db-instance; older AWS CLI versions don't have the flag on modify yet, and if standard support has already ended, disabling it triggers the major version upgrade.

ElastiCache

The cheapest fix may not be a Redis upgrade at all. ElastiCache supports upgrading Redis OSS clusters to Valkey, which is out of the Extended Support cycle and, at us-east-1 list prices, about 20% cheaper per node (cache.m5.large: $0.1248 vs $0.156 an hour). If you stay on Redis OSS, upgrade 4, 5 and 6 to 7.x before the dates above.

Get warned for free next time

You don't need a paid support plan for this. AWS Health sends lifecycle events to EventBridge for every account, at no cost. They're the AWS_<SERVICE>_PLANNED_LIFECYCLE_EVENT event types (for example AWS_EKS_PLANNED_LIFECYCLE_EVENT and AWS_RDS_PLANNED_LIFECYCLE_EVENT), with the affected resources listed.

One rule in us-west-2 receives account-specific Health events from all regions. Route them to an SNS topic and subscribe your team's channel:

{ "source": ["aws.health"], "detail-type": ["AWS Health Event"], "detail": { "eventTypeCategory": ["scheduledChange"], "eventTypeCode": [{ "wildcard": "*_PLANNED_LIFECYCLE_EVENT" }] } } 

aws sns create-topic --name lifecycle-events --region us-west-2 aws events put-rule --region us-west-2 --name aws-lifecycle-events \ --event-pattern file://lifecycle-pattern.json aws events put-targets --region us-west-2 --rule aws-lifecycle-events \ --targets Id=sns,Arn=arn:aws:sns:us-west-2:<account-id>:lifecycle-events 

(The SNS topic needs a resource policy that lets events.amazonaws.com publish to it.)

For many accounts, turn on AWS Health organizational view in the management account. It's free in the console for every support plan, and then the management account (or a delegated admin) gets one organization-wide EventBridge feed, so one rule covers everything. The Health API itself does need a Business or Enterprise support plan; EventBridge doesn't.

The us-west-2 shortcut has no high availability. If you can't miss an event, create the rule in each region you use and deduplicate on communicationId.

What this doesn't cover

Extended Support is one kind of AWS deadline. The others don't come through Health's lifecycle events at all: imported ACM certificates (they never auto-renew), Route 53 domains with auto-renew off, IAM access keys past your rotation policy, Secrets Manager rotation, and Savings Plans and Reserved Instances that expire and bump next month's bill. That's the gap I built Expiry Radar for: one timeline across accounts, with alerts routed to the team that owns each resource. It's free for one account.

If the script finds something surprising, or gets a number wrong for your setup, tell me in the comments and I'll fix it.