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

Alexandr Kalashnikov — Thu, 12 Nov 2026 22:39:21 +0000

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:

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).
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.
The charge is a line item, not an incident. Nothing breaks, so nothing pages anyone.

What it costs

Service	Standard	Extended Support surcharge	Year 3
EKS	$0.10 per cluster-hour	+$0.50 per cluster-hour ($0.60 total)	— (extended support lasts 12 months)
RDS for PostgreSQL / MySQL, Aurora (provisioned)	instance price	+$0.10 per vCPU-hour	+$0.20 per vCPU-hour
Aurora Serverless v2	ACU price	+$0.085 per ACU-hour	+$0.17 per ACU-hour
ElastiCache for Redis OSS	node price	+80% of the On-Demand node price	+160%

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:

Version	In Extended Support since	Extended Support ends
RDS for MySQL 8.0	1 Aug 2026	31 Jul 2029
RDS for PostgreSQL 13	1 Mar 2026	28 Feb 2029
ElastiCache Redis OSS 4 and 5	1 Feb 2026	31 Jan 2029 (then auto-upgraded to Valkey)
RDS for MySQL 5.7	1 Mar 2024	30 Jun 2029 (year 3 pricing since 1 Mar 2026)
Aurora MySQL 2 (5.7)	1 Nov 2024	30 Jun 2029
EKS 1.32	23 Mar 2026	23 Mar 2027

Coming up:

Date	What happens
26 Nov 2026	EKS 1.31 leaves Extended Support. AWS auto-upgrades the control plane, without a notification and without rollback. Nodes stay on 1.31.
2 Dec 2026	EKS 1.34 leaves standard support. Billing starts at 00:00 UTC.
31 Jan 2027	ElastiCache for Redis OSS 6 leaves standard support.
28 Feb 2027	RDS and Aurora PostgreSQL 14 leave standard support.
31 Mar 2027	RDS for PostgreSQL 11 leaves Extended Support (auto-upgrade).

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

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.

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.
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.
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

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.
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).
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.

DEV Community: Alexandr Kalashnikov