Migration Cloud AWS : Architecture Sécurisée et Hybride (Projet Cirrus)

Ce document présente l’architecture détaillée conçue pour la migration de l’application Cirrus (Nimbus Corp) vers le Cloud AWS. L’objectif de ce projet est de fournir une infrastructure cible hautement disponible, tout en s’intégrant dans une topologie réseau hybride stricte et en appliquant une supervision technique rigoureuse des coûts et des performances.

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

L’architecture réseau a été pensée pour répondre aux exigences de souveraineté et de routage avancé.

Architecture de production déployée.

1.1. Plan d’adressage et Région

• L’infrastructure est déployée exclusivement dans la région AWS Europe (Paris), soit eu-west-3. Cela permet de garantir une latence cible inférieure à 50 ms pour les utilisateurs en France, tout en assurant la conformité RGPD B2B et l’exclusion du Cloud Act américain.
• Le Virtual Private Cloud (VPC) s’appuie sur le bloc CIDR alloué 10.0.0.0/16, ce qui permet de fournir 65 536 adresses IPv4.
• Ce choix de réseau est un prérequis absolu d’ingénierie : les locaux On-Premise de Nimbus Corp utilisent le sous-réseau 192.168.10.0/24. Le réseau 10.0.0.0/16 évite tout chevauchement (IP overlapping), rendant le routage bidirectionnel possible via le tunnel VPN.

(📸 Insérer ici une capture d’écran de la console VPC montrant la table de routage principale et le CIDR)

1.2. Segmentation en Sous-réseaux (Subnetting Multi-AZ)

Pour respecter le SLA contractuel de 99,9 % limitant le downtime à 44h/an, l’infrastructure est répartie symétriquement sur deux Zones de Disponibilité (eu-west-3a et eu-west-3b). Le VPC applique un modèle de sécurité strict en 3-Tier :

• Tier 1 : Zone Publique (DMZ)
  • Subnets : 10.0.1.0/24 (AZ-a) et 10.0.2.0/24 (AZ-b).
  • Rôle et Routage : Hébergement de l’Application Load Balancer (ALB) et des NAT Gateways. Ce sont les uniques sous-réseaux disposant d’une table de routage pointant vers l’Internet Gateway (IGW), autorisant le trafic entrant et sortant direct avec Internet.
• Tier 2 : Zone Privée Applicative (Compute)
  • Subnets : 10.0.10.0/24 (AZ-a) et 10.0.11.0/24 (AZ-b).
  • Rôle et Routage : Hébergement des instances EC2 (Ubuntu 22.04 LTS) pour le code Python/Django. Aucune adresse IP publique n’est allouée, rendant les instances inaccessibles de l’extérieur. Le trafic sortant (mises à jour OS, paquets pip) est routé exclusivement vers la NAT Gateway de la DMZ.
• Tier 3 : Zone Privée Données (Database & Cache)
  • Subnets : 10.0.20.0/24 (AZ-a) et 10.0.21.0/24 (AZ-b).
  • Rôle et Routage : Hébergement du moteur Amazon RDS (PostgreSQL 15.x) et du cluster ElastiCache (Redis 7.x). L’isolation est absolue : la table de routage ne possède aucune route vers une NAT Gateway ou une Internet Gateway. Le trafic ne peut ni entrer ni sortir vers Internet.

2. Connectivité Hybride et Filtrage Ingress

2.1. Ingress Web (ALB et AWS WAF)

• La terminaison SSL/TLS est centralisée sur l’Application Load Balancer (ALB) via un certificat d’AWS Certificate Manager (ACM).
• Le chiffrement en transit est forcé par une politique de sécurité ALB imposant le protocole TLS 1.3 (ELBSecurityPolicy-TLS13-1-2-2021-06), rejetant les chiffrements obsolètes.
• Un pare-feu applicatif AWS WAF est attaché à l’ALB pour filtrer le trafic (règles gérées OWASP Top 10, protection SQLi, XSS) avant d’atteindre les instances privées.

2.2. Interconnexion Hybride (VPN IPsec Site-to-Site)

Pour que les serveurs Django montent le NAS On-Premise (12 To d’archives), un tunnel VPN sécurisé a été déployé.

• Protocole et Chiffrement : Utilisation d’IPsec (IKEv2) avec un chiffrement AES-256 entre la Virtual Private Gateway (VGW) du VPC et le Fortigate 60F On-Premise.
• Routage BGP : Le protocole BGP est utilisé pour la propagation dynamique des routes, assurant la tolérance aux pannes du tunnel.
• Tables de routage : La Zone Privée Applicative intègre une route spécifique pointant la destination 192.168.10.0/24 (LAN Nimbus) vers l’interface de la VGW.

(📸 Insérer ici une capture d’écran de la configuration du tunnel VPN IPsec ou des tables de routage BGP)

3. Matrice de Filtrage Dynamique (Security Groups)

L’application stricte du principe de moindre privilège est gérée au niveau des interfaces réseau (ENI) via des Security Groups (SG) stateful.

• SG-ALB (Load Balancer) :
  • Entrant : Autorise TCP 443 (HTTPS) depuis 0.0.0.0/0 (Internet mondial).
  • Sortant : Autorise TCP 8000 uniquement vers SG-APP.
• SG-APP (Serveurs EC2 Django) :
  • Entrant : Autorise TCP 8000 (port Gunicorn) exclusivement depuis la source SG-ALB. Toute tentative de connexion directe est rejetée au niveau matériel.
  • Sortant :
    • TCP 5432 (PostgreSQL) vers SG-DB.
    • TCP 6379 (Redis) vers SG-CACHE.
    • TCP 443 (HTTPS) vers 0.0.0.0/0 (via NAT).
    • TCP 2049 (NFS) ou TCP 445 (SMB) vers le CIDR On-Premise 192.168.10.0/24.
• SG-DB (Base de données RDS) :
  • Entrant : Autorise TCP 5432 exclusivement depuis la source SG-APP. L’accès externe au VPC est interdit.
  • Sortant : Refus total (Deny All), la base de données n’initie aucun flux.

4. Couche de Calcul (Compute) et Stratégie FinOps

4.1. Dimensionnement Système (EC2)

Pour éviter un surdimensionnement coûteux tout en remplaçant l’ancien serveur On-Premise (4 cœurs / 8 threads, 16 Go de RAM), la charge est distribuée horizontalement.

• Ressource : Instances t3.medium (2 vCPUs, 4 GiB RAM, x86_64, réseau jusqu’à 5 Gbps).
• OS : Ubuntu Server 22.04 LTS (ami-03b7b5f1a4e474c6d en eu-west-3), compatible avec Python 3.11.
• CPU Credits : Configuré en mode Standard (non Unlimited) pour accumuler des crédits hors charge et absorber les pics de 50 Mbps aux heures de bureau sans surcoût.

4.2. Auto Scaling Group (ASG)

Le Cirrus-ASG garantit le SLA sur la plage critique (07h00 - 20h00, Lundi-Vendredi) et s’étend sur les sous-réseaux 10.0.10.0/24 et 10.0.11.0/24.

• Capacité : Min = 0, Max = 4 instances.
• Actions Planifiées (Scheduled Actions) :
  • Réveil (06h45 UTC) : Cron 45 6 * * 1-5 forçant la capacité désirée et minimale à 2 instances.
  • Sommeil (20h15 UTC) : Cron 15 20 * * 1-5 abaissant la capacité à 0 (ou 1 en best-effort), générant une économie brute d’environ 52 % sur le Compute.
• Mise à l’échelle dynamique : Basée sur la métrique ASGAverageCPUUtilization fixée à 70 % (heures ouvrées).

4.3. Automatisation du déploiement

L’initialisation système est immuable et gérée par Cloud-Init.

#!/bin/bash
# [Insérer ici la suite du script d'initialisation Cloud-Init / Gunicorn]

(📸 Insérer ici une capture d’écran des graphes de l’Auto Scaling Group montrant les extinctions nocturnes)

5. Stockage et Interconnexion Filesystem

5.1. Base de données et Cache

• RDS PostgreSQL 15 : Instance db.m6i.large (ou db.t3.medium en compromis initial) déployée en Multi-AZ. Le failover DNS automatique s’opère en moins de 60 secondes vers eu-west-3b.
• Stockage RDS : 300 Go en volume gp3, paramétré avec 3 000 IOPS de base et 125 Mo/s de débit.
• Extensions PostgreSQL : Activées via le DB Parameter Group : pg_trgm, uuid-ossp, pg_stat_statements.
• ElastiCache (Redis 7.x) : Nœud cache.t3.medium (3,24 GiB RAM) provisionné dans eu-west-3a pour gérer les sessions de 50 utilisateurs simultanés avec une latence infra-milliseconde.

5.2. Montage NFS Persistant (Hybride)

Les EC2 lisent en continu sur le NAS local de 12 To via NFSv4 (TCP/2049) à travers le VPN. Le fichier /etc/fstab des instances est configuré avec une forte tolérance aux coupures réseau :

192.168.10.50:/volume1/archives /opt/cirrus-app/media nfs rw,hard,intr,rsize=1048576,wsize=1048576,tcp,timeo=600,retrans=2,nofail 0 0

• Détails techniques : hard,intr empêche le gel de l’OS en cas de chute du VPN. rsize/wsize calibrés à 1 Mo maximisent le débit. timeo=600,retrans=2 offre 60 secondes de tolérance avant retransmission.

6. Supervision Centralisée et Alerting

6.1. CloudWatch Agent

Chaque EC2 exécute le démon amazon-cloudwatch-agent pour la traçabilité légale (12 mois de rétention). Le fichier JSON d’ingestion provisionné sous /opt/aws/amazon-cloudwatch-agent/bin/config.json démarre ainsi :

{
  // [Insérer ici la suite de la configuration JSON de CloudWatch]
}

6.2. Alertes Métriques (SNS)

1. Sécurité (SSH) : Un filtre métrique scrute le groupe Cirrus-OS-Auth-Logs pour “Failed password for invalid user”. Au-delà de 5 tentatives en 5 minutes, une alerte est envoyée par SMS/e-mail via Amazon SNS.
2. Performance (CPU) : Notification envoyée si l’Auto Scaling Group dépasse 80 % d’utilisation CPU pendant deux périodes de 5 minutes consécutives.
3. FinOps (Billing) : Alarme sur la métrique EstimatedCharges. Une alerte est envoyée à la DSI dès que 80 % du budget mensuel est atteint.

(📸 Insérer ici une capture d’écran du tableau de bord CloudWatch avec l’alarme de facturation ou les alertes SSH)

6.3. Sécurité IAM

L’authentification inter-services utilise des rôles éphémères attachés aux Instance Profiles, interdisant les clés statiques.

{
  // [Insérer ici la suite des politiques Trust et Permissions IAM]
}

7. 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 réel). L’application d’Instances Réservées (1-Year No Upfront) sur RDS et ElastiCache génère environ 30 % d’économies sur la capacité de calcul.

(Sans la stratégie FinOps, le coût sur 2 ans aurait été de 12 432 $. L’économie brute est supérieure à 1 300 $)

Synthèse Analytique du Déploiement :

• Compute (6,7 % vs 40-50 % cible) : Gain massif grâce à l’extinction hors des heures ouvrées par l’ASG.
• Database & Cache (50,2 % vs 30-35 % cible) : Surcoût lié à la survie des données et au PRA (Déploiement Multi-AZ obligatoire pour le RTO < 2h).
• Réseau (36,1 % vs 5-10 % cible) : Représente le coût réel d’une architecture Enterprise-Grade étanche à Internet (NAT Gateways redondées, tunnel VPN IPsec persistant, IPs publiques facturées).
• Sécurité & Monitoring (7,0 % vs 15 % cible) : Coûts maîtrisés grâce au maintien du stockage lourd (12 To) On-Premise via le VPN. Le budget ne couvre que la gouvernance périphérique à bas coût. L’utilisation d’Ubuntu, PostgreSQL, Redis et Python élimine les coûts de licences commerciales.