Il y a une phase dans la vie de chaque startup appelée « ClickOps ». Vous vous connectez à la console AWS. Vous recherchez EC2. Vous cliquez sur “Lancer l’instance”. Vous l’appelez « legacy-server-do-not-touch ». Ça marche. Cela semble productif. Deux ans plus tard, ce serveur plante. L’ingénieur qui l’a construit est parti. Personne ne sait quelle version du système d’exploitation il utilisait. Personne ne sait quels groupes de sécurité étaient ouverts. Personne ne sait où se trouvent les clés SSH. L’entreprise est hors ligne.

Chez Maison Code Paris, nous appliquons une règle stricte : L’Infrastructure est le Code. S’il n’est pas dans Terraform (ou Pulumi/CDK), il n’existe pas. Ce guide est une plongée approfondie dans la création d’une infrastructure AWS de niveau production qui soit résiliente, sécurisée et ne vous met pas en faillite.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Pourquoi Maison Code parle d’infrastructure

Nous gérons l’infrastructure de marques qui ne peuvent pas échouer. Lorsqu’un client lance une collaboration avec une superstar mondiale, le trafic est multiplié par 100 en 60 secondes. Si l’équilibreur de charge n’est pas réchauffé, si la base de données n’est pas évolutive, le site plante. Nous concevons pour l’élasticité. Nous utilisons AWS non pas comme « serveur hôte » mais comme « utilitaire programmable ». Nous aidons les CTO à migrer de « serveurs d’animaux de compagnie » fragiles vers des « flottes de bétail » résilientes.

1. La philosophie de base : Infrastructure as Code (IaC)

Pourquoi écrivons-nous l’infrastructure en HCL (HashiCorp Configuration Language) ?

Reproductibilité : vous pouvez créer un environnement « Staging » qui est un clone exact de « Production » en 10 minutes.
Auditabilité : git blâme vous indique exactement qui a ouvert le port 22 au public et quand.
Reprise après sinistre : si us-east-1 tombe en panne, vous modifiez une variable region = "eu-west-1" et redéployez.

La pile Terraform

Nous ne gérons pas l’État localement. Nous utilisons un backend distant (S3 + DynamoDB pour le verrouillage).

#main.tf
terraformer {
  back-end "s3" {
    bucket = "maisoncode-terraform-state"
    clé = "prod/infrastructure.tfstate"
    région = "us-east-1"
    dynamodb_table = "terraform-locks"
    chiffrer = vrai
  }
}

fournisseur "aws" {
  région = "us-east-1"
  balises_par défaut {
    balises = {
      Environnement = "Production"
      Projet = "E-Commerce"
      GéréBy = "Terraform"
    }
  }
}

2. Mise en réseau : le piège VPC

La plus grosse erreur commise par les développeurs est d’utiliser le “VPC par défaut”. Le VPC par défaut place tout dans les sous-réseaux publics. Votre base de données a une IP publique. C’est imprudent. Nous architectons des réseaux à 3 niveaux.

graph TD
    Utilisateur -->|HTTPS| ALB [Équilibreur de charge d'application]
    sous-graphe VPC
        sous-graphe Sous-réseau public
            ALB
            NAT[Passerelle NAT]
        fin
        sous-graphe Sous-réseau privé
            Application[Serveur d'applications / Lambda]
        fin
        sous-réseau de base de données subgraph
            RDS[RDS Postgres]
        fin
    fin
    Application -->|SQL| RDS
    Application -->|Sortant| NAT

Niveau 1 : sous-réseau public

Contient : équilibreurs de charge (ALB), passerelles NAT, hôtes Bastion.
Routage : possède une passerelle Internet (IGW). 0.0.0.0/0 -> IGW.

Niveau 2 : sous-réseau privé (couche d’application)

Contient : instances EC2, conteneurs Fargate, ENI Lambda.
Routage : Pas de passerelle Internet. 0.0.0.0/0 -> Passerelle NAT (pour les mises à jour sortantes).
Sécurité : Impossible d’accéder directement à partir d’Internet.

Niveau 3 : sous-réseau interne (couche de données)

Contient : RDS, ElastiCache, Redshift.
Routage : pas d’accès Internet du tout. Pas de NAT.
Sécurité : Isolement total.

3. La surprise de la passerelle NAT à 20 000 €

La tarification de la bande passante AWS est prédatrice. Une passerelle NAT vous facture par heure + par Go traité. Si votre application télécharge 10 To d’images à partir de S3 et que le trafic S3 standard passe par la passerelle NAT, vous payez environ 450 €. Correction : points de terminaison de la passerelle S3. Il s’agit d’un « trou de ver » virtuel entre votre VPC et S3 qui contourne le NAT. C’est Gratuit.

ressource "aws_vpc_endpoint" "s3" {
  vpc_id = aws_vpc.main.id
  service_name = "com.amazonaws.us-east-1.s3"
}

Provisionnez toujours les points de terminaison de passerelle pour S3 et DynamoDB.

4. Calcul : EC2 contre Fargate contre Lambda

Quel moteur de calcul convient au e-commerce de luxe ?

EC2 (Machines Virtuelles)

Cas d’utilisation : applications héritées, services avec état (WebSockets), bases de données (si auto-hébergées).
Verdict du code de la maison : à éviter. Trop de maintenance (correctifs du système d’exploitation).

ECS Fargate (conteneurs sans serveur)

Cas d’utilisation : applications Node.js/Docker de longue durée.
Avantages : Aucun correctif du système d’exploitation. Vous définissez « CPU : 2, RAM : 4 Go ». AWS l’exécute.
Verdict du code maison : Choix standard pour les serveurs Next.js envoyant du HTML.

Lambda (Fonctions)

Cas d’utilisation : tâches événementielles (redimensionnement d’image, traitement de commande).
Avantages : mise à l’échelle jusqu’à zéro.
Verdict du Code Maison : Exceptionnel pour le “Glue Code” et les travailleurs d’arrière-plan.

5. La base de données : RDS Aurora Serverless v2

Le RDS traditionnel vous oblige à choisir une taille d’instance (db.m5.large). Si le trafic augmente, vous tombez en panne. Si le trafic baisse, vous payez trop cher. Aurora Serverless v2 augmente et diminue localement la capacité de calcul en millisecondes. Il s’accorde parfaitement avec le modèle “Vente Flash” de gouttes de luxe.

ressource "aws_rds_cluster" "par défaut" {
  cluster_identifier = "aurora-cluster-demo"
  moteur = "aurora-postgresql"
  engine_mode = "provisionné"
  serverlessv2_scaling_configuration {
    min_capacity = 0,5 # 40 $/mois
    max_capacity = 64,0 # Charge lourde
  }
}

Lorsque la baisse se termine, elle revient à 0,5 ACU (Aurora Capacité Units). Vous payez ce que vous utilisez.

6. Diffusion de contenu : CloudFront

Vous ne pouvez pas servir les actifs de S3 directement aux utilisateurs. S3 est lent (délai jusqu’au premier octet). CloudFront est obligatoire. Il s’agit d’un CDN mondial. Configuration critique : Politiques de cache. Ne vous contentez pas de tout mettre en cache.

Images : Cache pendant 1 an.
Réponses API : mise en cache pendant 0 seconde (ou 60 secondes si publique).
HTML : Cache pendant 0 seconde (rendu côté serveur).

Sécurité : utilisez OAC (Origin Access Control) pour verrouiller votre compartiment S3 afin que seul CloudFront puisse le lire. Les utilisateurs ne peuvent pas contourner le CDN.

7. Le cadre bien architecturé (6 piliers)

AWS fournit une liste de contrôle appelée « Well-Architected Framework ». Nous auditons chaque client par rapport à cela.

Excellence opérationnelle : automatisez tout. Aucune modification manuelle.
Sécurité : chiffrez tout. Moindre privilège.
Fiabilité : déploiements multi-AZ. Systèmes d’auto-guérison.
Efficacité des performances : utilisez Serverless/Spot pour faire évoluer le contenu.
Optimisation des coûts : analysez quotidiennement les factures. Marquez chaque ressource.
Durabilité : utilisez des processeurs Graviton (ARM). Ils consomment 60 % d’énergie en moins.

8. Reprise après sinistre : RTO vs RPO

Si AWS « us-east-1 » brûle, que se passe-t-il ? Vous définissez 2 métriques :

RTO (Recovery Time Objective) : combien de temps faut-il pour se remettre en ligne ? (Objectif : < 1 heure).
RPO (Recovery Point Objective) : Quelle quantité de données pouvons-nous perdre ? (Objectif : < 5 minutes). Stratégie :
Base de données : réplicas en lecture interrégionaux (États-Unis -> UE). La promotion dure 5 minutes.
Fichiers : réplication inter-régions S3 (CRR).
Code : application Terraform multi-régions.

9. Sécurité : le principe du moindre privilège

IAM (Identity Access Management) est le pare-feu pour les humains. N’utilisez jamais le compte racine. Enfermez-le dans un coffre-fort. Ne jamais donner AdministratorAccess à un développeur.

Créez des politiques détaillées strictement limitées aux ressources.

{
    "Effet": "Autoriser",
    "Action": ["s3:PutObject"],
    "Ressource": "arn:aws:s3:::maisoncode-uploads/images/*"
}

Cet utilisateur peut télécharger des images. Ils ne peuvent pas supprimer le compartiment. Ils ne peuvent pas lire les rapports financiers.

8. Optimisation des coûts : instances ponctuelles

Pour le traitement des données par lots (par exemple, les tâches d’optimisation d’image exécutées la nuit), n’utilisez pas d’instances à la demande. Utilisez Instances Spot. Il s’agit de capacités AWS de rechange vendues avec une remise de 70 à 90 %. Le problème : AWS peut y mettre fin avec un avertissement de 2 minutes. Si votre application est apatride (comme un gestionnaire de file d’attente), cela n’a pas d’importance. Il gère la résiliation et redémarre ailleurs. Cela permet d’économiser des milliers de dollars par mois sur les tâches en arrière-plan.

9. Workflow de développement : environnements éphémères

Comment tester les changements d’infrastructure ? Nous utilisons des « Éphémères ». Lorsqu’un PR est ouvert dans GitHub :

Les actions GitHub déclenchent Terraform.
Il crée un nouvel espace de travail « pr-123 ».
Il déploie une pile complète (VPC + Fargate + RDS).
Il exécute des tests E2E.
Il exécute terraform destroy.

Cela garantit que les modifications du code n’interrompront pas la production.

10. Conclusion

AWS est une tronçonneuse. Il est assez puissant pour abattre une forêt, mais suffisamment dangereux pour vous couper la jambe. Cliquer dans la console, c’est jouer avec des jouets. Écrire Terraform, c’est de l’ingénierie. Pour 2026, nous nous dirigeons vers « Infrastructure from Code » (en utilisant SST ou Pulumi pour déduire l’infra à partir du code), mais les fondamentaux des VPC et de l’IAM restent immuables.

Votre cloud est en désordre ?

Avez-vous des « Serveurs inconnus » en cours d’exécution ? Votre facture est un mystère ? Engagez nos Architectes.