Introduction

La transformation DevOps n’est pas seulement une question d’outils : c’est un changement de culture et de méthode. Elle repose sur trois piliers : l’automatisation, la collaboration et la fiabilité continue (observabilité, respect des SLO, capacité de retour arrière). Dans AWS, ces principes prennent vie grâce à un écosystème riche : infrastructure as code, pipelines CI/CD, orchestration, observabilité et déploiement progressif.

Ce chapitre explore comment construire un cycle complet d’automatisation sur AWS, depuis la création des infrastructures avec Terraform, CloudFormation ou le CDK, jusqu’aux pipelines de déploiement et aux stratégies avancées de mise en production.

Infrastructure as Code : Terraform, CloudFormation et AWS CDK

1. Le principe de l’Infrastructure as Code (IaC)

L’Infrastructure as Code (IaC) consiste à décrire l’infrastructure sous forme de code, plutôt que de la configurer manuellement dans la console AWS. Ce paradigme apporte plusieurs avantages majeurs :

Traçabilité : tout changement est versionné dans Git.
Reproductibilité : la même configuration peut être déployée dans plusieurs environnements.
Automatisation : les déploiements deviennent rapides, cohérents et audités.

Au lieu d’un « clic » dans la console, on écrit des fichiers décrivant les ressources à créer : VPC, sous-réseaux, IAM Roles, S3, EC2, EKS… Ces fichiers sont exécutés par des outils spécialisés, garantissant que l’état réel correspond à la configuration déclarée.

Boucle de gestion IaC (schéma conceptuel, illustré ici avec le vocabulaire Terraform) : code --> plan --> apply --> drift detection

2. AWS CloudFormation : la solution native

AWS CloudFormation est le service natif d’IaC d’AWS. Il permet de décrire des piles (« stacks ») à l’aide de fichiers YAML ou JSON.

Un exemple simple...

CI/CD avec AWS CodePipeline, GitOps et ArgoCD

1. La chaîne CI/CD sur AWS

L’intégration continue (CI) et le déploiement continu (CD) sont essentiels au DevOps. AWS propose une suite complète et intégrée :

CodeCommit : dépôt Git managé ;
CodeBuild : exécution des builds, tests et packaging ;
CodeDeploy : déploiement automatique sur EC2, ECS, Lambda ;
CodePipeline : orchestration des étapes.

Un pipeline typique en YAML :

Stages: 
  - Name: Source 
    Actions: 
      - Name: Checkout 
        ActionTypeId: 
          Category: Source 
          Owner: AWS 
          Provider: CodeCommit 
  - Name: Build 
    Actions: 
      - Name: RunBuild 
        ActionTypeId: 
          Category: Build 
          Owner: AWS 
          Provider: CodeBuild

Chaîne CI/CD : Commit -->...

Gérer les mises en production : Blue/Green, Canary et Feature Flags

1. Déploiement Blue/Green

Le déploiement Blue/Green consiste à maintenir deux environnements identiques :

Blue : version en production ;
Green : nouvelle version.

Une fois validée, la bascule se fait via le Load Balancer (ALB) ou Route 53. En cas d’incident, le rollback est immédiat.

Exemple concret

Un service ECS déploie une nouvelle image Docker dans la « green » task definition. Une fois les tests réussis, CodeDeploy redirige le trafic de « blue » vers « green ».

Avantage

Aucun temps d’arrêt. L’utilisateur ne voit jamais la transition.

Blue/Green Deployment : deux environnements actifs alternés

2. Déploiement Canary

Le Canary Deployment consiste à exposer la nouvelle version à un petit pourcentage d’utilisateurs avant généralisation. On parle d’« échantillon témoin », comme dans l’industrie.

Sur AWS, on peut gérer ce routage progressif avec :

CodeDeploy (ECS/Lambda) ;
App Mesh ou API Gateway (Weighted Routing) ;
Route 53 Weighted Routing Policies.