Catching AWS deprecations before they bite - AWS Health scheduled changes to EventBridge, Trusted Advisor checks and an owner per notice

#The problem

AWS gives plenty of notice:

• Lambda sends deprecation notices at least 180 days ahead, through email, the Health Dashboard and Trusted Advisor.
• EKS sends an end-of-standard-support notice at least 60 days ahead through the Health Dashboard.

But email goes to the account's primary contact, and Health Dashboard entries expire. In a multi-account organisation, nobody reads them, and the first sign of trouble is a blocked deployment.

#1. Turn on the organisational view

From the management account (or a delegated administrator):

aws health enable-health-service-access-for-organization
aws health describe-health-service-status-for-organization

Now you can query events across accounts:

aws health describe-events-for-organization --region us-east-1 \
  --filter '{"eventTypeCategories":["scheduledChange","accountNotification"],"eventStatusCodes":["open","upcoming"]}' \
  --query "events[].[service,eventTypeCode,startTime]" --output table

The AWS Health API endpoint is global and served from us-east-1 (with failover regions); check the docs for the current endpoint setup.

#2. Send events to EventBridge

AWS Health publishes events to EventBridge in each region. A rule for scheduled changes and account notifications:

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "eventTypeCategory": ["scheduledChange", "accountNotification"]
  }
}

For a whole organisation, send Health events from member accounts to a central event bus (or use the organisational view through the delegated admin account), then fan out:

• Lambda deprecations (service: LAMBDA) to the serverless owners
• EKS version events (service: EKS) to the platform team
• EC2 and other retirement events to the infrastructure team

A small Lambda or Step Functions target can look up the affected resource's Owner tag (the event lists affected entities) and create a ticket in the right queue.

#3. Use Trusted Advisor for "what's affected right now"

Trusted Advisor's AWS Lambda Functions Using Deprecated Runtimes check includes published versions as well as $LATEST, and updates as you fix things. Turn on weekly email in Trusted Advisor preferences, or pull results:

aws trustedadvisor list-checks --language en \
  --query "checkSummaries[?contains(name,'Deprecated Runtimes')].[id,name]" --output text

The Trusted Advisor API and checks available depend on your support plan; check what your accounts can use.

#4. Track each notice to closure

Review the list in the weekly ops meeting. Deadlines from the current cycle worth tracking:

• Lambda python3.10 deprecated 31 Oct 2026, dotnet8 10 Nov 2026 - see Lambda runtime deprecations
• EKS 1.31 end of extended support 26 Nov 2026, 1.34 end of standard support 2 Dec 2026 - see EKS support dates
• Amazon Linux 2 end of life (30 June 2026) - see AL2 to AL2023

#5. Fix the contacts

Make sure the operations and security alternate contacts are set on every account (to team mailboxes, not individuals):

aws account put-alternate-contact --account-id 111122223333 \
  --alternate-contact-type OPERATIONS --name "Cloud Ops" \
  --email-address cloud-ops@example.com --phone-number "+44-000-000" --title "Ops"

#Checklist

• Health organisational view enabled
• EventBridge rule for scheduledChange and accountNotification events
• Events routed to owning teams by service or resource tag
• Trusted Advisor deprecated-runtime check reviewed weekly
• Each notice tracked with an owner and target date
• Alternate contacts set on every account

#Sources

• AWS Lambda runtimes - deprecation notifications
• Amazon EKS version FAQs - notifications