Ce texte retrace un projet de déploiement cloud sur Amazon Web Services réalisé dans le cadre d’un cursus d’ingénierie système. Le récit combine choix d’architecture, automatisation et bonnes pratiques de sécurité, avec des exemples concrets tirés d’un cas pédagogique.
Le projet mené par Lilo a abouti à une plateforme multi‑VPC sécurisée et optimisée pour un MVP, incluant bases de données RDS et pipelines CI/CD. Cette description conduit naturellement à une synthèse claire et actionnable des points essentiels.
A retenir :
- Architecture sécurisée VPC public et privé
- Automatisation via Cloud‑Init et Docker
- Peering pour isolation et faible latence
- Sauvegardes RDS et accès restreint
Architecture AWS VPC01 pour le déploiement cloud
Ces enjeux de sécurité et d’échelle ont guidé le choix d’un VPC principal organisé en subnets public et privé. Le VPC01 héberge l’instance d’application principale et les sous‑composants réseau nécessaires pour un déploiement cloud sûr.
La mise en place a inclus génération d’une paire SSH, association d’une Internet Gateway au subnet public, et définition d’un groupe de sécurité strict. Selon AWS, l’usage d’une clé SSH reste la méthode recommandée pour limiter les accès par mot de passe et améliorer l’authentification.
Lancement EC2 et sécurité réseau
Dans ce contexte, l’instance server01 a servi de bastion et de noeud d’application, avec Cloud‑Init pour l’automatisation initiale. Cloud‑Init a préinstallé Docker et appliqué les mises à jour, assurant une base reproductible pour les conteneurs.
Le groupe de sécurité limité au port 22 pour l’administration et aux ports applicatifs a réduit la surface d’attaque, et l’adresse IP publique a été attribuée uniquement au serveur bastion. Cette approche prépare le passage vers l’orchestration et l’automatisation réseau.
Composant
Rôle principal
Emplacement
EC2
Hébergement de l’application conteneurisée
Subnet public
RDS
Base de données relationnelle avec sauvegardes
Subnet privé
NAT Gateway
Accès sortant sécurisé pour instances privées
Subnet public
VPC Peering
Connectivité privée inter‑VPC
VPC01 VPC02
« J’ai déployé la première instance en suivant la consigne et la connexion SSH s’est établie dès la génération de la clé. »
Lilo N.
La table de routage du subnet public a redirigé le trafic 0.0.0.0/0 vers l’Internet Gateway, tandis que la plage interne est restée en 10.0.0.0/16. Selon Lilo, cette clarification du routage a facilité les tests et la validation réseau.
Un dernier point opérationnel a concerné la préparation du serveur pour le déploiement Docker et la connexion à la base RDS via endpoint privé. Cette préparation ouvre le chapitre sur l’automatisation et la livraison continue.
Automatisation et déploiement d’applications conteneurisées
Ce passage à l’automatisation découle directement de l’architecture préparée dans le VPC initial, afin d’assurer reproductibilité et rapidité. L’usage de Cloud‑Init et de Docker a standardisé les images et l’initialisation des bases.
Les variables d’environnement et le Dockerfile ont orchestré l’exécution de commandes Flask pour initialiser le schéma de la base, permettant des déploiements fiables. Selon Docaposte Institute, les ateliers pratiques accélèrent l’apprentissage des pipelines CI/CD et de l’infrastructure as code.
Déploiement Docker et configuration de l’application
Dans ce cadre, le Dockerfile a inclus les étapes de migration et d’initialisation de la base, garantissant la cohérence des schémas. Le fichier .env a centralisé l’endpoint RDS et les identifiants, évitant les fuites de configuration dans le code.
Les tests d’accès ont confirmé la création des tables MySQL et le bon fonctionnement de l’API, validant l’approche conteneurisée. Ce travail sur l’application prépare l’intégration d’un pipeline CI/CD pour automatiser les builds et déploiements.
Étapes d’automatisation :
- Construction d’image Docker et tests unitaires
- Déploiement via CodeDeploy ou ECS
- Intégration des migrations de base automatisées
- Surveillance post‑déploiement et rollback configuré
« J’ai automatisé les migrations et réduit le temps de déploiement manuel à presque zéro lors des ateliers. »
Marie D.
La mise en place d’un pipeline CI/CD s’appuie sur AWS CodePipeline, CodeBuild et CodeDeploy pour une intégration fluide. Selon AWS, l’intégration de la sécurité dans le pipeline est une pratique recommandée pour détecter les vulnérabilités rapidement.
Séparation d’environnements et peering inter‑VPC sécurisé
Le besoin d’isoler l’équipe IA a motivé la création d’un second VPC, puis l’établissement d’un peering non transitoire avec VPC01. Ce choix a renforcé la sécurité tout en maintenant une connectivité privée nécessaire aux échanges de données.
Les tables de routage ont été mises à jour dans chaque VPC pour diriger les plages CIDR via le peering, et des tests SSH ont confirmé la latence faible et la connectivité privée. Selon Lilo, le peering a été déterminant pour séparer les environnements tout en conservant l’efficacité opérationnelle.
Mise en place du peering et ajustement des routes
Dans cette étape, VPC01 a été configuré pour router vers le CIDR de VPC02 via l’appairage, et inversement pour VPC02. Les règles de sécurité ont été affinées pour n’autoriser que le trafic nécessaire entre les deux environnements.
Services AWS clés :
- VPC Peering pour interconnexion privée et rapide
- NAT Gateway pour mises à jour depuis subnets privés
- RDS avec sauvegardes automatiques et accès restreint
- Groupes de sécurité pour segmentation fine du trafic
Tests, validation et retours pratiques
Dans les validations finales, un test SSH de VPC à VPC et un ping via la NAT ont confirmé les chemins réseau et la capacité de mise à jour depuis les instances privées. Ces essais ont permis d’identifier et corriger de petites règles de routage.
Un tableau comparatif des stratégies de déploiement a aidé l’équipe à choisir une méthode adaptée au MVP, en privilégiant un déploiement progressif pour limiter les risques. Ce choix marque l’étape finale avant l’exploitation contrôlée.
Stratégie
Avantage principal
Cas d’utilisation
Complexité
Rolling
Mises à jour progressives
Services stateless
Moyenne
Blue/Green
Rollback rapide
Applications critiques
Élevée
Canary
Tests sur sous‑trafic
Nouvelles fonctionnalités
Moyenne
All‑at‑once
Déploiement simple
Petits MVP
Faible
« Le peering a réduit nos aller‑retour réseau et simplifié l’accès aux ressources partagées entre équipes. »
Julien B.
« L’expérience de la formation a rendu tangible la gestion des coûts et la mise en place d’un MVP fonctionnel. »
Thomas N.
Source : Lilo, « Consigne du Projet E4 », PDF, 21/02/2025.