AMIs são imagens estáticas e não podem ser alteradas. Mesmo se eles pudessem ser atualizados, eles não deveriam ser (pelo menos não as AMIs públicas).
A razão para isso é que as implantações automatizadas dependem de infraestrutura e ambientes precisamente conhecidos. Suponha que eu tenha um código que dependa de alguma biblioteca pré-instalada na AMI e sei que esse código funciona com a AMI atual. Se eu criar um modelo do CloudForamtion para iniciar uma instância com esse ID de AMI e executar esse código, ele deverá sempre funcionar. Para sempre .
No entanto, se a AMI tiver permissão para ser "atualizada" e essa atualização fizer com que a biblioteca seja alterada, meu código poderá ou talvez não ser compatível com a versão mais recente da biblioteca, potencialmente fazendo com que o código falhe. Não importa se a atualização da biblioteca foi feita com boas intenções (ou seja, uma correção de bug); ele precisa ser a decisão do escritor de aplicativos para atualizar a AMI, e não o mantenedor da AMI.
Se você estiver usando algo como o CloudFormation para gerenciar seu ambiente, os IDs da AMI serão armazenados em seus modelos (idealmente controlados pela versão!) e atualizados se e quando você estiver pronto para testar uma nova versão. A compatibilidade com uma nova AMI deve ser testada tão completamente quanto você faria com qualquer novo recurso.