Terraform 1.11 rend obsolète l’utilisation de DynamoDB pour le verrouillage de state S3. Grâce aux écritures conditionnelles S3 (août 2024), le paramètre use_lockfile = true remplace dynamodb_table.
Résultat : infrastructure simplifiée, coûts réduits, migration en quelques minutes. Le verrouillage DynamoDB est déprécié et sera supprimé dans une future version mineure.

La gestion du verrouillage de state Terraform sur S3 nécessitait une table DynamoDB dédiée.
Cette époque est révolue ! Terraform 1.11 introduit le verrouillage natif S3, simplifiant drastiquement votre infrastructure backend.

Pourquoi ce changement était inévitable

Historiquement, S3 utilisait une cohérence éventuelle (eventual consistency) pour les lectures après écriture, ce qui rendait impossible la gestion fiable du verrouillage directement dans S3. DynamoDB était donc indispensable pour garantir la cohérence forte nécessaire au verrouillage.

Chronologie du changement

Août 2024 : La révolution S3 Conditional Writes

AWS a annoncé en août 2024 le support des écritures conditionnelles dans Amazon S3, permettant de vérifier l’existence d’un objet avant de le créer. Cette fonctionnalité utilise le header HTTP if-none-match avec les requêtes PutObject et CompleteMultipartUpload.

Décembre 2024 : Terraform 1.10 (expérimental)

Terraform 1.10 a introduit le support expérimental du verrouillage natif S3 avec le paramètre use_lockfile. À ce stade, la fonctionnalité était utilisable mais marquée comme expérimentale.

Février 2025 : Terraform 1.11 (GA)

Terraform 1.11 a rendu le verrouillage natif S3 généralement disponible (GA) et a officiellement déprécié les arguments liés à DynamoDB. C’est la version recommandée pour la migration.

Under the Hood : Comment fonctionne S3 Conditional Writes ?

Le mécanisme technique

Les écritures conditionnelles S3 permettent aux clients d’écrire des objets de manière conditionnelle, en s’assurant de ne pas écraser des objets déjà écrits par un autre client. Plus besoin de construire des mécanismes de consensus côté client ou d’effectuer des requêtes API supplémentaires pour vérifier la présence d’un objet.

Le fichier de verrouillage

Lorsque vous activez use_lockfile = true, Terraform crée un fichier de verrouillage dans S3 avec l’extension .tflock. Par exemple, si votre state file est terraform.tfstate, le fichier de verrouillage sera terraform.tfstate.tflock.

La gestion des conflits

Lorsqu’un lock est actif, toute tentative d’écriture par un autre client retourne une erreur 412 Precondition Failed. Terraform gère automatiquement cette erreur et informe l’utilisateur qu’un verrouillage est en place.

Error: Error acquiring the state lock

Error message: operation error S3: PutObject, https response error
StatusCode: 412, api error PreconditionFailed: At least one of the
pre-conditions you specified did not hold

Lock Info:
  ID: 837482e8-441e-9ff6-d30b-333ee83d8fc4
  Path: my-bucket/terraform.tfstate
  Operation: OperationTypeApply
  Who: user@hostname
  Version: 1.11.0

Guide de migration : De DynamoDB à S3 natif

Étape 1 : Configuration actuelle avec DynamoDB

Votre configuration actuelle ressemble probablement à ceci :

terraform {
  required_version = ">= 1.0"

  backend "s3" {
    bucket         = "mon-bucket-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "eu-west-1"

    # Table DynamoDB pour le verrouillage (ancien système)
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Étape 2 : Migration vers le verrouillage natif S3

terraform {
  required_version = ">= 1.11.0"

  backend "s3" {
    bucket  = "mon-bucket-terraform-state"
    key     = "production/terraform.tfstate"
    region  = "eu-west-1"

    # Nouveau : verrouillage natif S3
    use_lockfile = true
    encrypt      = true
  }
}

terraform {
  required_version = "~> 1.10.0"

  backend "s3" {
    bucket  = "mon-bucket-terraform-state"
    key     = "production/terraform.tfstate"
    region  = "eu-west-1"

    # Verrouillage natif S3 (expérimental en 1.10)
    use_lockfile = true
    encrypt      = true
  }
}

terraform {
  required_version = ">= 1.11.0"

  backend "s3" {
    bucket  = "mon-bucket-terraform-state"
    key     = "production/terraform.tfstate"
    region  = "eu-west-1"

    # Les deux systèmes actifs pendant la migration
    dynamodb_table = "terraform-state-lock"
    use_lockfile   = true
    encrypt        = true
  }
}

Étape 3 : Mise à jour des permissions IAM

Le verrouillage natif S3 nécessite des permissions IAM légèrement différentes.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mon-bucket-terraform-state"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::mon-bucket-terraform-state/production/terraform.tfstate"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::mon-bucket-terraform-state/production/terraform.tfstate.tflock"
    }
  ]
}

Étape 4 : Réinitialisation du backend

Après avoir modifié votre configuration, réinitialisez le backend :

terraform init -reconfigure

Étape 5 : Test et validation

Effectuez un test de verrouillage :

# Terminal 1
terraform plan

# Terminal 2 (pendant que le plan tourne)
terraform plan
# Vous devriez voir l'erreur de verrouillage 412

Étape 6 : Nettoyage (optionnel)

Une fois la migration confirmée et stable, vous pouvez supprimer votre table DynamoDB :

aws dynamodb delete-table \
  --table-name terraform-state-lock \
  --region eu-west-1

Les avantages du verrouillage natif S3

Simplification de l’infrastructure

Plus besoin de gérer une ressource DynamoDB supplémentaire :

• ✅ Moins de ressources à provisionner
• ✅ Moins de code à maintenir
• ✅ Moins de points de défaillance

Réduction des coûts

Élimination des charges de lecture/écriture DynamoDB, conduisant à des économies potentielles sur votre facture AWS.

Exemple de coûts économisés :

• Table DynamoDB avec mode provisionné : ~13€/mois minimum
• Table DynamoDB avec mode on-demand : 0,25€ par million d’écritures
• Verrouillage natif S3 : inclus dans les coûts S3 standards

Simplification de la configuration

Comparaison du nombre de lignes de configuration :

Avant (avec DynamoDB) :

# 10 lignes de configuration backend
# + Table DynamoDB à créer et gérer
# + Permissions IAM pour DynamoDB

Après (natif S3) :

# 6 lignes de configuration backend
# Aucune ressource supplémentaire
# Permissions IAM simplifiées

Bonnes pratiques

Gestion des erreurs de verrouillage

# 1. Vérifier l'état du verrouillage
aws s3 ls s3://mon-bucket-terraform-state/production/ | grep tflock

# 2. Forcer le déverrouillage (après vérification !)
terraform force-unlock <LOCK_ID>

# 3. Ou supprimer manuellement le fichier de verrouillage
aws s3 rm s3://mon-bucket-terraform-state/production/terraform.tfstate.tflock

Cas particuliers et limitations

Terraform versions antérieures

Si vous devez maintenir des projets sous Terraform < 1.10, vous devrez continuer à utiliser DynamoDB pour ces projets spécifiques. La cohabitation des deux systèmes dans votre organisation est possible.

Environnements multi-régions

Le verrouillage natif S3 fonctionne par région. Pour des déploiements multi-régions complexes, documentez clairement quelle région héberge quel state file.

Pour aller plus loin

Besoin d’aide pour migrer votre infrastructure ? Chez Berria IT, on accompagne les équipes DevOps dans la modernisation de leur infrastructure as code. Contactez-nous.