AWS Extended Support: What it is, how it works, and how to prepare

AWS has always tried to encourage its customers to stay current with the latest versions of managed services such as Amazon RDS, Amazon EKS, Amazon ElastiCache, and others. Traditionally, when a version of a service reached End of Support (EoS), it was retired, and customers had to upgrade right away to keep their applications running.

That behavior has changed, however.

Now, with the Extended Support program, AWS keeps the legacy version available for an additional period — for a fee. This gives more operational flexibility to teams that need more time to update their environments, but it also calls for attention to additional costs and migration planning.

In this post, we will cover:

• What AWS Extended Support is
• Which services are affected
• How billing works
• Real-world simulations with EKS and RDS
• An automation for a monthly estimated-charge alert

What is AWS Extended Support?

AWS Extended Support is a recent Amazon Web Services feature that extends the official support period for legacy versions of managed services beyond the End of Support (EoS) date. Instead of abruptly cutting off the service, as it used to, AWS now lets customers keep using the old version for an additional fee.

This change reflects a real need seen in running enterprise environments: it is not always possible to upgrade right away a database version, a Kubernetes engine, or some other managed component. The reasons range from technical constraints, limitations in legacy applications, and complex maintenance windows to regulatory rules that require a more controlled upgrade process.

Before Extended Support

Historically, the version lifecycle for services such as Amazon RDS and Amazon EKS followed this logic:

1. AWS released a new version of the service (for example, PostgreSQL 14).
2. After a certain period (usually 12 to 18 months), the previous version (such as PostgreSQL 11) was marked as “deprecated.”
3. An end-of-support (EoS) deadline was set.
4. When EoS arrived, AWS took the version offline:

• New instances could no longer be created.
• Existing instances were forced to upgrade.
• Sometimes the upgrade was done automatically, creating operational risk.

This put pressure on engineering teams, especially at large companies with many distributed environments.

With Extended Support

AWS now offers an additional extended support period:

• You do not have to migrate immediately when EoS arrives.
• The old version keeps working, with the same performance and APIs.
• AWS charges an additional fee on top of the service cost for as long as that version is active.
• You get more time to plan, test, and migrate safely.

This model is similar to extended support for operating systems such as Windows Server and Red Hat Linux: you pay more, but you get time to adapt.

Why does this matter?

• Operational flexibility: No forced emergency upgrades.
• Lower risk: Avoids disruptions in critical environments.
• Cost transparency: The charge is clearly defined as an extra percentage.

Important: extended support does not include new improvements, fixes, or security updates for the legacy version. It only guarantees that the version will keep running in the AWS managed environment for an additional period.

Services with extended support

Some of the services already included in the Extended Support program are:

• Amazon EKS (Kubernetes)
• Amazon RDS (PostgreSQL, MySQL, SQL Server, Oracle, etc.)
• Amazon ElastiCache
• Amazon OpenSearch
• Amazon DocumentDB

Each service has its own policy for EoS dates and fee percentages.

How does billing work?

Billing varies by service and is usually calculated as an additional percentage on top of the service's standard cost.

EKS example:

• After a version's EoS (e.g., Kubernetes 1.24), the cluster stays active.
• AWS charges a 20% surcharge on the EKS control plane price.
• This percentage can vary depending on how long the version has been out of support (e.g., it may rise to 50% after 12 months).

RDS example:

• If you are running RDS with PostgreSQL 11 after EoS:
• AWS charges an additional 10% to 20% on the instance cost and storage.
• This amount can also go up over time.

Billing simulation — EKS and RDS

Let's simulate two scenarios:

Scenario 1: EKS with Kubernetes 1.24 (EoS version)

• Control instance: m5.large
• Approximate monthly cost: $73 (EKS control plane)
• Extended Support Fee (20%): $14.60
• Monthly total with extended support: $87.60

If you have 5 legacy clusters, that comes to $73 in extra costs per month.

Scenario 2: RDS PostgreSQL 11 on db.t3.medium

• Instance cost: $50/month
• Storage: 100 GB (SSD), ~$12/month
• Base total: $62/month
• Extended Support Fee (15%): $9.30
• Monthly total with extended support: $71.30

With 10 instances, that is $93/month in extra charges.

How to prepare?

1. Monitor your versions: Use AWS Config, the AWS CLI, or third-party tools to track service versions.
2. Plan migrations at least 3–6 months in advance.
3. Set up alerts and cost projections.

Automation: Monthly Extended Support Alert

Let's build a simple automation to:

• Check for EKS and RDS instances that are out of support
• Calculate an estimate of the additional cost
• Send an alert via SNS or email

Prerequisites:

• AWS CLI configured
• Lambda + CloudWatch, or a script via cron
• IAM with permission for eks:ListClusters, rds:DescribeDBInstances

Example script (Python)

import boto3
from datetime import datetime

# Simule os dados das versões EoS
eks_eos_versions = {'1.24': 0.2}  # 20% de taxa
rds_eos_versions = {'11': 0.15}   # 15% de taxa

# Simule os custos médios
eks_base_cost = 73  # USD/mês por cluster
rds_base_cost = 62  # USD/mês por instância

# Inicializa os clientes
eks_client = boto3.client('eks')
rds_client = boto3.client('rds')
sns_client = boto3.client('sns')

def check_eks_clusters():
    clusters = eks_client.list_clusters()['clusters']
    total_support_fee = 0
    for cluster in clusters:
        info = eks_client.describe_cluster(name=cluster)['cluster']
        version = info['version']
        if version in eks_eos_versions:
            fee = eks_base_cost * eks_eos_versions[version]
            total_support_fee += fee
    return total_support_fee

def check_rds_instances():
    instances = rds_client.describe_db_instances()['DBInstances']
    total_support_fee = 0
    for db in instances:
        version = db['EngineVersion'].split('.')[0]
        if version in rds_eos_versions:
            fee = rds_base_cost * rds_eos_versions[version]
            total_support_fee += fee
    return total_support_fee

def send_alert(total_fee):
    message = (
        f"[{datetime.utcnow()}] Estimativa de cobrança por Extended Support: ${total_fee:.2f} por mês.\n"
        "Recomenda-se atualizar as versões dos serviços listados."
    )
    sns_client.publish(
        TopicArn='arn:aws:sns:us-east-1:123456789012:ExtendedSupportAlerts',
        Subject='[AWS ALERTA] Suporte Estendido Ativo',
        Message=message
    )

def lambda_handler(event=None, context=None):
    eks_fee = check_eks_clusters()
    rds_fee = check_rds_instances()
    total_fee = eks_fee + rds_fee
    send_alert(total_fee)

Schedule it with CloudWatch

1. Create a Lambda function with this script.
2. Schedule it to run monthly via CloudWatch Events.
3. Use an Amazon SNS topic with the email addresses of the people responsible.

Conclusion

AWS Extended Support is both a blessing and a trap.

On one hand, it gives time and breathing room to teams juggling multiple priorities. On the other, it can generate hidden costs that grow quickly if they are not monitored.

The takeaway: keep your services up to date whenever possible, use automation to spot billing risks, and plan upgrades as part of your production environment's lifecycle.

Official references:

• AWS EKS Kubernetes Versions and Support Timeline
• AWS RDS End of Support Policy
• Pricing examples for Extended Support