Terraform + AWS : des états géants aux déploiements en 3 minutes

“Nous n’avons pas touché à notre infrastructure AWS depuis 3 mois de peur de casser quelque chose”. Cela te rappelle quelque chose ? La solution n’est pas de changer d’outil, c’est de changer de méthodologie.

Le mensonge que nous avons cru

Nous commençons tous de la même façon : “Nous allons faire Infrastructure as Code, ça va être génial”. Et effectivement, les premiers jours sont magiques. Tu crées ton premier VPC, tes groupes de sécurité, quelques instances…. Tout fonctionne. Tu te sens comme un magicien.

Puis vient la réalité.

Six mois plus tard, tu as des états géants, des modules couplés jusqu’à la gueule, et chaque changement est une roulette russe. Ça te rappelle quelque chose ?

1. terraform plan → 20 minutes d’attente
2. Plan de 400 lignes que personne ne comprend
3. “Es-tu sûr de vouloir appliquer ceci ?”
4. Trois heures de débogage parce que quelque chose s’est mal passé à la ligne 247.

Mais il y a un facteur que peu d’équipes prennent en compte…

Ce qui fonctionne vraiment (et pourquoi personne ne te le dit)

Après avoir sauvé des dizaines de projets Terraform, la formule est plus simple que tu ne le penses :

Petits États + modules intelligents + GitOps non effrayants.

États par couche (pas par projet)

Oublie “un État pour les gouverner tous”. Divise comme ceci :

terraform/
├── network/     # VPC, subnets, NAT gateways
├── data/        # RDS, ElastiCache  
├── compute/     # EKS, ECS, ASGs
└── apps/        # ALBs, Route53

Chaque couche évolue de manière indépendante. L’équipe chargée des données peut mettre à jour RDS sans toucher au réseau. Cela peut changer la donne.

L’astuce de l’état distant

La magie consiste à relier les couches sans les coupler :

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "company-terraform-states"
    key    = "network/terraform.tfstate"
  }
}

# Usar outputs de otra capa
subnet_id = data.terraform_remote_state.network.outputs.private_subnet_id

Modules sans maux de tête

Pour chaque type de charge de travail, un module spécifique :

• secure-webapp/ – ALB + WAF + instances
• microservice/ – Service EKS + entrée + surveillance
• data-pipeline/ – Lambda + SQS + RDS avec sauvegardes

Pas de modules “universels” nécessitant 47 paramètres.

Le multi-cloud est là

C’est là que les choses deviennent intéressantes. De nombreuses équipes adoptent des stratégies hybrides : AWS pour les applications critiques, OpenStack pour le développement et les tests.

Pourquoi ? Coût et contrôle.

# Mismo módulo, diferente cloud
module "webapp" {
  source = "./modules/webapp"
  
  # En OpenStack para dev
  provider = openstack.dev
  instance_type = "m1.medium"
  
  # En AWS para prod  
  # provider = aws.prod
  # instance_type = "t3.medium"
}

L’avenir n’est pas “AWS ou rien”. C’est la flexibilité architecturale. Le pouvoir de choisir la solution que tu veux quand tu le veux et en fonction de ton budget.

OpenTofu change les règles du jeu

Avec les changements apportés à Terraform, OpenTofu devient le choix le plus judicieux. Même syntaxe, gouvernance open source, zéro enfermement dans un fournisseur.

L’avantage est brutal : tu peux migrer progressivement sans changer une seule ligne de code. Parfait pour les équipes qui veulent du contrôle sans drame.

La question que tu dois te poser

Ta dernière application de terraformation t’a-t-elle fait perdre des années de vie ?

Si la réponse est oui, le problème n’est pas technique. Il est d’ordre méthodologique.

Les équipes qui réussissent ne sont pas celles qui connaissent toutes les ressources sur AWS. Ce sont celles qui mettent en œuvre des méthodologies qui évoluent sans souffrir.

Reconnais-tu ces symptômes dans ton équipe ? La différence entre le succès et l’enfer réside dans l’application des bonnes techniques dès le départ.

Si tu veux approfondir ces méthodologies, nos cours Terraform/OpenTofu couvrent tout, des fondamentaux aux GitOps avancés avec des cas réels multi-cloud.