🛡️ AWS EC2 Instance references a deprecated AMI🟢

• Contextual name: 🛡️ Instance references a deprecated AMI🟢
• ID: /ce/ca/aws/ec2/instance-deprecated-image
• Tags:
  • 🟢 Policy with categories
  • 🟢 Policy with type
  • 🟢 Production policy
• Policy Type: BEST_PRACTICE
• Policy Categories: RELIABILITY

Stats

not available

Logic

• 🧠 prod.logic.yaml🟢
  • 📗 AWS EC2 Instance
  • 🔌 AWS EC2 Instance - object.extracts.yaml
  • 🔌 AWS EC2 Image - object.extracts.yaml
  • 🧪 test-data.json

Description

Open File

Description

Identify EC2 instances whose source Amazon Machine Image (AMI) has passed its scheduled deprecation date. AMI deprecation is a deployment lifecycle signal that warrants reviewing the image and planning replacement where appropriate.

Deprecation does not prove that the instance's installed operating system is unsupported. Public AMIs receive a default deprecation date two years after creation, and owners can deprecate private or public images for other reasons. Existing instances continue to operate after their source AMI is deprecated. Users, launch templates, and Auto Scaling groups can still launch instances from a deprecated AMI by specifying its ID.

Rationale

Reviewing instances associated with deprecated images helps prevent new deployments and recovery procedures from repeatedly using a baseline that its publisher has retired or superseded. The finding is actionable through the deployment configuration and a tested instance replacement. It also applies when an AMI becomes deprecated after the instance was launched.

... see more

Remediation

Open File

Remediation

1. Verify the finding. Confirm the instance's source AMI, its owner, deprecation time, and reason for deprecation. Assess the installed OS and application support separately; AMI deprecation alone does not establish OS end of support.
2. Choose and test a replacement. Select an available, non-deprecated AMI from a trusted publisher. Test a replacement instance for compatibility with the workload's architecture, drivers, licensing, security configuration, and application dependencies. Confirm the image's support lifecycle.
3. Prepare the migration. Back up required data and configuration, verify restoration, and test migration and rollback procedures. Preserve required IAM instance profiles, security groups, network settings, storage, encryption, and bootstrap configuration. Plan a maintenance window if the rollout could interrupt service.
4. Update deployment configuration. Reference the tested AMI in the relevant launch template, Auto Scaling group, infrastructure-as-code definition, or image pipeline. For Auto Scaling groups, select the tested launch-template version and replace instances through the established instance refresh process. Updating deployment configuration does not replace existing instances automatically.

... see more

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags	Compliance
💼 Cloudaware Framework → 💼 Infrastructure Modernization			39		no data