由於身在的環境是有非常多的 AWS Account，在 AWS 的管理上就會有許多要思考的地方，這篇是關於 AMI 上的管理
先列出 AMI 的應用
- snapshot for backup
- template image
- Autoscaling
在想法上會是從統一一個 manger account 將 AMI 透過 Modify Image Permissions 給所有 AWS Account，這樣可以統一提供一些應該會使用的 template images，讓其他的團隊不需要再自己用 packer build 或是手動起 EC2 建 image。
觀念上會有兩種 AWS account：
- manager account
- client account
如果用 awscli 操作可以用這個指令給予 launch 權限，把 AMI_ID 和 AWS_ACCOUNT 換掉：
$ aws ec2 modify-image-attribute --image-id $AMI_ID --launch-permission "{\"Add\":[{\"UserId\":\"${AWS_ACCOUNT}\"}]}" --profile $PROFILE
同時這個 AMI 的管理機制還要想到 AMI EOL 和 Autoscaling 的部份，長期下來不可能一直將舊的 AMI 留在 manager account，AMI 會因為微調、安全性更新改版而產生很多版本的 AMI (但相同性質)，舊的 AMI 會需要公告 EOL 日期後下架
但在 client account 這邊有可能遇到的狀況是直接用 manager account share 的 AMI 直接使用在 Autoscaling，當 AMI EOL 公告後，client account 有可能因為沒注意到 Autosclaing 的 AMI 已經被 EOL 下架而在 Autoscaling-in 後找不到 AMI 而 Launch instance fail
在避免這樣的狀況必須讓 Client account 用 copy AMI 的方式去使用，manager account 也必須 share copy volume 的權限：
$ aws ec2 modify-snapshot-attribute --snapshot-id ${SNAPSHOT_ID} --attribute createVolumePermission --operation-type add --user-ids ${AWS_ACCOUNT}
換掉 SNAPSHOT_ID 和 AWS_ACCOUNT 就可以使用。
順手也寫了一個 script 去自動 share ami 給所有 client account 放在 shazi7804/aws-tools
除了宣導使用 copy AMI 的方式以外，可能還必須寫一支 lambda 去掃所有的 Autoscaling 是不是有用到 template AMI，避免悲劇發生。