Optimiser Cloud avec Infrastructure as Code : Clés du Succès
Introduction
L'Infrastructure as Code n'est plus une option mais un prérequis pour toute infrastructure cloud sérieuse. En 15 ans, je suis passé de scripts bash artisanaux à Puppet, puis Ansible, et enfin Terraform. Chaque étape a apporté plus de fiabilité et de reproductibilité. Voici les clés de l'IaC que j'ai distillées à travers des projets sur AWS, GCP, Azure, OVH, Scaleway et Outscale.
Terraform pour le provisionnement, Ansible pour la configuration
La distinction est fondamentale : Terraform crée et gère les ressources cloud (VPC, instances, bases de données), Ansible configure les machines (packages, services, fichiers de configuration). Chez Epiconcept, j'utilisais Ansible pour configurer les serveurs : installation de Docker, configuration de MariaDB, déploiement des applications. La même approche ne fonctionnait pas pour le cloud : Ansible peut créer des ressources AWS, mais il ne gère pas l'état (state) et les dépendances entre ressources aussi bien que Terraform. Chez F2R2, Terraform gérait les 25 modules d'infrastructure AWS, et Ansible n'intervenait que pour la configuration des bastion hosts. Cette séparation claire des responsabilités évite les conflits et simplifie la maintenance.
L'organisation modulaire de Terraform
Un monolithe Terraform est ingérable au-delà de 500 lignes. Chez F2R2, j'avais organisé l'infrastructure en modules emboîtables : un module vpc qui exportait les subnet IDs, un module eks qui consommait ces IDs, un module aurora qui créait la base dans le même VPC, et un module security qui déployait WAF et GuardDuty. Chaque module avait son propre state dans un bucket S3 dédié. Les dépendances entre modules passaient par des terraform_remote_state data sources. Cette architecture permettait à 3 personnes de travailler simultanément sur des modules différents sans conflits de state, et le blast radius d'un terraform destroy accidentel était limité au module impacté.
Les tests d'infrastructure automatisés
Tester l'infrastructure est aussi important que tester le code. Chez F2R2, chaque module Terraform avait des tests à trois niveaux : terraform validate + tflint pour la syntaxe (10 secondes), terraform plan avec analyse des changements pour la cohérence (1 minute), et Terratest pour les tests d'intégration qui créaient réellement les ressources dans un compte AWS de test (10 minutes). Un test Terratest vérifiait par exemple que le cluster EKS était accessible, que les Security Groups n'ouvraient pas de ports non autorisés, et que le WAF bloquait bien les requêtes malveillantes. Le coût des ressources éphémères de test (environ 5 euros par run) était négligeable comparé au coût d'une erreur de configuration en production.
L'IaC multi-cloud : l'abstraction qui fonctionne
Chez Bloomflow, avec des clients sur 4 cloud providers, l'IaC multi-cloud était un défi. J'ai choisi de ne PAS abstraire les providers dans des modules génériques (ce qui mène à un "least common denominator" qui n'exploite aucun provider correctement). À la place, chaque provider avait ses propres modules Terraform, mais avec une interface cohérente : les mêmes variables d'entrée (cluster_name, node_count, instance_type) et les mêmes outputs (kubeconfig, api_endpoint, registry_url). Les modules applicatifs (Helm charts) étaient identiques quel que soit le cloud. Cette approche pragmatique offre le meilleur des deux mondes : spécificité par cloud pour l'infrastructure, uniformité pour les applications.
L'audit et l'optimisation des coûts via l'IaC
L'IaC est un outil puissant pour l'optimisation des coûts. Chez F2R2, l'audit AWS de 15 jours a commencé par l'analyse du code Terraform : instances EC2 surdimensionnées (visible dans les instance_type), RDS sans Reserved Instances, S3 sans lifecycle policies, et CloudWatch logs avec rétention infinie. La correction dans Terraform (downsizing des instances, ajout de lifecycle policies, activation des Reserved Instances) a réduit la facture mensuelle de 19%. Chez TEKYN, l'analyse du Terraform a révélé des distributions CloudFront avec des options de cache sous-optimales qui causaient des coûts de transfer inutiles. L'IaC rend les coûts visibles et modifiables en un commit.
Conclusion
L'Infrastructure as Code est le fondement d'une infrastructure cloud maîtrisée. La séparation Terraform/Ansible, l'organisation modulaire, les tests automatisés, l'approche pragmatique du multi-cloud, et l'optimisation des coûts via le code sont des pratiques qui transforment l'infrastructure d'un centre de coûts opaque en un actif documenté, testé et optimisé. Mon conseil : codez 100% de votre infrastructure, ne laissez aucune ressource créée manuellement via la console.