Support for AWS AMI Teardown/Security Lifecycle Policy -- extending pod spec abstraction to EC2/IaaS

My client has a Cloud Security policy where every 30 days, every VM Appliance in AWS is torn down and rebuilt. This creates an issue where after rebuild, that resource is tracked by Turbo under a new UUID and historical data is not tied back to the fresh resource. From an Eng standpoint, the way I'd imagine this getting implemented is similar to our abstraction of historical utilization for ephemeral containers/pods. The below recommendation was not sufficient and is preventing us from moving forward with implementing EC2 automation, Terraform, SNOW, etc.

In relation to the 30-day AMI Lifecycle Policy in AWS, you may remember our discussion on this topic with your former TAM. Earlier this week, we’d discussed two possibilities for how ABC Corp is managing this today — terminating (deleting) EC2 instances or simply stopping the instance from running. On the backend, Turbonomic tracks historical utilization data based on the ARN/uuid of an instance. When an instance is terminated this identifier can no longer be tracked across instances. As a result, we’re not able to tie historical utilization data of a terminated instance to a freshly provisioned EC2 instance. If the instance is simply stopped, this issue will not occur. If the same tagging remains in place, you can use dynamic resource groups in Turbonomic to ensure that the same scaling policies apply even if historical data does not remain.