What is the best approach to track descendants of AMIs?

We have several golden AMIs that teams have built AMIs off of (children), some AMIs are built off of those (grand children), and now we'd like to figure out how to track the decendant to its parent golden AMI. There is a /etc/os-release for the Amazon AMIs which is useful but it makes it harder to find the AMIs in between.

Possible solutions

1. Tagging of AMIs and tagging of decendent AMIs

   • This would work but would require this tagging approach for all packer scripts which someone may forget to include.

     "tags": {
       "source_ami": "{{ .SourceAMI }}",
       "source_ami_name": "{{ .SourceAMIName }}",
       "source_ami_date": "{{ .SourceAMICreationDate }}"
     }
     

   • In addition to that, we can also create a cloud custodian policy to deregister any new AMIs (after a specific date) to automatically deregister if it does not contain the above mandated tags.
   • Another problem with this approach is that sharing these AMIs with other accounts loses tags in those shared accounts. This solution would require either a Lambda or packer post processor that can assume a role in child accounts in order to copy tags of AMIs from the primary build account to the child account.

2. Manifest json file (example) downloaded to EC2 upon boot

   • This would not contain the resulting AMI id on the AMI itself since we do not know what the AMI is until it's complete. What we can do instead is use a manifest post processor to output the manifest.json, upload it to a prefix according to its respective AMI e.g. aws s3 cp manifest.json s3://bucket-ami-output/<ami-id>/manifest.json, and then have the EC2 launch use a /etc/rc.local script to hit its metadata to get its AMI, download the respective AMI manifest.json, check for a non-existent /etc/os-<parent-id>.json e.g. /etc/os-0.json. If os-0.json already exists, increment the parent id until one is available. Finally, move the json file to available file on the system.
   • Or we could create a file that has the source ami instead of the resulting ami. This is possible using a script that hits the metadata endpoint http://169.254.169.254/latest/meta-data/ami-id to get the current AMI during the packing process and then dump that information into a /etc/os-0.json file.

I'm leaning to the first approach because it seems much simpler.

Amazon EC2 started supporting lineage information for the AMIs. More information can be found in the AWS documentation. This means you no longer need to write custom scripts.