Module 2 — AWS CloudFormation : anatomie d'un template, validé réellement

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 9 minutes

Terraform vs CloudFormation

Le Module 1 a démontré Terraform en conditions réelles. CloudFormation répond au même besoin (décrire l’infrastructure en code, calculer et appliquer les changements), mais est propriétaire à AWS — alors que Terraform reste multi-fournisseur.

	Terraform	CloudFormation
Fournisseurs supportés	AWS, Azure, GCP, et des centaines d’autres	AWS uniquement
Format	HCL (`.tf`)	YAML ou JSON
État	Fichier d’état séparé (`.tfstate`), à gérer soi-même ou via un backend distant	Géré entièrement par AWS, invisible pour l’utilisateur
Prévisualisation des changements	`terraform plan`	Change Set
Coût	Gratuit (Terraform CLI)	Gratuit (le service CloudFormation lui-même ne facture rien, seules les ressources créées coûtent)

Pourquoi ce module reste utile même chez une équipe qui a choisi Terraform : de nombreuses entreprises qui utilisent AWS en profondeur ont malgré tout des piles CloudFormation historiques (souvent générées par le AWS Cloud Development Kit, ou CDK, qui compile en CloudFormation) — savoir lire un template CloudFormation reste une compétence utile même sans l’utiliser comme premier choix.

Anatomie d’un template

Un template CloudFormation a une structure fixe, avec des sections optionnelles :

AWSTemplateFormatVersion  (fixe, presque toujours "2010-09-09")
Description
Parameters    → valeurs fournies à la création/mise à jour de la stack
Mappings      → tables de correspondance statiques (ex: AMI par région)
Conditions    → logique conditionnelle (ex: ressource créée seulement en prod)
Resources     → LA seule section obligatoire : les ressources AWS à créer
Outputs       → valeurs à exposer après création (ex: URL, ID d'instance)

Le template, validé réellement (sans compte AWS)

Impossible de créer une vraie stack CloudFormation sans compte AWS actif — mais il est possible de valider réellement la syntaxe et la cohérence d’un template avec cfn-lint, l’outil officiel de validation d’AWS, utilisable hors ligne, sans identifiants cloud.

AWSTemplateFormatVersion: "2010-09-09"
Description: "Template de démonstration — bucket S3 + instance EC2 conditionnelle"

Parameters:
  Environment:
    Type: String
    Default: staging
    AllowedValues: [staging, prod]
  InstanceType:
    Type: String
    Default: t3.micro
    AllowedValues: [t3.micro, t3.small, t3.medium]

Mappings:
  RegionMap:
    us-east-1:
      AMI: ami-0abcdef1234567890
    eu-west-3:
      AMI: ami-0123456789abcdef0

Conditions:
  IsProd: !Equals [!Ref Environment, prod]

Resources:
  AppBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "demo-app-${Environment}-${AWS::AccountId}"
      VersioningConfiguration:
        Status: !If [IsProd, Enabled, Suspended]

  AppInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: !FindInMap [RegionMap, !Ref "AWS::Region", AMI]
      Tags:
        - Key: Environment
          Value: !Ref Environment

Outputs:
  BucketName:
    Value: !Ref AppBucket
    Export:
      Name: !Sub "${AWS::StackName}-BucketName"
  InstanceId:
    Value: !Ref AppInstance

$ cfn-lint cloudformation-demo.yaml
$ echo $?
0

Aucune sortie, code de retour 0 : le template est syntaxiquement valide et cohérent (types de paramètres corrects, toutes les références !Ref/!FindInMap pointent vers quelque chose qui existe réellement dans le template).

Une vraie erreur, provoquée puis détectée

Pour vérifier que cfn-lint détecte réellement les erreurs (et ne se contente pas de toujours répondre « valide »), une faute de frappe a été introduite volontairement : !Ref InstanceType a été changé en !Ref InstanceTypeTypo.

$ cfn-lint cloudformation-demo-broken.yaml

W2001 Parameter InstanceType not used.
cloudformation-demo-broken.yaml:9:3

E1020 'InstanceTypeTypo' is not one of ['Environment', 'InstanceType',
'AppBucket', 'AppInstance', 'AWS::AccountId', ...]
cloudformation-demo-broken.yaml:35:7

exit code: 6

Deux diagnostics, tous deux corrects : une erreur (E1020, référence vers un nom qui n’existe pas) et un avertissement (W2001, le paramètre InstanceType déclaré n’est du coup plus utilisé nulle part — conséquence directe de la même faute de frappe). C’est exactement la même logique que terraform validate, ou que le linter flake8 vu dans le cours CI/CD : détecter les erreurs de cohérence avant de tenter un déploiement, gratuitement et en quelques secondes.

Le cycle de vie réel (nécessite un compte AWS)

Sans identifiants cloud dans cet environnement, les commandes suivantes ne peuvent pas être exécutées ici — mais voici le cycle de vie exact, tel qu’il s’utiliserait avec un compte AWS actif :

# Créer la stack
aws cloudformation create-stack --stack-name demo-app \
  --template-body file://cloudformation-demo.yaml

# Prévisualiser une mise à jour avant de l'appliquer (l'équivalent de "terraform plan")
aws cloudformation create-change-set --stack-name demo-app \
  --template-body file://cloudformation-demo.yaml --change-set-name maj-v2
aws cloudformation describe-change-set --stack-name demo-app --change-set-name maj-v2
aws cloudformation execute-change-set --stack-name demo-app --change-set-name maj-v2

# Détecter une dérive (une modification faite manuellement dans la console AWS,
# en dehors de CloudFormation)
aws cloudformation detect-stack-drift --stack-name demo-app

# Nettoyer
aws cloudformation delete-stack --stack-name demo-app

Le Change Set est le concept le plus important à retenir : il joue exactement le rôle de terraform plan — calculer et afficher ce qui va changer, sans encore l’appliquer — avant d’exécuter le changement avec execute-change-set.

Prochaine étape

Conteneurs et orchestration : Docker avancé, Kubernetes, Helm