Gérer AWS à la main fonctionne quand on a trois instances et dix minutes devant soi. Dès que l'infrastructure grossit, la saisie répétée de commandes devient une source d'erreurs : oubli d'une région, mauvais profil, instance laissée allumée par accident. La réponse classique des équipes qui tiennent à leur santé mentale, c'est l'automatisation par scripts Bash. Ce tutoriel vous montre comment chaîner l'AWS CLI dans des scripts simples, robustes et réutilisables.
Poser les bases : configuration et profils
Avant d'écrire le moindre script, il faut un environnement propre. Installez l'AWS CLI, puis lancez aws configure pour définir vos accès par défaut. Mais pour de l'automatisation sérieuse, la bonne pratique consiste à utiliser des profils multiples : un profil par environnement (développement, staging, production) ou par identité. Cela évite qu'un script de maintenance de base de données dispose par accident des droits de modification sur des ressources critiques.
Dans un script, on cible le profil avec --profile NOM. Exemple :
aws s3 ls s3://mon-bucket-videos --profile production
Côté sécurité, évitez de stocker des clés en clair, même dans un fichier de configuration local. Privilégiez les rôles IAM attachés aux instances EC2 ou aux fonctions Lambda, ou AWS Secrets Manager pour les secrets d'application. Un script qui lit ses secrets dans l'environnement est plus portable et plus sûr.
Sortie structurée : le JSON et jq
Le format texte par défaut de l'AWS CLI est illisible pour un script. Pour automatiser, utilisez systématiquement --output json. La sortie devient une structure prévisible, exploitable par des conditions ou des boucles.
Pour extraire une valeur précise, l'outil jq est votre allié. Exemple typique : récupérer l'état d'une tâche asynchrone.
STATUS=$(aws ec2 describe-instances --profile prod --output json | jq -r '.Reservations[0].Instances[0].State.Name')
Cette capacité de parsing est ce qui distingue un script basique d'une vraie solution d'automatisation.
Structure d'un script fiable
Un script Bash commence par un shebang (#!/bin/bash) et gagne à déclarer ses variables en tête : noms de buckets, régions, ID d'AMI. Vous modifiez la configuration à un seul endroit, sans parcourir toute la logique.
Gestion des erreurs : ne jamais échouer en silence
Un script qui échoue silencieusement est pire qu'aucun script. Les fondamentaux :
set -e: arrête le script dès qu'une commande retourne un code d'erreur non nul, ce qui empêche la propagation d'erreurs dans des étapes dépendantes.- Les blocs
if: vérifiez explicitement les résultats, par exemple l'existence d'une AMI avant de lancer une instance. trap: exécutez des routines de nettoyage ou de notification avant l'arrêt forcé du script en cas d'erreur imprévue.
Boucles : traiter des listes d'objets
De nombreuses tâches AWS consistent à traiter un ensemble d'éléments : synchroniser des milliers de fichiers vers S3, ou gérer un parc d'instances. La combinaison aws ... --output json, jq et une boucle while read ou for permet de traiter chaque objet de manière atomique.
Exemple : arrêter uniquement les instances running qui ne sont pas marquées critiques.
for id in $(aws ec2 describe-instances --output json | jq -r '.Reservations[].Instances[] | select(.State.Name == "running") | .InstanceId'); do
aws ec2 stop-instances --instance-ids "$id"
done
Modularité : les fonctions Bash
Transformez les blocs répétitifs en fonctions. Une fonction log_message() qui gère l'horodatage, le niveau de sévérité et l'écriture dans un journal centralisé assure une traçabilité cohérente. Encapsulez des opérations complètes : une fonction create_s3_backup(bucket_name, retention_days) peut créer le bucket si nécessaire, configurer les politiques de rétention et lancer la première sauvegarde, avec sa propre gestion d'erreurs.
Pour les gros projets, découpez en fichiers : source ./functions/s3_ops.sh et gardez le script principal centré sur l'orchestration.
Scénarios concrets
Sauvegardes et rétention sur S3
Gérer les données brutes, les modèles et les vidéos finales est une tâche quotidienne. Un script peut déplacer les objets récents vers des classes de stockage moins coûteuses selon leur âge : stockage Standard, puis Infrequent Access après 30 jours, puis Glacier Deep Archive après 180 jours. Vérifiez l'intégrité avec aws s3 sync et la comparaison de checksums, et nettoyez les fichiers temporaires orphelins associés à des tâches échouées pour éviter des frais inutiles.
Cycle de vie des instances EC2
Les instances GPU coûtent cher si elles restent allumées sans rien faire. Un script peut interroger l'état de la file de tâches : si elle est vide depuis plus de 15 minutes et que les instances de rendu sont inactives, il les arrête. En cas de pic de demande, il peut démarrer un groupe d'instances Spot préconfigurées. Le taggage est indispensable ici : chaque instance porte son rôle et l'ID du travail qu'elle exécute, ce qui permet de filtrer précisément les machines à arrêter ou démarrer.
Déploiements rapides et mises à jour
Sans passer par Terraform ou CloudFormation, un script Bash suffit pour des ajustements ad hoc : télécharger de nouveaux binaires, mettre à jour des variables d'environnement, redémarrer les instances de service. Vous pouvez aussi déclencher une invalidation de cache CloudFront après une mise à jour majeure de contenu, pour que les utilisateurs voient immédiatement la dernière version.
Intégrer avec le reste de la stack
L'automatisation ne doit pas rester isolée. Le client psql peut être appelé depuis Bash pour des mises à jour massives de statuts, avec des identifiants lus depuis des variables d'environnement, jamais en dur. Et grâce à curl, un script peut notifier une API backend quand un rendu est terminé, ou envoyer une alerte via SNS ou un webhook en cas d'échec. C'est ainsi que vos scripts deviennent des composants du flux de travail, pas des îlots.
En résumé
L'automatisation AWS CLI avec Bash repose sur quelques principes : profils et secrets bien gérés, sortie JSON systématique, set -e et trap pour la robustesse, boucles pour les traitements de masse, fonctions pour la réutilisabilité. Commencez petit — un script de sauvegarde, puis un script d'arrêt d'instances — et faites évoluer votre bibliothèque de scripts au fil des besoins. C'est le moyen le plus direct de réduire les coûts d'infrastructure et de libérer du temps pour des tâches qui comptent vraiment.
