Tous les projets

Déploiement d’une architecture AWS à 3 niveaux avec Terraform

Infrastructure AWS à trois niveaux (web, applicatif, données) répartie sur deux zones de disponibilité et entièrement décrite avec Terraform.

Date

12 octobre 2026

Code source

3-tiers-architecture

Auteur

Eyanam TCHALIM

Contexte et objectifs

Ce projet met en place une infrastructure AWS en architecture 3-tiers (web, applicatif, données), décrite et déployée entièrement avec Terraform, afin qu’elle soit hautement disponible, sécurisée et reproductible.

Objectifs, vérifiables dans le code :

• répartir chaque niveau sur deux zones de disponibilité ;
• séparer strictement les flux réseau entre les niveaux ;
• protéger l’entrée publique par un pare-feu applicatif (WAF) ;
• disposer d’une base de données relationnelle résiliente, avec sauvegardes automatiques sur 7 jours ;
• externaliser chaque paramètre variable (tailles d’instances, capacités, plages CIDR, rétention des journaux) pour adapter l’infrastructure à d’autres environnements (dev, staging, prod).

Architecture

Le trafic traverse trois niveaux dupliqués sur deux zones de disponibilité, et seul l’ALB public est exposé à Internet.

Les flèches pleines suivent le chemin d’une requête : Internet Gateway, ALB public (protégé par le WAF), instances web, ALB interne, instances applicatives, puis base de données. La région par défaut est us-east-1.

Plan d’adressage

Le VPC utilise la plage 10.0.0.0/16 ; toutes ces plages sont des variables Terraform.

Routage

• Une table de routage publique, partagée par les deux zones, envoie le trafic par défaut vers l’Internet Gateway.
• Deux tables privées, une par zone, envoient le trafic par défaut vers la NAT Gateway de leur propre zone : la perte d’une zone n’affecte pas l’autre.
• Les sous-réseaux applicatifs et de données d’une zone partagent la même table privée : leurs instances peuvent donc sortir vers Internet par la NAT, sans qu’Internet puisse initier une connexion vers elles.

Services AWS utilisés

L’infrastructure repose sur dix services ou composants AWS, tous créés par Terraform ; les valeurs ci-dessous sont celles par défaut du fichier de variables.

Sécurité

La sécurité repose sur une cascade de groupes de sécurité : chaque niveau n’accepte du trafic que depuis celui qui le précède, et seul l’ALB public reçoit du trafic d’Internet.

Flux autorisés

Au-delà du premier flux, les règles désignent le groupe de sécurité du niveau précédent plutôt qu’une plage d’adresses : elles restent valables même si les adresses changent.

Pare-feu applicatif (WAF)

Une Web ACL WAFv2 est associée à l’ALB public. Elle autorise le trafic par défaut et applique, dans l’ordre :

• le jeu de règles commun AWS ;
• le jeu des entrées malveillantes connues ;
• le jeu de règles contre les injections SQL ;
• la liste de réputation d’adresses IP d’Amazon ;
• une règle de limitation qui bloque une IP au-delà de 2 000 requêtes sur 5 minutes (valeur par défaut, modifiable par variable).

Les journaux du WAF vont dans CloudWatch Logs avec une rétention de 90 jours, et une alarme se déclenche si plus de 100 requêtes sont bloquées sur 5 minutes.

Données et secrets

• La base RDS n’est pas accessible publiquement, son stockage est chiffré et elle n’accepte que le groupe de sécurité du niveau applicatif.
• L’identifiant et le mot de passe de la base sont des variables marquées sensibles ; le mot de passe n’a pas de valeur par défaut et doit faire au moins 8 caractères. Il est fourni au moment du déploiement, jamais écrit dans le code.

Fiabilité et performance

Chaque niveau est dupliqué sur deux zones de disponibilité, de sorte que la perte d’une zone laisse l’autre en service.

• Sauvegardes : sauvegardes automatiques conservées 7 jours, et instantané final conservé si la base est supprimée.
• Contrôles de santé : les groupes cibles interrogent / sur le niveau web et /health sur le niveau applicatif, et l’ALB n’envoie du trafic qu’aux instances saines.
• Capacité : chaque niveau est configuré avec un minimum de 2, un maximum de 4 et une capacité souhaitée de 2 instances. Aucune politique de mise à l’échelle automatique n’est définie : la capacité reste à 2 tant qu’elle n’est pas modifiée.
• Remplacement des instances : les groupes utilisent les contrôles de l’état EC2 ; une instance défaillante est donc remplacée, mais pas une instance qui échouerait seulement au contrôle de santé de l’ALB (voir les pistes d’amélioration).
• Taille : les instances t3.micro et la base db.t3.micro conviennent à une démonstration ; elles sont à redimensionner par variable pour une charge réelle.

Mise en œuvre

Le code est découpé en huit fichiers, un par domaine fonctionnel, pour faciliter la lecture, la maintenance et les revues.

Toutes les valeurs variables sont des variables Terraform avec une valeur par défaut, sauf le mot de passe de la base. Un même code peut donc servir pour dev, staging et production en changeant environment_name et les tailles. Chaque ressource est nommée et étiquetée à partir de ce préfixe, avec l’étiquette ManagedBy = terraform.

Déploiement

Le déploiement suit le flux Terraform standard, depuis le répertoire qui contient les fichiers .tf. Le mot de passe de la base est passé par une variable d’environnement :

export TF_VAR_db_password='<mot-de-passe-d-au-moins-8-caracteres>'

terraform init                # télécharge le fournisseur AWS
terraform plan -out=tfplan    # affiche le plan sans rien appliquer
terraform apply tfplan        # applique le plan validé

Pour supprimer l’environnement après une démonstration, terraform destroy retire toutes les ressources ; l’instantané final de la base est conservé.

Extrait : la base de données

multi_az                = true   # bascule automatique en cas de défaillance
backup_retention_period = 7      # sauvegardes automatiques sur 7 jours
storage_encrypted       = true   # chiffrement du stockage
publicly_accessible     = false  # aucune exposition à Internet
skip_final_snapshot     = false  # instantané final conservé à la suppression

Le bloc commenté dans providers.tf propose un état distant dans S3 avec verrouillage DynamoDB, recommandé dès que plusieurs personnes ou une production sont concernées.

Coûts et optimisation

En fonctionnement permanent, la configuration par défaut coûte environ 186 $ par mois avant trafic ; les NAT Gateways en représentent plus d’un tiers, et détruire l’environnement hors des périodes d’utilisation est le levier le plus efficace.

Estimation des coûts

Hypothèses : région us-east-1, 730 heures par mois, tarifs à la demande relevés le 12 octobre 2026, configuration par défaut du fichier de variables, sans trafic.

Les six adresses IPv4 de la colonne Production se répartissent ainsi : deux pour les NAT Gateways, deux pour l’ALB public (une par zone) et deux pour les instances web, qui reçoivent une adresse publique dans les sous-réseaux publics.

Coûts variables non inclus : traitement des données par les NAT Gateways (0,045 $ par Go), capacités des load balancers (LCU), requêtes inspectées par le WAF (0,60 $ par million), stockage disque des instances et de la base, sauvegardes au-delà de l’espace inclus, journaux CloudWatch. Les tarifs proviennent de la page officielle du WAF et de sources tierces qui reprennent les tarifs AWS ; confirmez-les avec l’AWS Pricing Calculator avant de publier des montants.

Suivi des coûts

• Le fournisseur AWS applique déjà les étiquettes Environment et ManagedBy à toutes les ressources : il suffit de les activer comme étiquettes de répartition des coûts dans la facturation pour suivre ce projet dans Cost Explorer.
• Un budget AWS Budgets avec alerte à 80 % et 100 % protège contre un oubli, ce qui compte ici car les coûts fixes courent même sans trafic.

Solutions de réduction, avec leur compromis

Compromis coût et résilience

Le projet choisit de payer la haute disponibilité : deux NAT Gateways, une base Multi-AZ et deux instances par niveau représentent environ 68 $ par mois de plus que le profil de test. Ce choix se défend en production, mais pas pour un environnement de démonstration, d’où l’intérêt d’externaliser ces paramètres en variables.

Résultats

Le code et l’état Terraform confirment un déploiement complet de l’architecture : 46 ressources gérées, réparties sur deux zones, avec les paramètres de résilience attendus.

Ces constats portent sur la configuration et l’état Terraform. Les fichiers fournis ne contiennent aucune mesure de performance, de charge ou de bascule : ajoutez-en (test de charge, exercice de bascule Multi-AZ) pour étayer les objectifs de disponibilité.

Enseignements et évolutions

Le projet atteint son objectif de base, mais la lecture du code laisse huit points à durcir avant une utilisation en production.

Enseignements

• Décrire l’infrastructure en code la rend reproductible, traçable par le contrôle de version et réplicable sur d’autres environnements (dev, staging) ou d’autres régions pour la reprise après sinistre.
• Externaliser les paramètres en variables permet d’adapter le même code à plusieurs environnements, et de réduire fortement le coût d’un environnement de test.
• Chaîner les groupes de sécurité plutôt que filtrer par plages d’adresses rend les règles lisibles et robustes.
• Planifier un exercice périodique de bascule Multi-AZ et un test de charge du WAF entretient la confiance dans la résilience de la plateforme.

Limites constatées et pistes d’amélioration

Évolutions

• Automatiser terraform plan et terraform apply dans un pipeline CI/CD, avec revue des changements avant application.
• Séparer les environnements avec des fichiers de variables ou des espaces de travail Terraform.
• Ajouter un nom de domaine (Route 53) et du HTTPS de bout en bout.