Skip to main content

Remediation

  1. Verify the finding. Confirm the installed OS name and release using current guest inventory, such as Breeze OS and OS Release, Systems Manager PlatformName and PlatformVersion, Linux /etc/os-release, or Windows system information. Review Cloudaware's OS Info: Source, OS Info: Maintained, OS Info: EOL From, and optional OS Info: EOES From against the vendor's current lifecycle schedule. Resolve stale or conflicting data before making changes. EC2 platform labels and source AMI metadata alone do not establish the installed release or its support status.

  2. Choose and test a supported release. Follow the vendor's supported upgrade path and test application dependencies, packages, security agents, drivers, licensing, and deployment automation. Rebuild from a trusted, maintained image when an in-place upgrade is unsupported. Confirm any Marketplace subscriptions or Bring Your Own License (BYOL) entitlements required for the target release.

  3. Prepare the migration. Back up application data and configuration, verify restoration, and test the rollback procedure. Plan a maintenance window where necessary. Preserve required IAM instance profiles, security groups, network settings, storage, encryption, and bootstrap configuration when replacing instances.

  4. Upgrade or replace the instances. Apply the tested upgrade or deploy replacement instances through the established deployment process. For Auto Scaling groups, select the tested launch-template version and roll out replacements using the normal instance refresh process. Verify workload health and complete traffic cutover before retiring the original instances. Updating a launch template or registering a new AMI does not upgrade existing instances.

  5. Confirm completion. Verify the installed OS release, security-update availability, and application health. Refresh guest inventory and Cloudaware lifecycle enrichment, then reevaluate the policy. Update golden images and deployment configuration to prevent new instances from using the retired release. Retain migration backups and the tested rollback path until acceptance, subject to retention requirements.

If migration must be deferred, verify that the vendor's extended-support offering covers the exact OS release and workload. Confirm the required subscriptions, enrollment, repositories, and delivery of security updates. Document a time-limited policy exception with an owner and migration deadline. A future OS Info: EOES From date or OS Info: Maintained value of Yes does not establish entitlement, and extended support may cover fewer packages or fixes. An ordinary-EOL finding remains until the OS is upgraded or an approved exception is applied through the exception process.