Terraform — Provider AWS

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Provider Terraform pour le cloud public
Provider hashicorp/aws
Auth recommandée rôle IAM (instance profile / OIDC), pas de clés en dur
Backend de state S3 + verrouillage DynamoDB
Voir aussi AWS · Terraform — Concepts fondamentaux · Terraform — Provider Azure · Terraform — Provider GCP

Cette page couvre le provider Terraform aws : authentification, ressources typiques et backend de state sur S3. Pour une présentation générale d'AWS (CLI, organisation des comptes, supervision), voir la page dédiée. Pour les notions transverses de state, de backend et de verrouillage, voir Terraform — Concepts fondamentaux.

Déclaration du provider

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region  = "eu-west-3"
  profile = "production"   # profil nommé local, cf. page Aws
}

Authentification

Comme rappelé sur la page AWS, une vraie clé d'accès (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY) ne doit jamais figurer en dur dans le code Terraform ni dans un dépôt. Le provider aws résout les identifiants dans cet ordre (simplifié) :

  1. variables d'environnement (AWS_ACCESS_KEY_ID, etc.) — à éviter en usage courant ;
  2. fichier ~/.aws/credentials et profils nommés (profile) — pratique en poste de travail ;
  3. rôle IAM attaché à la ressource d'exécution : instance profile EC2, rôle de tâche ECS/EKS, ou rôle assumé via OIDC depuis une CI (GitLab CI, GitHub Actions) — c'est la méthode recommandée en production et en pipeline, car elle élimine tout secret statique à stocker.
provider "aws" {
  region = "eu-west-3"

  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/terraform-ci"
  }
}

L'ARN de compte ci-dessus (123456789012) est un identifiant d'exemple générique, non un vrai compte.

Ressources typiques

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"   # exemple, à vérifier selon la région
  instance_type = "t3.micro"

  tags = {
    Name = "web-01"
  }
}

resource "aws_s3_bucket" "data" {
  bucket = "exemple-donnees-prod"

  tags = {
    gere_par = "terraform"
  }
}

resource "aws_iam_role" "app" {
  name = "app-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}
  • aws_instance — instance EC2 (calcul).
  • aws_s3_bucket — bucket de stockage objet S3.
  • aws_iam_role — rôle IAM, brique centrale pour donner des permissions sans clé statique (assumable par un service AWS, une instance, ou en fédération OIDC).

Backend de state : S3 + verrouillage DynamoDB

Le backend recommandé pour AWS stocke le state dans un bucket S3 (versionné et chiffré) et pose son verrou dans une table DynamoDB, pour éviter deux apply concurrents (voir la notion générale de state locking sur Terraform — Concepts fondamentaux).

terraform {
  backend "s3" {
    bucket         = "exemple-tfstate-prod"
    key            = "infra/network/terraform.tfstate"
    region         = "eu-west-3"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Prérequis à créer une seule fois (hors Terraform, ou via un bootstrap séparé) :

resource "aws_s3_bucket" "tfstate" {
  bucket = "exemple-tfstate-prod"
}

resource "aws_s3_bucket_versioning" "tfstate" {
  bucket = aws_s3_bucket.tfstate.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_dynamodb_table" "locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Depuis Terraform 1.10, le backend S3 gère nativement le verrouillage via une fonctionnalité S3 conditionnelle sans DynamoDB (à vérifier selon la version) ; la table DynamoDB reste la méthode la plus répandue et documentée pour les versions antérieures.

Voir aussi