D’abord parce que l’AMI doit pouvoir se suffir à elle-même et dans le cas où nous montons un EBS pour la persistence de données, ce n’est pas très pratique d’avoir un demi-MySQL sur l’AMI et l’autre moitié (le répertoire /var/lib/mysql) sur le snapshot de l’EBS.

Ensuite, en termes de sécurité, je préfère utiliser le scripting et générer à chaque fois des mots de passe aléatoires, avec « pwgen » par exemple, et les poser ensuite où il faut. Question d’habitude.

De plus, l’AMI masque un peu la capitalisation sur la construction de l’instance, qui est clairement apparente dans le scripting et dans Puppet en l’occurrence.

Et finalement, l’argument massue, de toute façon un gestionnaire de configuration centralisé, comme Puppet, est plus adapté car il permet de faire vivre la configuration des machines au fil de l’eau et de les maintenir dans un état homogène.

Si il faut modifier l’AMI à chaque modification de paramétrage et redéployer les EC2… On n’a pas fini.
L’AMI est un bon outil pour instancier un template de base (au sens basique)(dont je suis parti pour mes instances EC2) sur lesquels on installe le client Puppet ou bien afin de faire des démonstrations ou des présentations.

Je reste sur le scripting pour la production dans le cadre de configurations plus ou moins poussées.