Déployer une Infrastructure Cloud Résiliente avec Terraform
Construire une infrastructure cloud résiliente : retour d'expérience multi-cloud
La résilience d'une infrastructure cloud ne se décrète pas, elle se construit. Après avoir architecturé des infrastructures sur AWS, GCP, Scaleway, OVH Cloud et Outscale avec Terraform, voici les patterns qui assurent une disponibilité maximale.
Le multi-AZ : la base de la résilience sur AWS
Chez F2R2, l'architecture AWS Multi-Compte était déployée sur 3 zones de disponibilité (AZ) par défaut. Le VPC Terraform module créait automatiquement des subnets dans chaque AZ, et les services critiques (EKS, Aurora PostgreSQL, ElastiCache) étaient distribués sur les 3 zones. Si une AZ tombe (ce qui arrive : AWS a eu des pannes de zone en 2023), les services continuent de fonctionner sur les deux autres.
Le pattern Terraform pour le multi-AZ est simple mais doit être systématique : chaque ressource qui supporte le multi-AZ doit être configurée explicitement. Pour Aurora, c'est le paramètre availability_zones. Pour EKS, ce sont les subnets du node group qui doivent couvrir plusieurs AZ. Pour les ALB, les subnets cibles.
La sauvegarde et la restauration
Chez Coopengo (HDS sur AWS), la réglementation imposait des sauvegardes quotidiennes avec une rétention de 30 jours et des tests de restauration mensuels. Terraform gérait les politiques de backup AWS Backup, les snapshots RDS automatiques, et les lifecycle policies S3 pour la rétention.
Le test que j'ai rendu obligatoire : une restauration de la base de données de production dans un environnement de test, automatisée par un pipeline CI mensuel. Le Job Terraform provisionnait une instance RDS temporaire à partir du dernier snapshot, les tests de validation tournaient, puis l'instance était détruite. Sans ce test automatisé, nous n'aurions jamais découvert qu'un changement de parameter group avait rendu les snapshots incompatibles avec la version actuelle d'Aurora.
L'Infrastructure as Code résiliente elle-même
Le state Terraform est un single point of failure. Si le state est corrompu ou perdu, vous ne pouvez plus gérer votre infrastructure. Mon setup pour protéger le state : bucket S3 avec versioning (chaque modification du state crée une nouvelle version), encryption SSE-S3, DynamoDB pour le locking (empêche les modifications concurrentes), et un bucket de réplication dans une autre région pour le disaster recovery.
Chez Bloomflow, nous avions un state par layer d'infrastructure (réseau, base de données, Kubernetes, applications). Cette séparation limitait l'impact d'un problème de state à une seule couche et réduisait le temps de terraform plan.
Le monitoring de l'infrastructure
Terraform provisionne l'infrastructure, mais il ne la surveille pas. La surveillance est gérée par des outils dédiés, eux-mêmes provisionnés par Terraform. Chez F2R2, les modules Terraform incluaient systématiquement les alarmes CloudWatch associées : alarme sur l'utilisation CPU d'Aurora (seuil 80%), alarme sur la latence de l'ALB (seuil 500ms P99), alarme sur l'espace disque des volumes EBS.
Chez Metronome sur OVH Cloud, la stack de monitoring (Grafana, Prometheus, Loki) était elle-même déployée via Helm sur le cluster Kubernetes, avec les dashboards et les alertes provisionnés en code. Tout était versionné dans Git et déployé par ArgoCD.
Le Disaster Recovery en pratique
Chez Earny SA, la migration GCP vers AWS s'est faite sans downtime. La stratégie : déployer la nouvelle infrastructure AWS en parallèle avec Terraform, migrer les données pendant que l'ancienne infrastructure GCP continuait de servir le trafic, basculer le DNS une fois la synchronisation terminée, et garder l'infrastructure GCP en standby pendant 2 semaines avant de la détruire.
Ce plan de DR a été documenté, testé, et exécuté sans incident. La clé : chaque étape était scriptée et automatisée avec Terraform. Aucune action manuelle dans la console AWS ou GCP. La migration a pris 3 jours au total, dont 2 jours de synchronisation de données et 1 jour de bascule et validation.
Le coût de la résilience
La résilience a un coût. Le multi-AZ double ou triple certaines ressources (NAT Gateway, instances de base de données). Les sauvegardes consomment du stockage. Le monitoring ajoute des instances. Chez F2R2, l'audit de 15 jours a permis d'identifier que certaines ressources de résilience étaient surdimensionnées (3 NAT Gateways pour un trafic qui en nécessitait 1), contribuant aux 19% d'économies réalisées. La résilience doit être calibrée au juste besoin.