Managing AWS Health Planned Lifecycle Events with ServiceNow

When the AWS services you depend on require version upgrades, are reaching end of support, or otherwise need specific maintenance to avoid operational issues, AWS Health communicates these as Planned Lifecycle Events (PLE). PLEs are designed to give your teams advance notice, at least 180 days for major changes and 90 days for minor changes, so you can plan and act before impact.

Examples include:

• Amazon EKS Kubernetes version end of standard support
• Amazon RDS engine version end of support
• Amazon EC2 instance generation retirement

You receive notifications about PLEs by default through email, but the same information is also available programmatically using the AWS Health API or Amazon EventBridge which allows you to integrate with your ITSM or operational tools of choice.

This article walks you through the concepts of why you should consider integrating PLEs with ITSM tools, PLE features aligned with tools like like ServiceNow, the progression of lifecycle events, and options for structuring changes depending on your use case.

Why integrate Planned Lifecycle Events with ITSM tools

The primary reason to integrate PLEs with your tools is to reduce manual effort and risk. When your environment is small, a few accounts and a handful of resources, keeping track of the important events is feasible. But you're growing.

I often speak to AWS customers who manage large enterprises, organizations with hundreds or thousands of accounts and hundreds of thousands of resources. At that scale, you need to rely on automation and processes because email isn't a viable tool anymore.

PLEs in particular are well-suited for integration with ServiceNow change management because PLEs deliver important event details as structured metadata allowing you to reference specific Health data when calling the API for your tools.

Key features in a Planned Lifecycle Events for change management

Let's review a few PLE features that align well with change management.

Identify lifecycle events across Regions with deprecated_versions

Each AWS Region where you have affected resources receives its own event with a unique eventArn. To correlate these into a single lifecycle change, use the deprecated_versions field in eventMetadata. This value is the same across all Regions for the same lifecycle change (e.g., "Amazon Aurora PostgreSQL 13 End of Standard Support"), making it the natural key for grouping regional events together and avoiding duplicate records in ServiceNow.

Affected entities

The affectedEntities array lists each affected resource by its unique Amazon Resource Name (ARN) with an individual status:

• PENDING: The resource requires action from you
• RESOLVED: The required action has been completed (you upgraded, migrated, or deleted the resource)

Dynamic burndown

As you take action on resources, their status updates from PENDING to RESOLVED. When all resources reach RESOLVED status, the Health event status changes to Closed.

If the event start date passes and you still have unresolved resources, the Health event remains open for up to 4 years after the event start or end date (whichever is later).

If you want more information on PLEs, review the full documentation for AWS Health Planned Lifecycle Events

A reference Planned Lifecycle Event

The following is an example of a Planned Lifecycle Event for Amazon Aurora PostgreSQL end of standard support. In the event detail, note the startTime indicating the deadline for the change, affectedEntities with PENDING status, the actionability of ACTION_REQUIRED, and the eventMetadata providing context about the deprecated version.

{
    "version": "0",
    "id": "f44cd31b-0130-41fd-2b25-ae73e0f220e6",
    "detail-type": "AWS Health Event",
    "source": "aws.health",
    "account": "123456789012",
    "time": "2026-01-28T00:05:51Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:rds:us-east-1:123456789012:db:my-frontend-db1-instance-1",
        "arn:aws:rds:us-east-1:123456789012:db:my-backend-db2-instance-1",
        "arn:aws:rds:us-east-1:123456789012:db:my-frontend-db1-instance-1-us-east-1b"
    ],
    "detail": {
        "eventArn": "arn:aws:health:us-east-1::event/RDS/AWS_RDS_PLANNED_LIFECYCLE_EVENT/AWS_RDS_PLANNED_LIFECYCLE_EVENT_0469d033...",
        "service": "RDS",
        "eventTypeCode": "AWS_RDS_PLANNED_LIFECYCLE_EVENT",
        "eventTypeCategory": "scheduledChange",
        "eventScopeCode": "ACCOUNT_SPECIFIC",
        "communicationId": "1693515544866527fce70adea4c1386cd5ce5c0b-1",
        "startTime": "Sat, 28 Feb 2026 08:00:00 GMT",
        "lastUpdatedTime": "Wed, 28 Jan 2026 00:05:50 GMT",
        "statusCode": "upcoming",
        "eventRegion": "us-east-1",
        "eventDescription": [{
            "language": "en_US",
            "latestDescription": "You are receiving this message because you have one or more Amazon Aurora PostgreSQL DB instances running major version 13 that require your attention. PostgreSQL 13 will be deprecated by the community in November 2025, and will not receive any bug fixes or security patches after that. Following the community timeline, Aurora PostgreSQL 13 will reach end of standard support on February 28, 2026..."
        }],
        "eventMetadata": {
            "deprecated_versions": "Amazon Aurora PostgreSQL 13 End of Standard Support",
            "truncated": "false"
        },
        "affectedEntities": [{
            "entityValue": "arn:aws:rds:us-east-1:123456789012:db:my-frontend-db1-instance-1",
            "status": "PENDING",
            "lastUpdatedTime": "Fri, 28 Nov 2025 03:40:31 GMT"
        }, {
            "entityValue": "arn:aws:rds:us-east-1:123456789012:db:my-backend-db2-instance-1",
            "status": "PENDING",
            "lastUpdatedTime": "Fri, 28 Nov 2025 03:40:31 GMT"
        }, {
            "entityValue": "arn:aws:rds:us-east-1:123456789012:db:my-frontend-db1-instance-1-us-east-1b",
            "status": "PENDING",
            "lastUpdatedTime": "Fri, 28 Nov 2025 03:40:31 GMT"
        }],
        "affectedAccount": "123456789012",
        "page": "1",
        "totalPages": "1",
        "backupEvent": "false",
        "actionability": "ACTION_REQUIRED",
        "personas": ["OPERATIONS"]
    }
}

How Planned Lifecycle Events progress over time

Before mapping these events to ServiceNow, let's walk through how a Planned Lifecycle Event progresses from start to finish.

A new event is published

When AWS identifies resources in your account affected by an upcoming lifecycle change, a Planned Lifecycle Event is published to your AWS account. The event arrives with a statusCode of upcoming, a startTime indicating the deadline for action, and an affectedEntities list where each resource has a status of PENDING.

If you use AWS Organizations with organizational view enabled, events from all member accounts are delivered to a central management account. The affectedAccount field identifies which account each event belongs to.

Detailed updates and burndown

As your teams take action (upgrading database engines, updating cluster versions, rotating certificates) the Health event updates. Individual resources in affectedEntities transition from PENDING to RESOLVED. Each update arrives as a new event with the same eventArn, an updated lastUpdatedTime, and the current state of all affected entities.

New resources may also appear in the event over time if AWS identifies additional affected resources in your account.

The event concludes

When all affected entities reach RESOLVED status, the Health event statusCode changes to closed. If the startTime passes and you still have unresolved resources, the event remains open for up to 4 years. During this time, the service may implement the described change to your unresolved resources at any point after the start date.

Mapping Planned Lifecycle Events to ServiceNow

With this lifecycle in mind, let's look at how to represent these events in ServiceNow. The right structure depends on two factors: how your organization assigns ownership of AWS accounts and resources, and how mature your ServiceNow CMDB is.

The parent change request

Regardless of your organizational model, start with a parent change request keyed on the deprecated_versions value from eventMetadata. This gives you a single, descriptive record for the lifecycle change, for example, a change request titled "Amazon Aurora PostgreSQL 13 End of Standard Support", that serves as the central tracking point across all regions and accounts.

As new events arrive from different Regions sharing the same deprecated_versions, update this single parent change request rather than creating duplicates. The parent change request's state reflects the Health event's statusCode. Since the Health event itself won't close until all affected entities are resolved (or the event expires), the parent change request naturally stays open until the work is done.

Change tasks: two approaches

Underneath the parent change request, create change tasks to represent the actual work. Which approach you choose depends on how your organization manages AWS accounts.

Approach 1: Change tasks per account

Use this when each AWS account represents a single team or application. There's one group of people responsible for all resources in the account, so a single change task per account is sufficient.

• Create one change task per unique affectedAccount
• Set the assignment group based on the account owner
• List the affected resources and their statuses (PENDING/RESOLVED) in the work notes
• As the Health event updates, append new work notes reflecting the updated resource statuses

This keeps the task count manageable. The assigned team reviews their work notes to see which resources still need action. When all resources for that account are RESOLVED, close the change task.

Approach 2: Change tasks per resource

Use this when AWS accounts are shared by multiple teams and resources are divided among different owners. A single account-level task wouldn't route to the right people.

• Create one change task per affected entity from affectedEntities
• The resource ARN in entityValue identifies both the resource and its Region (e.g., arn:aws:rds:us-east-1:123456789012:db:my-frontend-db1-instance-1)
• Set the change task state based on the entity status: PENDING maps to Open, RESOLVED maps to Closed
• Assign each task based on resource ownership, using tags, CMDB lookups, or naming conventions

As the Health event updates and individual entities move to RESOLVED, your integration transitions the corresponding change tasks to Closed. This gives each resource owner a specific, assigned work item with clear completion criteria.

Leveraging Configuration Items and Impacted Services

If your ServiceNow instance has Configuration Items (CIs) defined for your AWS resources and service dependencies mapped, you can enrich the integration further:

• Associate each change task with the corresponding CI using the resource ARN as a lookup key
• Add affected CIs to the change request's Affected CIs related list. If your CMDB has service relationships defined, ServiceNow can automatically populate the Impacted Services/CIs related list by traversing those relationships.
• This gives change managers visibility into which business services are affected by the lifecycle change

If you don't have CIs defined in ServiceNow, the change task approaches above work on their own. The resource ARN, account number and Region (embedded in the ARN) provide enough context to route and track the work. Defining CIs and service maps is valuable but not a prerequisite for this integration.

Choosing your approach

Your situation	Recommended approach
Central team (CCoE/governance) tracking lifecycle events across the org	Parent change request per deprecated_versions for visibility
Each AWS account = one team or application	Account-level change tasks with resources in work notes
AWS accounts shared by multiple teams	Resource-level change tasks assigned to individual owners
CIs and service dependencies defined in ServiceNow	Associate change tasks with CIs
No CIs defined	Change tasks alone, using ARNs and account numbers for context

These approaches can be combined. A central team might own the parent change request for org-wide visibility while account-level or resource-level change tasks are assigned to the teams doing the work.

Tracking progress

Resource burndown

Whether you use account-level or resource-level change tasks, you can surface progress on the parent change request:

• Total resources = count of all affectedEntities across all pages
• Resolved = count where entity status is RESOLVED
• Remaining = count where entity status is PENDING

Displaying this on the parent change request (e.g., "12 of 47 resources resolved") gives stakeholders a clear picture of progress without opening individual tasks.

Planning around lead times

Planned Lifecycle Events provide at least 180 days notice for major changes and 90 days for minor changes, where possible. Use the startTime to set due dates on your change requests and build planning cadences around these timelines. For example, you might create a recurring review of open Planned Lifecycle Event change requests to ensure teams are making progress well before the deadline.

Practical considerations

Enrichment with resource context

The event provides resource ARNs but not application context. If ServiceNow needs to know which application or team owns a resource, enrich the event data by:

• Looking up resource tags using the AWS Resource Groups Tagging API
• Querying your CMDB for the resource's application and owner
• Mapping account numbers to business units using a lookup table

Wrap up

Planned Lifecycle Events provide structured, trackable information about upcoming changes that require your action. The deprecated_versions field gives you a single, descriptive key for the lifecycle change across all Regions, while the dynamic resource burndown maps naturally to ServiceNow change tasks, whether you track at the account level or the individual resource level. Start with the approach that matches how your organization assigns ownership today, and layer in CI associations and impacted services as your ServiceNow maturity allows.

For more on Planned Lifecycle Events and filtering Health events, refer to:

• Planned lifecycle events for AWS Health
• Developing a high-specificity AWS Health event strategy with AWS User Notifications