Le Cloud Public par le Code : Déployer une infrastructure Web scalable et hautement disponible sur AWS avec Terraform

Pourquoi « le cloud par le code » change vraiment la donne (et pourquoi AWS + Terraform)

Il y a un moment assez précis où on comprend. Quand on a monté une infra « au clic » dans la console AWS, que tout marche, qu’on est content. Et puis deux semaines plus tard, quelqu’un demande « on peut refaire la même en staging ? ». Ou pire : « on a besoin de recréer à l’identique dans une autre région ». Là, soudain, les screenshots, les souvenirs flous, les paramètres oubliés... ça devient une dette.

Le cloud par le code, c’est le passage de « je configure » à « je décris ». Une infrastructure reproductible, versionnée, auditable. On sait ce qui a changé, quand, et pourquoi. Et surtout, on peut refaire. Avancement.

L’intention de cet article est simple : déployer une infrastructure Web scalable et hautement disponible sur AWS avec Terraform. On reste concret. Pas un cours théorique sur l’IaC. Plutôt une architecture de référence, le squelette Terraform, et les bonnes pratiques qui évitent les pièges classiques.

Pourquoi AWS ? Parce que tout ce qu’on veut faire ici existe en services managés, solides, éprouvés. Multi zones de disponibilité, élasticité, intégrations (Route 53, ACM, CloudWatch, ALB...). L’écosystème est mature, et ça compte quand on vise « prod ».

Pourquoi Terraform ? Parce que c’est l’outil IaC le plus utilisé pour orchestrer de l’infra cloud, multi cloud, avec un workflow clair (plan/apply), un state, des modules, et une intégration CI/CD naturelle. Et en équipe, la collaboration est beaucoup plus saine qu’avec des scripts maison ou des clics.

À la fin, vous aurez :

• une architecture AWS de référence pour une app Web scalable et HA,
• une structure Terraform réaliste (sans usine à gaz),
• des points d’attention sécurité, observabilité, coûts,
• et un workflow pour que ça tienne dans la durée.

Avant de coder : le cahier des charges (simple) d’une infra Web scalable et hautement disponible

Avant d’écrire la moindre ressource Terraform, on fixe le vocabulaire. Sinon, on se retrouve à « scaler » un truc qui ne scale pas, ou à « faire du HA » avec un point de panne unique au milieu.

Scalable, ici, veut dire : capacité à monter et descendre en charge automatiquement. On évite les goulots évidents :

• compute : plusieurs instances, pas une seule,
• réseau : sous réseaux multi AZ, pas un subnet unique,
• entrée trafic : load balancer, pas une IP collée à une VM.

Hautement disponible, ici, veut dire : tolérance à la panne au niveau d’une zone de disponibilité (AZ). Donc multi AZ, health checks, et surtout éliminer les single points of failure.

Et puis il y a les objectifs non fonctionnels, ceux qui font la différence en prod :

• sécurité : instances en réseau privé, contrôle des flux, IAM minimal,
• observabilité : logs, métriques, alarmes, pas juste « ça répond »,
• coûts : right sizing, tags, et éviter de payer pour du vide,
• déploiements sûrs : mises à jour progressives, rollbacks possibles.

Hypothèses pour garder l’article à une complexité raisonnable :

• l’app côté compute est stateless (ou quasi), donc un ASG peut remplacer des instances sans drame,
• les assets statiques peuvent aller sur S3 (optionnel),
• la base de données n’est pas au centre du périmètre (on mentionnera RDS en compromis, mais on ne le déploie pas en détail).

Bref, une architecture de référence. Simple mais solide.

L’architecture AWS cible (vue d’ensemble)

Imaginez le schéma mental suivant, sans dessin, mais on va le rendre clair.

• Un VPC.
• Deux zones de disponibilité (minimum).
• Dans chaque AZ : un subnet public et un subnet privé.
• Dans les subnets publics : l’ALB et les NAT Gateways.
• Dans les subnets privés : les instances EC2 gérées par un Auto Scaling Group.
• Une Internet Gateway pour l’accès entrant et sortant côté public.
• Des route tables séparées public et privé, avec NAT pour la sortie depuis le privé.
• Route 53 pour le DNS, ACM pour les certificats, HTTPS sur l’ALB.
• CloudWatch pour métriques et logs, et les access logs de l’ALB envoyés vers S3.
• Sécurité avec Security Groups bien séparés, IAM minimal, chiffrement au repos et en transit.

Le point clé : rien d’essentiel n’existe dans une seule AZ. Si une AZ a un souci, l’ALB route vers l’autre, l’ASG relance ailleurs, et le site continue.

Pré requis et conventions Terraform (pour éviter les galères)

Côté machine :

• tfenv
• AWS CLI configurée (profil, ou SSO).
• Des credentials AWS qui ont les droits nécessaires (au minimum VPC, EC2, ELBv2, IAM, S3, Route 53, ACM, CloudWatch).

Choisissez la région tôt. La latence, le prix, et même la dispo de certains services changent selon la région. Les AZ sont propres à chaque compte AWS, mais Terraform peut les découvrir dynamiquement. On peut rester simple : deux AZ.

apply

Tags et naming : c’est du FinOps basique, mais indispensable. Dès le début, adoptez un set de tags commun :

• Environment
• Project
• Owner
• CostCenter

Structure de repo recommandée. Deux approches qui marchent :

• modules/ + environments/
• ou un root module clair avec des fichiers par domaine, et une gestion d’environnements via workspaces.

environments/

Étape 1 : poser le socle réseau : VPC, subnets multi AZ, routage, NAT

Le réseau, c’est le socle. Et c’est aussi l’endroit où on peut se tirer une balle dans le pied avec un CIDR mal choisi.

10.0.0.0/16enable_dns_supportenable_dns_hostnames

Ensuite, deux AZ. Dans chaque AZ :

• un subnet public (pour ALB, NAT),
• un subnet privé (pour EC2).

Routage :

• subnets publics : route vers Internet Gateway.
• subnets privés : route par défaut vers NAT Gateway (dans la même AZ idéalement).

Et surtout : pas d’IP publiques sur les instances EC2. Elles sortent via NAT, elles ne sont pas joignables depuis l’Internet. L’entrée se fait via l’ALB.

En Terraform, vous pouvez tout écrire à la main. Mais il faut être honnête : le module officiel VPC AWS de Terraform est très utilisé, bien maintenu, et vous évite des erreurs de plomberie.

• terraform-aws-modules/vpc/aws
• Option B : DIY, plus pédagogique, mais plus de code à maintenir.

vpc_idpublic_subnetsprivate_subnets

Étape 2 : sécuriser proprement : security groups, IAM minimal, principes de base

On veut une surface d’attaque minimale, et des flux explicites.

Security Groups, configuration typique :

• 80/4430.0.0.0/0::/0
• SG instances : entrée uniquement depuis le SG ALB (pas depuis Internet), sortie vers Internet autorisée (via NAT) si nécessaire pour updates, appels API, etc.

Séparer les SG est important. Si vous mettez tout dans un même SG, vous finissez par ouvrir trop large « temporairement », puis vous oubliez. Classique.

IAM minimal :

• si vos instances doivent écrire des logs dans CloudWatch, ou lire des paramètres SSM, utilisez un rôle IAM attaché à l’instance profile.
• AdministratorAccess
• partez du principe du moindre privilège, quitte à ajouter une permission plus tard.

Secrets et paramètres :

• utilisez SSM Parameter Store ou Secrets Manager.
• ne hardcodez pas des secrets dans Terraform.
• et même sans hardcoder, attention : tout ce qui est dans Terraform peut finir dans le state. Donc on évite d’y mettre des valeurs sensibles en clair. Terraform gère l’infra, pas vos secrets en clair.

Chiffrement :

• EBS chiffré (par défaut si possible),
• TLS via ALB et ACM,
• logs vers S3 avec bucket policy restrictive, et idéalement chiffrement SSE S3 ou SSE KMS selon votre niveau d’exigence.

Étape 3 : mettre l’entrée en haute dispo : ALB, listeners, health checks, logs

L’ALB est votre porte d’entrée. Il vit dans les subnets publics multi AZ.

On crée :

• un Application Load Balancer,
• un Target Group (HTTP, port de l’app, par exemple 8080),
• un listener HTTP 80 (souvent redirection vers HTTPS),
• un listener HTTPS 443 avec le certificat ACM.

/health

Stickiness :

• à éviter si votre app est stateless, parce que ça masque des problèmes et limite certains patterns de scaling,
• utile seulement si vous avez une vraie raison (sessions non externalisées, comportement legacy), et même là, c’est souvent un signal qu’il faut refactor.

Access logs ALB vers S3 : oui. Même si vous ne les regardez pas tous les jours. Le jour où vous devez comprendre un pic, une IP, une anomalie, c’est précieux.

Côté Terraform, les variables qui reviennent souvent :

• domain_name
• certificate_arn
• app_port
• health_check_path
• alb_logs_bucket

Étape 4 : rendre l’app scalable : launch template, auto scaling group, rolling updates

Le scaling côté compute se fait via un Auto Scaling Group, piloté par un Launch Template.

Launch Template :

• AMI (idéalement une AMI packagée, ou au minimum une AMI Amazon Linux),
• instance_type
• user_data
• SG instances,
• IAM instance profile.

ASG :

• dans les subnets privés multi AZ,
• min_sizedesired_capacitymax_size
• health checks basés sur l’ELB (ALB), pas juste EC2. Sinon vous gardez des instances « vivantes » mais inutilisables.
• attachement au Target Group.

Déploiements sans coupure :

• utilisez l’instance refresh (rolling update) de l’ASG.
• configurez un warmup. Sinon, l’ASG remplace trop vite et vous créez un trou de capacité.
• gardez une capacité minimale qui permet de supporter la charge pendant le renouvellement.

Logs applicatifs :

• au minimum, envoyez vos logs vers CloudWatch Logs (CloudWatch Agent).
• /var/log

Scaling policy :

• commencez simple : CPU moyenne, ou request count per target via ALB.
• ensuite, affinez avec des métriques métier si vous en avez (latence, queue depth, etc.). Mais ne bloquez pas le lancement du projet là dessus.

Étape 5 : DNS et certificat : Route 53 + ACM pour un site propre en prod

Pour un vrai service Web, on veut un domaine propre et du HTTPS.

Route 53 :

• example.com
• AAAAA
• app.example.com

ACM :

• app.example.com
• validation DNS (recommandée), gérée par Terraform : création des records de validation dans Route 53, puis ressource de validation ACM.

Points d’attention Terraform :

• dépendances : le listener HTTPS ne doit pas être créé avant que le cert soit validé, sinon vous avez des erreurs ou un cycle bancal.
• create_before_destroy

Environnements :

• dev.app.example.comstaging.app.example.comapp.example.com
• évitez de tester des changements dangereux directement sur le domaine prod. Ça paraît évident, mais bon.

Route 53 health checks : optionnel. Dans beaucoup de cas, l’ALB suffit. On ajoute des health checks Route 53 surtout si on fait du failover inter région ou multi ALB.

Organisation du code Terraform : variables, outputs, modules (sans sur architecturer)

Le piège, c’est de transformer un projet de 20 ressources en une cathédrale de modules. L’autre piège, c’est l’inverse : tout mettre dans un seul fichier, illisible, et impossible à revoir.

Un découpage qui marche bien :

• networksecurityalbcompute
• network.tfalb.tfcompute.tfsecurity.tfoutputs.tf

Variables typiques :

• environmentprojectregion
• vpc_cidr
• instance_type
• min_sizedesired_capacitymax_size
• domain_name
• health_check_path

localslocal.common_tagsEnvironmentProject

Gestion des environnements :

• workspaces : pratique, mais ça peut devenir opaque, et les erreurs de workspace arrivent vite.
• environments/environments/devenvironments/prod

En général, si vous êtes plusieurs et que vous voulez de la lisibilité en revue, les dossiers gagnent.

Lisibilité :

• commentaires courts, utiles,
• noms explicites,
• éviter la magie. Le but est simple : quelqu’un d’autre doit pouvoir maintenir l’infra sans vous appeler.

Automatiser et fiabiliser : workflow Terraform propre (plan/apply), CI/CD, revues

Le workflow standard, celui qui évite les mauvaises surprises :

1. terraform fmt
2. terraform validate
3. terraform plan
4. revue du plan en Pull Request
5. terraform apply

En CI :

• plan
• conservez l’artefact du plan si votre process le permet, et appliquez exactement ce qui a été planifié.
• en prod, imposez des approvals manuels.

Contrôles qualité :

• tflint
• checkovtfsec
• si vous êtes très cadrés : OPA ou Sentinel, mais ce n’est pas obligatoire pour démarrer.

Stratégie de branches :

• PR obligatoires,
• revue infra comme du code applicatif,
• apply

Drift :

• terraform plan
• et si vous trouvez du drift, traitez le problème à la source. Soit on arrête de cliquer, soit on accepte que Terraform ne soit pas la source de vérité. Mais pas les deux.

Coûts et compromis (les points qui piquent en prod)

Quelques trucs font mal quand la facture arrive.

NAT Gateways :

• recommandation HA : une NAT par AZ, et route privée vers la NAT de la même AZ.
• mais c’est cher. Et il y a aussi le coût de traitement de données. Alternatives : NAT instance (moins cher, mais maintenance, scaling, SPOF si mal fait). À évaluer selon contexte.

Choix EC2 :

• on demand pour la simplicité,
• spot pour réduire le coût, en mix si votre app tolère l’interruption,
• Graviton (ARM) si votre stack est compatible, souvent très bon ratio perf prix.

Auto Scaling :

• min
• min

RDS si vous l’ajoutez :

• Multi AZ augmente fortement la résilience,
• et augmente aussi la facture. Souvent nécessaire en prod, mais ça doit être assumé, pas ajouté « pour faire sérieux ».

Conseil très pragmatique : taguez tout. Activez AWS Cost Explorer et Budgets tôt. Le coût, ça se gère dès le début, pas quand il est déjà trop tard.

Ce que vous obtenez (résumé) et comment passer à l’étape suivante

Récap de ce qu’on a construit, en logique « infra de référence » :

• un réseau multi AZ (VPC, subnets publics et privés, routage, NAT),
• un ALB en frontal, multi AZ, avec health checks,
• un ASG en privé, scalable, avec rolling updates,
• HTTPS propre avec ACM, DNS Route 53,
• logs et métriques (CloudWatch, access logs ALB vers S3),
• sécurité de base (SG séparés, IAM minimal, chiffrement).

Et ensuite ? Quelques améliorations naturelles, quand vous êtes prêts :

• AWS WAF devant l’ALB,
• CloudFront (si beaucoup de contenu statique, ou besoin de caching global),
• blue green ou canary deploy plus avancé,
• base de données managée (RDS) et cache (ElastiCache),
• tests IaC (par exemple Terratest) et policy as code,
• séparation multi comptes AWS (dev, staging, prod) avec une gouvernance propre.

La recommandation la plus utile, celle qui paraît bête mais qui marche : faites un POC, puis testez une panne d’AZ. Vraiment. Regardez ce qui se passe. Ensuite seulement, industrialisez via CI.

Versionnez, automatisez, documentez. Et gardez l’infra simple mais solide. C’est ça, le vrai gain du cloud par le code.

Questions fréquemment posées

Qu'est-ce que le « cloud par le code » et pourquoi est-il important ?

Le « cloud par le code » signifie passer de la configuration manuelle à la description de l'infrastructure via du code. Cela permet d'avoir une infrastructure reproductible, versionnée et auditable, facilitant la recréation précise dans différents environnements ou régions, évitant ainsi les erreurs humaines et la dette technique.

Pourquoi choisir AWS pour déployer une infrastructure Web scalable et hautement disponible ?

AWS propose des services managés solides et éprouvés offrant multi zones de disponibilité, élasticité, intégrations natives comme Route 53, ACM, CloudWatch et ALB. Son écosystème mature garantit robustesse et fiabilité indispensables pour une architecture en production.

Quels sont les avantages de Terraform pour gérer l'infrastructure cloud ?

Terraform est l'outil IaC le plus utilisé qui permet d'orchestrer une infrastructure cloud multi-cloud avec un workflow clair (plan/apply), un état centralisé (state), des modules réutilisables et une intégration naturelle avec CI/CD. Il améliore la collaboration en équipe comparé aux scripts maison ou configurations manuelles.

Quels critères définissent une infrastructure Web scalable et hautement disponible selon cet article ?

Une infrastructure scalable peut monter et descendre automatiquement en charge sans goulots évidents (plusieurs instances compute, subnets multi AZ, load balancer). Une architecture hautement disponible tolère les pannes au niveau d'une zone de disponibilité grâce au multi AZ, health checks et élimination des points de panne uniques.

Quelles bonnes pratiques non fonctionnelles sont essentielles pour une infra cloud en production ?

La sécurité (instances en réseau privé, contrôle des flux, IAM minimal), l'observabilité (logs détaillés, métriques, alarmes), la maîtrise des coûts (right sizing, tagging) ainsi que des déploiements sûrs avec mises à jour progressives et possibilités de rollback sont indispensables pour garantir robustesse et pérennité.

Quelle architecture AWS cible est recommandée pour une app Web scalable et HA ?

Une architecture comprenant un VPC avec au moins deux zones de disponibilité, chaque AZ disposant d'un subnet public (ALB, NAT Gateway) et privé (instances EC2 dans Auto Scaling Group), Internet Gateway pour accès public, tables de routage distinctes avec NAT pour sortie privée. Utilisation de Route 53 pour DNS, ACM pour certificats HTTPS sur ALB, CloudWatch pour métriques/logs et sécurité renforcée via Security Groups séparés, IAM minimal et chiffrement en transit et au repos.