Utiliser Terraform avec AWS : Le Guide Complet
Utiliser Terraform avec AWS : Le Guide Complet
La gestion d'infrastructure a évolué, passant des clics manuels dans la console et des scripts fragiles à du code déclaratif versionné, révisé et partagé. Pour les équipes qui construisent sur Amazon Web Services, Terraform est devenu la référence de l'infrastructure en tant que code (IaC)—et savoir comment utiliser Terraform avec AWS efficacement est désormais une compétence essentielle pour les ingénieurs cloud. Ce guide vous accompagne dans l'ensemble du workflow, de la configuration du fournisseur AWS au déploiement de ressources réelles avec des pratiques de niveau production.
Ce que vous allez apprendre
À la fin de ce guide, vous maîtriserez l'ensemble du workflow Terraform sur AWS—de la configuration du fournisseur et la définition des ressources à la gestion d'état et la collaboration en équipe. Vous serez capable de déployer, mettre à jour et détruire une infrastructure AWS en toute confiance grâce à l'approche déclarative de Terraform, et vous repartirez avec un modèle mental clair pour structurer vos propres projets. Vous apprendrez également des garde-fous pratiques pour éviter des erreurs coûteuses comme le déploiement sur le mauvais compte AWS.
Comprendre les concepts fondamentaux : Fournisseurs, Ressources et État
Avant d'écrire une quelconque configuration, il est utile de comprendre les blocs de construction fondamentaux de Terraform. Contrairement à AWS CloudFormation—qui est natif d'AWS et suppose que les ressources sont créées dans un compte AWS—Terraform est agnostique au cloud et vous oblige à déclarer explicitement des fournisseurs qui interagissent avec des API spécifiques.
Qu'est-ce qu'un fournisseur ?
Un fournisseur est un plugin qui sert de pont entre Terraform et une plateforme cible. Le fournisseur AWS est ce qui permet à Terraform d'appeler les API AWS pour créer, lire, mettre à jour et supprimer des ressources. Comme Terraform prend en charge plusieurs fournisseurs—AWS, Kubernetes, Helm, et même des outils SaaS tiers—vous pouvez provisionner un cluster Amazon EKS et y déployer des charts Helm dans la même configuration.
Ressources et sources de données
Une ressource définit un composant de votre infrastructure : une instance EC2, un bucket S3 ou un groupe de sécurité. Les ressources sont déclarées de manière déclarative—vous spécifiez ce que vous voulez, et Terraform détermine comment le créer.
Une source de données, quant à elle, interroge AWS pour obtenir des informations sur des ressources existantes. Par exemple, au lieu de coder en dur un ID d'AMI qui pourrait changer ou varier selon la région, vous pouvez utiliser une source de données pour récupérer dynamiquement la dernière AMI Amazon Linux 2023.
L'état : La source de vérité
Terraform maintient un fichier d'état qui suit les ressources qu'il gère. Cet état fait le lien entre votre configuration et l'infrastructure réelle, et il est essentiel pour planifier les mises à jour, détecter les dérives et nettoyer les ressources proprement. Pour les environnements d'équipe, il est fortement recommandé de stocker l'état dans un backend distant comme Amazon S3 pour éviter les conflits et garantir la cohérence.
Pour commencer : Installation des outils et configuration des identifiants AWS
Prérequis
Avant d'écrire une seule ligne de configuration, préparez votre environnement local :
- Terraform CLI 1.5 ou ultérieur – Téléchargez le binaire et ajoutez-le à votre PATH.
- AWS CLI – Installez-le et configurez-le avec des identifiants IAM disposant des autorisations suffisantes.
- Un compte AWS – Utilisez le niveau gratuit pour vous entraîner et éviter des frais imprévus.
Authentification du fournisseur AWS
Le fournisseur AWS de Terraform s'authentifie en utilisant les mêmes méthodes que l'AWS CLI. L'approche la plus simple consiste à définir des variables d'environnement avec vos identifiants IAM :
export AWS_ACCESS_KEY_ID=<votre_clef_acces>
export AWS_SECRET_ACCESS_KEY=<votre_clef_secrete>
Alternativement, Terraform peut lire le fichier d'identifiants par défaut situé dans ~/.aws/credentials.
Étape 1 : Écrire votre première configuration Terraform
Créez un nouveau répertoire pour votre projet et définissez le fournisseur et les ressources. Les fichiers de configuration Terraform utilisent le langage de configuration HashiCorp (HCL) et se terminent par .tf.
Le bloc terraform
Le bloc terraform configure Terraform lui-même, y compris les sources des fournisseurs et les contraintes de version. Épingler les versions des fournisseurs évite les dérives inattendues lors des mises à jour.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
required_version = ">= 1.2"
}
L'argument source pointe vers le fournisseur dans le registre Terraform. HashiCorp maintient le fournisseur AWS, donc sa source est hashicorp/aws.
Le bloc provider
Le bloc provider configure le fournisseur AWS, y compris la région par défaut :
provider "aws" {
region = "us-west-2"
}
Définir une instance EC2
Un bloc resource déclare un composant d'infrastructure. Voici comment définir une instance EC2 en utilisant une source de données pour récupérer la dernière AMI Ubuntu :
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477"] # Canonical
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
}
}
resource "aws_instance" "app_server" {
ami = data.aws_ami.ubuntu.id
instance_type = "t2.micro"
tags = {
Name = "terraform-demo"
}
}
Utiliser une source de données pour l'AMI rend votre configuration dynamique et portable entre les régions.
Étape 2 : Initialiser, planifier et appliquer
Le workflow Terraform se compose de trois commandes principales :
terraform init
Initialisez le répertoire de travail. Cela télécharge les plugins de fournisseur requis et configure le backend :
terraform init
Terraform lit le bloc required_providers et installe la version du fournisseur AWS que vous avez spécifiée.
terraform plan
Prévisualisez les modifications que Terraform apportera à votre infrastructure :
terraform plan
Le plan montre les ajouts, modifications et suppressions—c'est votre occasion de détecter les erreurs avant d'appliquer.
terraform apply
Appliquez la configuration pour créer les ressources. Terraform affichera à nouveau le plan et demandera une confirmation :
terraform apply
Tapez yes pour continuer. Terraform provisionnera l'instance EC2 et affichera les résultats.
terraform destroy
Lorsque vous avez terminé, nettoyez pour éviter des frais :
terraform destroy
Terraform calcule ce qui doit être supprimé en fonction du fichier d'état et demande une confirmation.
Étape 3 : Ajouter un groupe de sécurité et une logique de provisionnement
Un serveur est inutile sans accès réseau. Ajoutez un groupe de sécurité pour contrôler le trafic entrant et sortant :
resource "aws_security_group" "web" {
name = "web-sg"
description = "Autoriser HTTP et SSH"
vpc_id = var.vpc_id
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["10.0.0.0/16"] # Restreindre SSH
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
Attachez le groupe de sécurité à votre instance EC2 en référençant aws_security_group.web.id dans l'argument vpc_security_group_ids.
Automatiser l'installation de logiciels avec les données utilisateur
Utilisez les données utilisateur EC2 pour installer des logiciels au premier démarrage de l'instance. Par exemple, pour installer Nginx sur Amazon Linux 2023 :
resource "aws_instance" "web" {
ami = data.aws_ami.al2023.id
instance_type = "t3.micro"
vpc_security_group_ids = [aws_security_group.web.id]
key_name = var.key_name
user_data = <<-EOF
#!/bin/bash
dnf install -y nginx
systemctl start nginx
echo "<h1>Bonjour depuis Terraform</h1>" > /usr/share/nginx/html/index.html
EOF
}
Les données utilisateur s'exécutent lors du démarrage initial et constituent un moyen simple d'amorcer des instances sans outils de gestion de configuration supplémentaires.
Étape 4 : Utiliser les variables, les sorties et les modules
Variables pour la réutilisabilité
Coder en dur des valeurs rend les configurations fragiles. Définissez des variables dans un fichier variables.tf :
variable "instance_type" {
description = "Type d'instance EC2"
type = string
default = "t2.micro"
}
variable "aws_region" {
description = "Région AWS"
type = string
default = "us-west-2"
}
Référencez les variables dans votre configuration avec var.instance_type.
Sorties pour afficher des informations
Les sorties vous permettent de récupérer des informations après l'application, comme l'adresse IP publique de l'instance :
output "instance_public_ip" {
description = "IP publique de l'instance EC2"
value = aws_instance.app_server.public_ip
}
Modules pour des composants réutilisables
Les modules sont des conteneurs pour plusieurs ressources qui peuvent être partagées entre projets. Le registre Terraform propose des milliers de modules communautaires, et vous pouvez également écrire les vôtres. L'utilisation de modules maintient votre configuration racine propre et favorise la réutilisabilité.
Étape 5 : État distant et collaboration en équipe
Pour tout environnement d'équipe, stocker l'état localement est dangereux—il peut devenir obsolète ou entrer en conflit avec les modifications d'autres utilisateurs. Configurez un backend distant, généralement avec Amazon S3 et DynamoDB pour le verrouillage d'état :
terraform {
backend "s3" {
bucket = "mon-bucket-d-etat-terraform"
key = "prod/terraform.tfstate"
region = "us-west-2"
encrypt = true
dynamodb_table = "verrous-terraform"
}
}
Cette configuration garantit que l'état est partagé et verrouillé pendant les opérations d'application, empêchant les modifications simultanées qui pourraient corrompre le fichier d'état.
Étape 6 : Bonnes pratiques de sécurité
Restreindre le fournisseur à des comptes AWS spécifiques
L'une des erreurs les plus dangereuses est d'exécuter Terraform contre le mauvais compte AWS—par exemple, vouloir déployer en développement mais utiliser accidentellement des identifiants de production. Le paramètre allowed_account_ids dans le bloc du fournisseur crée un filet de sécurité :
provider "aws" {
region = "us-west-2"
allowed_account_ids = ["123456789012"] # Uniquement ce compte
}
Si vous tentez d'exécuter Terraform avec des identifiants d'un compte différent, le plan générera immédiatement une erreur, évitant des erreurs coûteuses.
Utiliser des rôles IAM, pas des clés statiques
Pour les instances EC2, utilisez toujours des profils d'instance IAM plutôt que d'intégrer des identifiants statiques. Cela améliore la sécurité et simplifie la rotation des identifiants.
Contrôle de version et révision
Toutes les configurations Terraform doivent être stockées dans un système de contrôle de version. Les demandes de tirage pour les modifications d'infrastructure doivent être révisées comme le code applicatif—c'est la valeur fondamentale de l'IaC.
Comment utiliser Terraform avec AWS dans les pipelines CI/CD
Intégrer Terraform dans les pipelines CI/CD automatise les déploiements et garantit la cohérence. Un workflow GitHub Actions typique :
name: Terraform Apply
on:
push:
branches: [ main ]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: hashicorp/setup-terraform@v1
- name: Terraform Init
run: terraform init
- name: Terraform Plan
run: terraform plan
- name: Terraform Apply
run: terraform apply -auto-approve
Cette approche élimine les étapes d'application manuelles et garantit que chaque fusion sur la branche principale déploie une infrastructure qui a été révisée et testée.
Questions fréquemment posées
1. Quelle est la différence entre Terraform et AWS CloudFormation ?
Terraform est agnostique au cloud et prend en charge plusieurs fournisseurs—AWS, Azure, Google Cloud et des centaines d'autres—tandis que CloudFormation est exclusif à AWS. Terraform offre également un workflow plus flexible avec des étapes de planification/application et prend en charge une gamme plus large de ressources tierces.
2. Où Terraform stocke-t-il l'état de mon infrastructure ?
Par défaut, Terraform stocke l'état dans un fichier local terraform.tfstate. Pour la production et l'utilisation en équipe, vous devez configurer un backend distant comme Amazon S3 pour stocker l'état de manière centralisée avec verrouillage pour éviter les conflits.
3. Que sont les modules Terraform et pourquoi devrais-je les utiliser ?
Les modules sont des conteneurs pour plusieurs ressources qui peuvent être réutilisées entre projets. L'utilisation de modules réduit la duplication, garantit la cohérence et permet de partager des modèles d'infrastructure entre équipes via le registre Terraform.
4. Comment éviter de déployer accidentellement sur le mauvais compte AWS ?
Utilisez le paramètre allowed_account_ids dans votre bloc de fournisseur AWS pour restreindre Terraform à des ID de compte spécifiques. Si les identifiants ne correspondent pas à la liste autorisée, Terraform générera une erreur avant d'apporter des modifications.
5. Quelle est la différence entre terraform plan et terraform apply ?
terraform plan prévisualise les modifications que Terraform apporterait à votre infrastructure. terraform apply exécute ces modifications. Exécutez toujours plan d'abord pour détecter les erreurs avant de modifier les ressources.
Sources
- Terrateam, "Comment déployer Nginx avec Terraform sur AWS" (2026)
- AWS Prescriptive Guidance, "Comprendre les ressources et fournisseurs Terraform" (2024)
- AWS Prescriptive Guidance, "Bonnes pratiques du fournisseur AWS Terraform" (2024)
- HashiCorp Developer, "Créer une infrastructure" (2025)
- Refine, "Premiers pas avec Terraform sur AWS" (2024)
- DevelopersIO, "allowed_account_ids du fournisseur AWS Terraform" (2025)
- GitHub, "Dépôt terraform-basics-aws"
— Editorial Team
Aucun commentaire pour le moment.