Terraform — Provider AWS
| 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é) :
- variables d'environnement (
AWS_ACCESS_KEY_ID, etc.) — à éviter en usage courant ; - fichier
~/.aws/credentialset profils nommés (profile) — pratique en poste de travail ; - 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
- AWS — CLI, organisation des comptes, supervision
- Terraform — Concepts fondamentaux — state, backend, verrouillage
- Terraform — Provider Azure · Terraform — Provider GCP
- Terraform — Modules et variables