Conception d’une migration sécurisée d’une application web vers AWS

Projet en bref

Contexte

Ce projet consistait à préparer la migration vers le cloud d’une application interne de sécurisation de données. Son architecture historique reposait sur un serveur web Apache, une base MySQL et un partage de fichiers CIFS/SMB hébergés sur une infrastructure proche de sa capacité maximale et de sa fin de support.

Cette organisation présentait plusieurs limites : des composants uniques, une montée en charge difficile, une forte dépendance au stockage type fichier et des opérations d’exploitation largement manuelles.

Mon rôle a été d’analyser ces contraintes, de comparer plusieurs fournisseurs cloud, de proposer une cible technique cohérente et de construire un plan de migration exploitable par les équipes projet, développement, base de données, sécurité et métier.

Objectifs techniques

• Améliorer la disponibilité du frontal web et de la base de données ;
• adapter la capacité de calcul au nombre d’utilisateurs ;
• faire évoluer le stockage historique vers un service cloud plus durable ;
• sécuriser les accès, les données, les sauvegardes et la traçabilité ;
• définir une migration progressive avec des critères de validation et un retour arrière.

Architecture retenue

La cible s’appuie sur des services managés AWS et une répartition sur deux zones de disponibilité. Le frontal Apache est placé derrière un Application Load Balancer et intégré à un groupe Auto Scaling. La base MySQL est transférée vers Amazon RDS Multi-AZ.

Le stockage objet Amazon S3 constitue la cible durable. Une transition temporaire par Amazon FSx for Windows File Server reste possible lorsque la compatibilité SMB/CIFS doit être maintenue pendant l’adaptation de l’application.

flowchart LR
    U["Utilisateurs"] -->|"HTTPS"| ALB["Application<br/>Load Balancer"]

    subgraph Cloud["AWS — architecture multi-AZ"]
        ALB --> WEB["Serveurs Apache<br/>EC2 Auto Scaling"]
        WEB --> DB[("RDS MySQL<br/>Multi-AZ")]
        WEB --> API["Accès objet<br/>SDK ou API"]
        API --> S3[("Amazon S3<br/>versioning + lifecycle")]
        WEB -. "transition éventuelle" .-> FSX[("Amazon FSx<br/>SMB/CIFS")]
    end

    OPS["CloudWatch · CloudTrail<br/>AWS Backup · Budgets"]
    WEB -. "journaux et métriques" .-> OPS
    DB -. "sauvegardes" .-> OPS
    S3 -. "audit et coûts" .-> OPS

Les principaux choix de sécurité sont :

• Des ressources applicatives et de données placées dans des sous-réseaux privés ;
• une exposition publique limitée au répartiteur HTTPS ;
• des rôles IAM appliquant le principe du moindre privilège ;
• le chiffrement des volumes, bases, objets et sauvegardes avec AWS KMS ;
• la centralisation des journaux, métriques et événements d’audit ;
• des sauvegardes restaurables et des critères RTO/RPO à valider avec le métier.

Travaux réalisés

Veille et aide à la décision

• Analyse des modèles IaaS, PaaS et SaaS ;
• comparaison d’AWS, Azure, Google Cloud et OVHcloud ;
• étude des stratégies de rehost, replatform et refactor ;
• sélection d’AWS à partir des contraintes du frontal web, de MySQL, de SMB/CIFS, de la supervision et des coûts.

Conception de l’architecture

• Identification des points uniques de défaillance de l’existant ;
• conception d’un VPC réparti sur deux zones de disponibilité ;
• remplacement du frontal unique par un ALB et des instances EC2 Auto Scaling ;
• remplacement de MySQL local par RDS MySQL Multi-AZ ;
• définition d’une trajectoire de stockage en deux scénarios : FSx pour la transition et S3 pour la cible.

Sécurité et continuité

• Définition du cloisonnement réseau et des flux autorisés ;
• intégration d’IAM, KMS, CloudTrail, CloudWatch et AWS Backup ;
• proposition d’objectifs de reprise et de perte de données ;
• préparation des contrôles de sauvegarde, de restauration, de recette et de retour en arrière.

Planification et pilotage

• Construction d’un planning de migration sur huit semaines ;
• répartition des responsabilités entre les équipes ;
• définition de critères de go/no-go avant la bascule ;
• estimation des charges projet et des coûts récurrents des deux scénarios ;
• préparation d’un support de kick-off accessible à un public non technique.

Difficultés et choix techniques

Conserver la compatibilité ou moderniser le stockage

Problème : l’application dépend d’un partage CIFS/SMB, alors qu’un stockage objet est mieux adapté à une architecture cloud durable.

Analyse : une migration directe vers S3 réduit le coût récurrent et la dépendance au serveur de fichiers, mais impose une adaptation du code et davantage de tests. FSx limite les changements initiaux, au prix d’une solution transitoire plus coûteuse.

Décision : présenter au décideur deux trajectoires, l’une passant par FSx pour une sortie rapide du datacenter avant de viser S3, l’autre engageant une transformation directe si le délai et les ressources le permettent.

Résultat : le plan sépare clairement la réduction du risque à court terme de l’objectif d’optimisation à long terme.

Renforcer la disponibilité sans complexifier l’exploitation

Problème : Apache et MySQL constituaient des points uniques de défaillance.

Analyse : la simple duplication de serveurs aurait amélioré la disponibilité, mais aurait aussi conservé une charge d’administration importante.

Décision : associer ALB et EC2 Auto Scaling pour le web, puis utiliser RDS MySQL Multi-AZ pour déléguer une partie de la haute disponibilité, des sauvegardes et de la maintenance.

Résultat attendu : une architecture capable d’absorber les variations de charge et de mieux résister à la perte d’une instance ou d’une zone.

Planifier avec des données d’entrée incomplètes

Problème : les volumes, les dépendances applicatives, les objectifs RTO/RPO et la fenêtre de coupure n’étaient pas encore confirmés.

Analyse : inventer ces valeurs aurait rendu le budget et le planning artificiellement précis.

Décision : documenter les hypothèses, prévoir un audit en première semaine et appliquer une marge de cadrage de plus ou moins 20 % aux estimations.

Résultat : les inconnues deviennent des points de validation explicites plutôt que des risques cachés.

Résultats

Le projet a produit une proposition d’architecture et un plan de migration documentés ; il ne correspond pas à un déploiement AWS en production.

La stratégie retenue permet d’arbitrer entre rapidité de migration et modernisation. Elle associe chaque étape à des responsables, des livrables, des critères de succès et une solution de retour en arrière.

Compétences démontrées

• Analyse d’une architecture existante et de ses risques ;
• veille technologique et comparaison de fournisseurs cloud ;
• conception d’une architecture AWS résiliente et évolutive ;
• sélection de services EC2, ALB, Auto Scaling, RDS, FSx et S3 ;
• application des principes IAM, chiffrement, journalisation et moindre privilège ;
• définition d’une stratégie de sauvegarde et de continuité d’activité ;
• préparation d’un plan de migration, de recette et de rollback ;
• estimation de charges et de coûts cloud ;
• communication technique adaptée aux décideurs et aux équipes opérationnelles ;
• création de schémas d’architecture avec Mermaid.

Retour d’expérience

Ce projet m’a montré qu’une migration cloud ne se limite pas au remplacement de serveurs locaux par des machines virtuelles distantes. La valeur vient surtout de l’utilisation raisonnée des services managés, de l’automatisation de l’exploitation et de la suppression progressive des dépendances historiques.

L’arbitrage entre FSx et S3 illustre également l’importance d’une trajectoire adaptée au contexte. Viser directement la meilleure cible technique peut représenter un risque supérieur à celui d’une trajectoire/migration en deux temps / d’une approche progressive. Une migration solide doit donc relier architecture, contraintes applicatives, continuité métier, coûts et capacité de changement des équipes.

Avec davantage de temps, je compléterais cette étude par un prototype Infrastructure as Code avec Terraform, des tests de restauration automatisés, une simulation de charge et un chiffrage fondé sur les métriques réelles de l’application.