1. Contexte, Périmètre et Conception (Design-First)

J’ai abordé ce projet en partant du design : avant de provisionner quoi que ce soit ou d’écrire la moindre ligne de code IaC, j’ai entièrement modélisé l’architecture pour répondre aux contraintes de la société Nimbus Corp.

L’objectif : remplacer une infra On-Premise vieillissante, deux serveurs Dell PowerEdge qui représentaient un point de défaillance unique, par une architecture Cloud résiliente, élastique et sécurisée.

1.1. Objectifs Métier et Engagements de Service (SLA)

Le design a été dicté par ces impératifs de production :

• Haute Disponibilité : un taux de disponibilité minimal de 99,9 % sur la plage d’utilisation critique, de 7h à 20h en semaine, heure de Paris.
• Plan de Reprise d’Activité : une perte de données maximale admissible d’une heure, et un temps de rétablissement de deux heures maximum.
• Évolutivité : absorber la croissance interne, de 50 à 80 utilisateurs sous 3 ans, et les pics de requêtes transitoires, jusqu’à 1 200 requêtes par heure, soit 50 % de charge en plus.
• Maintien en Condition Opérationnelle : décharger l’équipe technique interne des tâches liées au matériel physique, matrice RAID, disques, climatisation.

1.2. Périmètre de la Migration (Scope)

En analysant l’existant, j’ai séparé ce qui profite de l’élasticité du Cloud de ce qui doit rester sur site pour des raisons de volume :

• Migré vers AWS : la couche applicative en Python 3.11, Gunicorn et Nginx, la base PostgreSQL 15 avec 145 Go de métadonnées et 18 Go de logs, le cache Redis 7.0 de 2 Go, et les données chaudes, fichiers statiques et traitements temporaires, environ 55 Go.
• Maintenu On-Premise : les 12 To de documents clients archivés sur le NAS physique local, et la périphérie réseau existante, pare-feu Fortigate 60F et commutation Cisco.

1.3. Contraintes Majeures de Conception (Design Constraints)

Ce sont ces quatre contraintes qui ont façonné la topologie finale du VPC et les choix de services :

1. Connectivité hybride et latence : l’application Cloud doit consulter et alimenter en continu les 12 To d’archives On-Premise, donc le calcul Cloud doit monter le NAS local. Ça impose un tunnel VPN IPsec Site-to-Site en IKEv2 et AES-256 entre le Virtual Private Gateway AWS et le Fortigate local, avec une latence strictement inférieure à 50 ms pour ne pas bloquer les process Django en attente d’I/O.
2. Sécurité by design et conformité RGPD : l’hébergement de données juridiques impose une localisation stricte en France, région AWS eu-west-3 Paris. Le design impose un cloisonnement réseau en 3 tiers, un chiffrement au repos avec des clés gérées par le client via AWS KMS pour RDS et EBS, et un chiffrement en transit en TLS 1.3. Les logs d’audit sont centralisés sur Amazon CloudWatch avec une rétention de 12 mois.
3. Contraintes FinOps : le budget mensuel On-Premise historique, environ 490 €, a cadré la migration. J’ai pensé l’infra FinOps dès le départ, avec notamment une extinction automatique de la couche de calcul la nuit et le week-end via l’Auto Scaling Group, pour environ 52 % d’économie sur le poste Compute.
4. Organisation et services managés : l’équipe technique de Nimbus Corp est réduite, un admin sys et un dev, et pas spécialisée Cloud, donc la conception privilégie largement les services managés. RDS et ElastiCache permettent de déléguer la gestion bas niveau, les sauvegardes et la configuration des clusters de bascule à AWS.

C’est sur cette base qu’a été conçue la cartographie réseau ci-dessous, validée avant de lancer le déploiement technique.

Ce qui change entre le labo et une vraie prod : J’ai validé cette infra dans un environnement restreint, AWS Academy, ce qui a imposé quelques contournements, une dette technique assumée pour ce PoC. En prod, voici comment je referais ces points :

• Gestion des secrets et immutabilité : ici, les identifiants RDS sont injectés en clair via le script d’amorçage UserData. En prod, je m’appuierais sur des Golden AMIs, des images pré-cuites ne contenant aucune donnée sensible. Au démarrage, l’instance EC2 utiliserait son rôle IAM pour s’authentifier auprès de Secrets Manager ou de Parameter Store, et récupérer ces valeurs chiffrées directement en mémoire, sans jamais les écrire sur le disque.
• Moindre privilège : je n’avais pas les droits pour créer des rôles IAM, donc je me suis reposé uniquement sur l’isolation réseau via les Security Groups. En temps normal, chaque EC2 aurait un rôle IAM dédié qui limite les appels API autorisés, pour contenir une éventuelle compromission.
• Observabilité : impossible de déployer l’agent CloudWatch faute de rôle IAM, donc les logs des démons systèmes, auth.log et syslog, sont restés en local sur les volumes EBS, sans possibilité d’alertes centralisées.
• Sécurité périmétrique : la couche 7 AWS WAF a été désactivée, ce service étant bloqué par la politique de l’organisation racine du labo.

2. Topologie Réseau et Isolation Stratégique (VPC)

Toute l’infra repose sur un VPC dédié, un réseau défini par logiciel. Le choix du bloc CIDR racine 10.0.0.0/16, soit 65 536 adresses IPv4, n’est pas arbitraire : il ne devait pas chevaucher le réseau local existant en 192.168.1.0/24, ce qui est nécessaire pour le routage bidirectionnel via IPsec.

La topologie est répartie sur deux zones de disponibilité, eu-west-3a et eu-west-3b, pour encaisser la perte totale d’un datacenter physique. Le subnetting suit un modèle à 3 tiers :

2.1. Cartographie des Flux et Routage Asymétrique

Le routage dans le VPC est pensé pour qu’aucune instance de calcul ne soit exposée directement.

• Tier 1, la DMZ publique : sous-réseaux 10.0.1.0/24 et 10.0.2.0/24. Rattachés à la table de routage principale, avec une route par défaut vers l’Internet Gateway. C’est là que sont les pare-feu applicatifs et les NAT Gateways.
• Tier 2, la zone privée applicative : sous-réseaux 10.0.10.0/24 et 10.0.11.0/24. Pas d’IP publique ici, c’est là que tourne la flotte d’instances EC2. Leur table de routage est asymétrique : le trafic sortant part vers l’interface de la NAT Gateway de leur zone de disponibilité.

La Resource Map ci-dessous confirme cette configuration de routage au sein de l’hyperviseur AWS, avec le flux asymétrique de la couche Compute vers l’extérieur.

2.2. Cloisonnement du Tier 3 (Zero Trust)

Le Tier 3, la zone privée données, avec les sous-réseaux 10.0.20.0/24 et 10.0.21.0/24, héberge l’instance Amazon RDS PostgreSQL et le cluster ElastiCache Redis. Pour rester dans une logique Zero Trust, ce réseau est isolé au niveau de la couche 3.

Sa table de routage ne contient qu’une seule entrée, la route locale du VPC. Pas de route par défaut vers Internet : même en cas de compromission, aucune exfiltration de données ne peut partir de la base vers Internet, puisque les paquets seraient de toute façon abandonnés par le routeur virtuel du VPC.

3. Connectivité Hybride : Tunnel VPN IPsec Site-à-Site

Pour relier le Cloud et le On-Premise, j’ai mis en place un lien persistant entre le réseau local en 192.168.1.0/24 et le VPC AWS en 10.0.0.0/16. Ça permet aux serveurs EC2 applicatifs de monter le stockage distant de façon transparente via NFSv4.

3.1. Infrastructure AWS (VGW et Routage)

Côté Cloud, l’interconnexion passe par une Virtual Private Gateway rattachée au VPC, le concentrateur VPN managé par AWS. La destination locale est déclarée via une Customer Gateway qui pointe vers l’IP publique du routeur sur site.

Pour que le trafic des instances EC2 du Tier 2 arrive jusqu’au NAS local, j’ai injecté dans la table de routage RT-Private-App une route, statique ou dynamique via propagation BGP si le routeur distant le supporte, ciblant le CIDR 192.168.1.0/24 vers l’identifiant de la VGW.

3.2. Établissement Cryptographique Local (strongSwan)

Côté On-Premise, un serveur Ubuntu en 192.168.1.130, configuré avec IP Forwarding, fait office de pare-feu et de concentrateur VPN via le démon strongSwan.

La négociation cryptographique se fait en deux temps :

• Phase 1, l’IKE SA : négociation initiale sur UDP/500 en IKEv2, avec chiffrement AES-256, hachage SHA-256, et échange de clés Diffie-Hellman en groupe 14.
• Phase 2, l’IPsec SA : établissement du tunnel de données via ESP sur UDP/4500 pour le NAT Traversal, qui scelle la communication de bout en bout entre les blocs IP locaux et distants.

Vérification de l’état des tunnels IPsec et de la négociation IKE via le démon charon

sudo ipsec statusall

3.3. Anecdote : le mystère des paquets NFS perdus dans le tunnel

Ça n’a pas été aussi simple que ça en a l’air. Le tunnel Site-to-Site affichait bien le statut UP, et les pings passaient sans problème entre les EC2 AWS et le NAS local. Sauf que dès que les EC2 essayaient de monter le partage NFS ou de transférer un gros fichier, la connexion restait bloquée indéfiniment, de manière aléatoire.

En lançant un tcpdump sur le pare-feu local, j’ai repéré de la fragmentation. L’encapsulation IPsec ajoute un en-tête supplémentaire aux paquets, et les gros paquets NFS finissaient par dépasser le MTU standard de 1500 octets. Ils étaient alors rejetés en silence, parce que certains routeurs sur le trajet bloquaient l’ICMP qui aurait dû signaler le problème.

La solution : forcer, via une règle iptables sur le routeur On-Premise, un TCP MSS Clamping strict, pour que la taille des segments TCP soit négociée à la baisse dès le départ. Depuis, le flux NFS passe sans accroc à travers le VPN.

4. Matrice de Sécurité (Stateful Firewalling)

La politique de sécurité applique le principe du moindre privilège, au niveau des interfaces réseau élastiques, via des Security Groups. Contrairement aux ACL, qui opèrent au niveau du sous-réseau sans état, les Security Groups AWS sont des pare-feu à état de couche 4 : ils gardent la trace des connexions établies et autorisent dynamiquement le trafic de retour, sans règle explicite à ajouter.

L’idée de cette matrice, c’est de ne pas avoir à gérer des IP statiques pour la communication inter-services, en s’appuyant sur le chaînage de Security Groups.

4.1. Maillage Ingress (Load Balancer vers Applicatif)

L’Application Load Balancer, dans la DMZ, est le seul point d’entrée exposé sur Internet, en TCP/443.

Les instances applicatives EC2 du Tier 2, elles, ne doivent jamais être accessibles seules. La règle entrante du SG-APP ignore donc tout bloc CIDR : elle n’autorise le trafic sur le port TCP/8000 que s’il vient d’une interface réseau portant l’identifiant du Security Group de l’ALB. Toute autre tentative de connexion est droppée au niveau de l’hyperviseur, avant même d’atteindre le système d’exploitation de l’instance.

4.2. Verrouillage Egress (Base de Données)

Le Security Group de la base de données illustre bien l’esprit Zero Trust. En entrée, il n’autorise le trafic TCP/5432 qu’en provenance du SG-APP.

En sortie, j’ai supprimé purement et simplement la règle par défaut qui autorise tout le trafic sortant. La seule règle qui reste cible la boucle locale, pour les process internes du moteur. Résultat : l’instance RDS PostgreSQL ne peut techniquement lancer aucun flux réseau vers l’extérieur. Si une vulnérabilité applicative permettait une exécution de code via des requêtes SQL malformées, l’attaquant ne pourrait ni télécharger un payload supplémentaire, ni établir un reverse shell.

5. Résilience, Auto Scaling et Stratégie FinOps

Pour tenir le SLA de 99,9 % sans sur-dimensionner inutilement, la couche de calcul s’appuie sur du scaling horizontal couplé à une gestion automatique de l’élasticité.

5.1. Équilibrage de Charge (Couche 7)

Le routage du trafic utilisateur passe par l’ALB, qui fait la terminaison TLS et déchiffre les requêtes. Le trafic est ensuite inspecté au niveau applicatif avant d’être distribué vers le Target Group.

La résilience s’appuie sur des health checks assez agressifs. L’ALB interroge toutes les 30 secondes un endpoint dédié sur chaque instance EC2. Seules les instances qui répondent en 200 de façon consécutive restent dans le pool de distribution. En cas de défaillance matérielle ou de crash du daemon Gunicorn, l’instance est drainée puis sortie du routage, et la panne reste transparente pour l’utilisateur final.

5.2. Élasticité Dynamique et Standard d’Immutabilité

La flotte de calcul est gérée par un Auto Scaling Group sur les deux zones de disponibilité. La capacité s’ajuste en temps réel via une politique de Target Tracking Scaling : au-delà de 70 % d’utilisation CPU moyenne, l’ASG déclenche le provisionnement de nouvelles ressources.

Choix d’implémentation, PoC vs prod : Pour ce labo, l’amorçage des instances passe par un script UserData qui met à jour l’OS, installe les dépendances Python et NFS, et configure le routage à la volée. Ça induit environ 5 minutes de latence au démarrage d’une nouvelle instance.

En prod, je m’appuierais plutôt sur des Golden AMIs, des images pré-cuites générées via un pipeline CI avec un outil comme HashiCorp Packer. Ces images évitent de télécharger et compiler des paquets au démarrage, et font tomber le temps d’instanciation de 5 minutes à environ 45 secondes.

5.3. Ingénierie FinOps et Maîtrise de la Facturation Réseau

J’ai pensé l’architecture avec les contraintes de facturation Cloud dès la phase de design, pour éviter que les coûts de transfert de données et le sur-dimensionnement n’explosent.

• Facturation du VPN IPsec : sur AWS, le trafic entrant vers le VPC est gratuit. Donc quand les utilisateurs envoient des documents vers l’appli, ou que le NAS On-Premise envoie des données vers les EC2, la bande passante n’est pas facturée. En revanche, le trafic sortant vers Internet ou vers le site local via le VPN est payant au-delà du quota gratuit. Le tunnel Site-to-Site a un coût fixe horaire d’environ 0,05 $, plus une facturation de la sortie au Go. J’ai donc mis en cache les requêtes fréquentes via Redis, pour limiter les allers-retours inutiles vers le NAS distant.
• Arbitrage compute : j’ai choisi des instances t3.medium, qui fonctionnent avec des crédits processeur. Plutôt que de prendre des m5 ou des c5, qui délivrent 100 % du CPU en continu et coûtent plus cher, les t3 accumulent des crédits en heures creuses pour absorber les pics de charge. Le mode Unlimited sert de filet de sécurité : si les crédits sont épuisés, AWS facture la micro-seconde de sur-utilisation CPU, ce qui reste beaucoup moins cher qu’un sur-dimensionnement permanent.
• Extinction automatique : couper la flotte applicative entre 20h15 et 6h45 via l’Auto Scaling Group fait économiser plus de 50 % sur le poste budgétaire du Compute EC2.

5.4. Externalisation des Sessions (Amazon ElastiCache Redis)

Pour que l’Auto Scaling Group puisse détruire et recréer des instances sans déconnecter les utilisateurs, la flotte EC2 doit rester sans état. Les sessions sont donc externalisées de la base de données vers un cluster Amazon ElastiCache en Redis 7.

Côté réseau et sécurité :

• Subnetting : le cluster utilise un Subnet Group qui couvre les sous-réseaux isolés du Tier 3, en 10.0.20.0/24 et 10.0.21.0/24. Le nœud primaire est placé dans la zone eu-west-3a, pour rester à latence infra-milliseconde des instances EC2 de la même zone.
• Filtrage : verrouillage strict au niveau de l’interface réseau. La règle entrante n’autorise le trafic sur le port TCP/6379 qu’en provenance du groupe de sécurité applicatif.
• Routage : rattaché à la table RT-Private-Data, le cluster Redis n’a aucune route par défaut. Les données volatiles restent confinées à l’intérieur du VPC.

6. Validation Applicative et Infrastructure as Code

Cette phase consiste à vérifier que tout fonctionne de bout en bout, du point d’entrée public jusqu’au montage du volume réseau via IPsec.

6.1. Exécution Métier et Montage Réseau

La validation se fait au niveau applicatif. L’interface web, exposée via l’ALB en HTTPS, affiche les variables d’état du système et confirme les interconnexions sous-jacentes.

Le tableau de bord ci-dessous montre :

1. L’authentification intra-VPC : la connexion TCP réussit vers le cluster PostgreSQL managé en version 15.18, ce qui prouve que le chaînage des Security Groups et le routage inter-sous-réseaux fonctionnent.
2. L’accès hybride, NFS sur IPsec : le système de l’instance EC2 reconnaît un volume monté dynamiquement, de 98 Go. Ce montage, géré par les options de résilience réseau dans /etc/fstab, confirme que les paquets NFSv4 sont bien encapsulés, envoyés à la Virtual Private Gateway, chiffrés, routés à travers Internet, puis déchiffrés par strongSwan côté site local.

6.2. Automatisation et Extraits d’Infrastructure as Code (IaC)

J’ai d’abord maquetté et validé l’architecture étape par étape via la console AWS, pour m’assurer du bon comportement de chaque composant réseau. Une fois stabilisée, j’ai traduit tout le déploiement en Infrastructure as Code, CloudFormation et scripts locaux, pour pouvoir le reproduire.

Voici les extraits qui illustrent les concepts réseau et système les plus importants du projet :

1. Le routage asymétrique, en CloudFormation Cet extrait montre la table de routage du Tier 2. Le trafic sortant des instances EC2 est forcé vers l’interface de la NAT Gateway, ce qui confirme que le sous-réseau reste inaccessible depuis l’extérieur.

  RouteTablePrivateAppAZa:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref CirrusVPC
      Tags:
        - Key: Name
          Value: RT-Private-App-AZa

  RoutePrivateAppToInternet:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref RouteTablePrivateAppAZa
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref NatGatewayAZa

7. Gouvernance et Plan de Reprise d’Activité (PRA)

La haute dispo ne suffit pas à elle seule : il faut aussi une vraie politique de sauvegarde. Pour répondre aux exigences de conformité, j’ai codé et déployé un Plan de Reprise d’Activité via le service centralisé AWS Backup.

7.1. Stratégie de Ciblage Dynamique (Tag-Based Backup)

Plutôt que de cibler des identifiants en statique, trop rigide pour un environnement élastique, le plan de sauvegarde repose sur une sélection dynamique par tags. AWS Backup scrute le VPC et capture l’état de toute ressource portant la paire clé-valeur Backup: Daily-PRA.

• Couche de données : le tag est appliqué directement sur l’instance RDS. AWS Backup génère un snapshot du volume de stockage chaque jour.
• Couche de calcul : les instances EC2 étant éphémères et pilotées par l’ASG, impossible de les tagger à la main. Le tag est appliqué au niveau du groupe d’Auto Scaling avec l’attribut PropagateAtLaunch à true. Chaque nouvelle instance hérite du tag, et ses volumes EBS locaux, qui contiennent les logs systèmes non centralisés, sont automatiquement inclus dans la sauvegarde nocturne.

7.2. Cycle de Vie et Automatisation (IaC)

Le déploiement de cette politique, phase 6 du projet, est géré en entier par CloudFormation :

• Coffre-fort : création d’un Cirrus-Production-Vault, chiffré avec KMS pour sceller les instantanés.
• Fenêtre d’exécution : le plan se déclenche à 2h du matin UTC, quand l’ASG a réduit la flotte à son minimum, pour limiter l’impact sur les IOPS du système.
• Rétention : les instantanés sont gardés 35 jours avant purge automatique, pour tenir les normes d’auditabilité de l’entreprise.

8. Perspectives d’Évolution et d’Ingénierie de Bas Niveau

L’architecture actuelle répond aux besoins de haute dispo et d’isolation Zero Trust, mais passer à l’échelle pour une infra critique demanderait quelques optimisations de bas niveau en plus :

8.1. Observabilité Centralisée et Alerting

Dès que les restrictions IAM seraient levées, déployer l’agent CloudWatch ou un démon comme Fluent-bit sur la flotte EC2 deviendrait le standard. L’idée serait de convertir les logs locaux, syslog, gunicorn, erreurs d’authentification, en JSON structuré, de les pousser vers un puits de logs centralisé, et de coupler ça à Amazon SNS pour des alertes en temps réel, par exemple si le taux d’erreurs HTTP 500 dépasse 5 % sur une minute glissante.

8.2. Fiabilisation du Routage Hybride (BGP)

Le tunnel IPsec repose aujourd’hui sur du routage statique, avec 192.168.1.0/24 routé vers la VGW. Pour une résilience plus poussée, installer un démon de routage comme FRRouting sur le pare-feu local permettrait d’établir une session BGP à travers le tunnel. L’échange de signaux de vie dynamiques garantirait un basculement automatique vers le second tunnel IPsec en cas de défaillance du lien principal.

8.3. Optimisation Egress via VPC Endpoints (AWS PrivateLink)

Aujourd’hui, tout le trafic sortant des instances du Tier 2, téléchargement de dépendances système, appels vers des services AWS externes, passe par les NAT Gateways de la DMZ, ce qui a un coût pour chaque Go qui transite.

Si l’application Cirrus devait interagir davantage avec des services AWS natifs, archivage froid vers Amazon S3, appels à l’API Systems Manager, déployer des VPC Gateway Endpoints deviendrait pertinent. Ça permettrait d’injecter une route locale directement dans la table de routage RT-Private-App : les paquets à destination d’Amazon S3 transiteraient uniquement via le réseau interne d’AWS, gratuitement, sans passer par la NAT Gateway, et sans jamais traverser d’IP publique, ce qui va aussi dans le sens du Zero Trust.

9. Chiffrage Budgétaire et Analyse FinOps

L’architecture s’appuie sur une extinction planifiée de la couche Compute la nuit et le week-end, 65h de fonctionnement sur 168h, soit 38,7 % du temps. Voici une simulation des coûts, basée sur la tarification officielle AWS :