updated ami

[jameslaneovermind]

No description provided.

[github-actions]

Expected Changes

s3-bucket › s3-one-apt-catfish

--- current
+++ planned
@@ -1 +1,12 @@
+bucket: s3-one-apt-catfish
+eventbridge: false
+lambda_function: []
+queue:
+    - events:
+        - s3:ObjectCreated:*
+      filter_prefix: input/
+      filter_suffix: .txt
+      queue_arn: queue-arn
+terraform_address: module.loom[0].aws_s3_bucket_notification.prod-bucket-notification-new
+terraform_name: module.loom[0].aws_s3_bucket_notification.prod-bucket-notification-new
+topic: []

Unmapped Changes

Note

These changes couldn't be mapped to a real cloud resource and therefore won't be included in the blast radius calculation.

s3-bucket › module.loom[0].aws_s3_bucket_notification.prod-bucket-notification

--- current
+++ planned
@@ -1 +1,12 @@
+bucket: s3-one-apt-catfish
+eventbridge: false
+lambda_function: []
+queue:
+    - events:
+        - s3:ObjectCreated:*
+      filter_prefix: input/
+      filter_suffix: .csv
+      queue_arn: queue-arn
+terraform_address: module.loom[0].aws_s3_bucket_notification.prod-bucket-notification
+terraform_name: module.loom[0].aws_s3_bucket_notification.prod-bucket-notification
+topic: []

Blast Radius

Items	Edges
1	0

Open in Overmind

Risks

Incompatibility with New AMI [High]

The change to the image_id attribute in the aws_launch_template resource updates the AMI used for launching new EC2 instances. Given the current system is operating with the old AMI (ami-0c94855ba95c286c99), there's a risk the new AMI (ami-0171207a7acd2a570) might introduce incompatibilities with the existing application setup. These could stem from differences in the underlying operating system, installed software versions, or configuration defaults. To mitigate this risk, a compatibility review between the old and new AMI is needed, focusing on the operating system, critical software dependencies, and any pre-installed packages. For completeness, application-level testing on an instance launched with the new AMI should be conducted before rolling out the change.

Performance Regression with New AMI [Medium]

Changing the AMI can lead to performance differences due to variations in the operating system configuration, kernel version, or installed software and libraries. Even if the application runs correctly on the new AMI (ami-0171207a7acd2a570), there might be unseen performance regressions as a result of these changes. Benchmarking the application on the new AMI compared to its current performance metrics on the old AMI (ami-0c94855ba95c286c99) can help identify any potential performance degradation early. This would provide an opportunity to adjust configurations or consider alternate AMIs if necessary.

Missing Dependencies in the New AMI [Medium]

The application's current operational state with the old AMI suggests certain dependencies and configurations are currently met. Switching to a new AMI (ami-0171207a7acd2a570) raises the risk of missing or incompatible dependencies not present in the new AMI. A thorough dependency checklist review against the new AMI, possibly via a dry-run or staging deployment, would be essential to ensure all critical application dependencies are met or can be resolved via startup scripts or configuration management tools.

Configuration Drift [Low]

Given the current system's operation under a specific AMI, manual configurations or hotfixes applied over time might not be documented or encoded into the infrastructure as code configuration. Transitioning to a new AMI (ami-0171207a7acd2a570) without accounting for these can lead to configuration drift. This drift might manifest as discrepancies between newly launched instances and existing ones, potentially affecting application consistency and reliability. An audit of manual changes and ensuring they are codified within the launch templates or through configuration management policies is crucial to prevent drift.