Infrastructure as Code AWS — CloudFormation et CDK TypeScript DOP-C02 2026

📍 Article principal du cluster : AWS DevOps Engineer Professional DOP-C02 — guide pratique 2026

Ce tutoriel fait partie du cluster certification AWS DOP-C02. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Le domaine 2 « Configuration Management and IaC » pèse 17 % de l’examen DOP-C02. Il teste votre maîtrise de CloudFormation (le service IaC natif AWS) et d’AWS CDK (Cloud Development Kit, qui génère des templates CloudFormation à partir de code TypeScript, Python, Java ou Go). Ce tutoriel construit le même stack VPC + ECS + ALB d’abord en CloudFormation pur, puis en CDK TypeScript pour comparer. Vous comprendrez les trade-offs et les patterns à privilégier selon le contexte.

Prérequis

• AWS CLI v2 configuré avec admin access
• Node.js 22+ et npm installés
• 40 minutes

Étape 1 — Stack CloudFormation simple en YAML

On commence par un template CloudFormation YAML qui crée un bucket S3 paramétrable. C’est le « hello world » de CFN et c’est exactement le format qui apparaît dans les questions d’examen.

AWSTemplateFormatVersion: '2010-09-09'
Description: Demo bucket with parameter

Parameters:
  BucketSuffix:
    Type: String
    Default: dop-c02-demo
    AllowedPattern: '[a-z0-9-]+'

Mappings:
  RegionMap:
    eu-central-1:
      LogPrefix: 'fra'
    eu-west-3:
      LogPrefix: 'cdg'

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

Resources:
  DemoBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub '${BucketSuffix}-${AWS::AccountId}-${AWS::Region}'
      VersioningConfiguration:
        Status: Enabled

Outputs:
  BucketName:
    Value: !Ref DemoBucket
    Export:
      Name: !Sub '${AWS::StackName}-BucketName'

Cinq sections clés à connaître par cœur : Parameters (entrées du template), Mappings (look-up table par clé), Conditions (logique conditionnelle), Resources (le cœur — déclaration des ressources AWS), Outputs (sorties exportables vers d’autres stacks). Toute question CFN à l’examen exploite au moins deux de ces sections.

Étape 2 — Déployer la stack via CLI

La création de stack se fait via `aws cloudformation create-stack`. Pour les mises à jour, on préfère `deploy` qui détecte automatiquement create vs update.

aws cloudformation deploy \
  --template-file demo-bucket.yaml \
  --stack-name dop-c02-demo-bucket \
  --parameter-overrides BucketSuffix=demo123

aws cloudformation describe-stacks --stack-name dop-c02-demo-bucket
aws cloudformation list-exports --query 'Exports[?Name==`dop-c02-demo-bucket-BucketName`]'

La sortie `describe-stacks` montre l’état CREATE_COMPLETE et liste les Outputs. Les exports sont consommables par d’autres stacks via `Fn::ImportValue` — c’est le pattern « cross-stack reference » testé en domaine 2.

Étape 3 — Drift detection

Le drift détecte si une ressource gérée par une stack a été modifiée hors-stack (modification manuelle dans la console). C’est un sujet récurrent à l’examen.

aws cloudformation detect-stack-drift --stack-name dop-c02-demo-bucket
DRIFT_ID=$(aws cloudformation detect-stack-drift --stack-name dop-c02-demo-bucket --query StackDriftDetectionId --output text)
sleep 5
aws cloudformation describe-stack-drift-detection-status --stack-drift-detection-id $DRIFT_ID

Si une modification manuelle a été faite (par exemple changement de versioning du bucket via console), `StackDriftStatus` retourne `DRIFTED` avec la liste des propriétés modifiées. En pratique, on programme `detect-stack-drift` quotidiennement via EventBridge pour alerter l’équipe.

Étape 4 — Initialiser un projet AWS CDK TypeScript

CDK est l’évolution de CloudFormation : on écrit du code TypeScript/Python qui génère des templates CFN à la volée. Avantages : abstraction réutilisable (constructs), validation à la compilation, intégration IDE complète.

npm install -g aws-cdk
cdk --version

mkdir -p /tmp/dop-cdk && cd /tmp/dop-cdk
cdk init app --language typescript
ls
cat lib/dop-cdk-stack.ts

Le projet généré contient `bin/dop-cdk.ts` (entry point), `lib/dop-cdk-stack.ts` (votre stack), `cdk.json` (configuration). C’est l’arborescence standard CDK 2.x.

Étape 5 — Stack CDK équivalente du bucket S3

On reproduit le bucket de l’étape 1 en CDK pour comparer la verbosité.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class DopCdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const bucket = new s3.Bucket(this, 'DemoBucket', {
      versioned: true,
      encryption: s3.BucketEncryption.S3_MANAGED,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    new cdk.CfnOutput(this, 'BucketName', {
      value: bucket.bucketName,
      exportName: 'DopCdkBucketName',
    });
  }
}

Le code est plus court qu’en CFN pour des comportements équivalents — CDK applique automatiquement les bonnes pratiques (encryption par défaut, blockPublicAccess). C’est la philosophie « secure by default » qui plaît aux questions sécurité du domaine 6.

Étape 6 — Déployer la stack CDK

Le déploiement CDK fait deux choses : `synth` génère le template CFN, puis `deploy` l’applique via CloudFormation.

cdk bootstrap  # Une fois par compte/région — crée le bucket pour les artefacts
cdk synth
cdk deploy --require-approval never

`cdk synth` produit le template CloudFormation dans `cdk.out/`. Vous pouvez l’inspecter pour comprendre ce que CDK génère sous le capot. C’est précieux pour le debug et pour les questions « quelle ressource CFN est créée par tel construct CDK ».

Étape 7 — Constructs L1, L2, L3 — la hiérarchie CDK

CDK organise ses APIs en trois niveaux. L1 (ou « Cfn… ») mappe 1:1 avec les ressources CloudFormation — `CfnBucket` est l’équivalent direct de `AWS::S3::Bucket`. Verbose, mais accès complet aux propriétés. L2 est l’API idiomatique avec defaults secure — `Bucket` (sans Cfn) génère un `CfnBucket` plus une politique IAM par défaut. C’est ce qu’on utilise au quotidien. L3 (« Patterns ») compose plusieurs L2 pour des patterns courants — `ApplicationLoadBalancedFargateService` déploie ALB + ECS service + TaskDefinition + LogGroup en une ligne.

import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ecsPatterns from 'aws-cdk-lib/aws-ecs-patterns';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 2 });
const cluster = new ecs.Cluster(this, 'Cluster', { vpc });

new ecsPatterns.ApplicationLoadBalancedFargateService(this, 'Service', {
  cluster,
  cpu: 256,
  memoryLimitMiB: 512,
  desiredCount: 2,
  taskImageOptions: {
    image: ecs.ContainerImage.fromRegistry('public.ecr.aws/nginx/nginx:latest'),
    containerPort: 80,
  },
});

Cette dizaine de lignes génère un template CloudFormation de 700+ lignes. C’est l’avantage majeur de CDK pour les équipes qui doivent répliquer des stacks complexes — gain de productivité 5-10x sur l’écriture, maintenabilité supérieure.

Étape 8 — StackSets pour multi-account

StackSets permet de déployer la même stack dans plusieurs comptes AWS et plusieurs régions simultanément. Indispensable pour les organisations multi-account avec Control Tower.

aws cloudformation create-stack-set \
  --stack-set-name dop-c02-baseline \
  --template-body file://demo-bucket.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

aws cloudformation create-stack-instances \
  --stack-set-name dop-c02-baseline \
  --regions eu-central-1 eu-west-3 \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx

Le mode SERVICE_MANAGED utilise AWS Organizations pour découvrir automatiquement les comptes cibles. Le pattern : déployer une baseline (CloudTrail, Config, GuardDuty) dans tous les comptes nouvellement créés. Tombe en domaine 2 et 6.

Comprendre la différence CFN vs CDK vs Terraform vs Pulumi

Quatre outils IaC majeurs en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer ; vérifier la source officielle AWS avant toute décision technique), chacun avec ses spécificités. CloudFormation est le service AWS natif — JSON/YAML déclaratif, intégration AWS profonde (drift detection, StackSets, Service Catalog). Limitation : verbose pour des stacks complexes. CDK est le wrapper de programmation autour de CFN — plus expressif, type-safe, réutilisable via constructs. Reste limité à AWS principalement (CDKTF étendait à Terraform mais a été sunset par HashiCorp en décembre 2025 ; les projets existants continuent à fonctionner sans nouvelles features). Terraform (HashiCorp) est multi-cloud, écosystème de modules massif, syntaxe HCL déclarative. Standard de fait dans les organisations multi-cloud. Pulumi ressemble à CDK mais multi-cloud — plus jeune, communauté plus restreinte.

Pour DOP-C02, attendez-vous à des questions principalement sur CFN et CDK. Terraform peut être mentionné dans le contexte mais n’est pas le focus. La maîtrise CFN reste fondamentale même quand on utilise CDK — savoir lire un template généré par `cdk synth` est essentiel pour debug.

Erreurs fréquentes

Ajustements pratiques pour Dakar, Abidjan et Bamako

Pour les équipes plateforme en Afrique de l’Ouest, CDK TypeScript est aujourd’hui le choix le plus rentable pour une nouvelle stack : courbe d’apprentissage rapide pour les développeurs Node.js, maintenance simplifiée par rapport à CFN pur, et compatibilité totale avec l’examen DOP-C02. Les organisations multi-account (banques digitales, scale-up tech) doivent maîtriser StackSets pour propager les baseline sécurité automatiquement aux nouveaux comptes — c’est ce qui distingue un junior d’un senior DOP-C02.

Tutoriels frères

• Pipeline CodePipeline + CodeBuild + CodeDeploy ECS
• EventBridge et Lambda — automation réactive et runbooks (à venir)

Pour explorer plus loin

• 🔝 Retour au pilier : AWS DOP-C02 — guide pratique 2026
• CloudFormation User Guide : docs.aws.amazon.com/AWSCloudFormation
• AWS CDK v2 : docs.aws.amazon.com/cdk/v2/guide
• CDK Patterns library : cdkpatterns.com

FAQ

CDK ou Terraform pour mon entreprise ?
CDK si vous êtes 100 % AWS et avez une équipe TypeScript/Python. Terraform si vous opérez du multi-cloud ou si votre équipe préfère HCL. Les deux sont valides, le choix dépend du contexte.

Faut-il connaître CDK Python pour DOP-C02 ?
TypeScript est le focus principal de la documentation officielle. Python est testé occasionnellement. Maîtriser TypeScript suffit pour 95 % des questions.

Mots-clés secondaires : cloudformation tutoriel, aws cdk typescript, drift detection, stacksets multi-account, infrastructure as code aws, dop-c02 iac