Lab : Analyse et Conception d'Architecture EC2
Objectifs du Lab
Ce lab est un exercice de conception et d'analyse. Vous allez :
- ✅ Analyser des architectures EC2 existantes
- ✅ Identifier les bonnes pratiques et les erreurs
- ✅ Concevoir votre propre architecture
- ✅ Justifier vos choix techniques
Approche Théorique
Ce lab ne nécessite pas d'accès AWS. Vous travaillerez sur papier/document avec des schémas et des analyses.
Durée Estimée
2 heures
Partie 1 : Analyse d'Architecture Existante
Scénario : Site E-Commerce
Voici l'architecture actuelle d'un site e-commerce :
┌─────────────────────────────────────────────────────────────┐
│ RÉGION : us-east-1 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ AZ : us-east-1a │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Instance EC2 : i-web001 │ │ │
│ │ │ Type : t2.micro │ │ │
│ │ │ AMI : Amazon Linux 2 │ │ │
│ │ │ IP Publique : 52.1.2.3 │ │ │
│ │ │ │ │ │
│ │ │ Applications : │ │ │
│ │ │ - Apache (port 80) │ │ │
│ │ │ - MySQL (port 3306) │ │ │
│ │ │ - Application PHP │ │ │
│ │ │ │ │ │
│ │ │ Security Group : sg-default │ │ │
│ │ │ Règles : │ │ │
│ │ │ - Inbound: SSH (22) - 0.0.0.0/0 │ │ │
│ │ │ - Inbound: HTTP (80) - 0.0.0.0/0 │ │ │
│ │ │ - Inbound: MySQL (3306) - 0.0.0.0/0 │ │ │
│ │ │ │ │ │
│ │ │ Stockage : 8 GB EBS (gp2) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Questions d'Analyse
Question 1 : Problèmes de Sécurité
Identifiez au moins 3 problèmes de sécurité dans cette architecture.
💡 Indice
Regardez :
- Les règles du Security Group
- L'emplacement de MySQL
- L'architecture mono-instance
Question 2 : Problèmes de Disponibilité
Identifiez les risques de disponibilité de cette architecture.
💡 Indice
Pensez à :
- Nombre de zones de disponibilité
- Point de défaillance unique (SPOF)
- Capacité de montée en charge
Question 3 : Problèmes de Performance
Le site devient lent pendant les soldes. Quelles sont les causes possibles ?
💡 Indice
Analysez :
- Le type d'instance
- La séparation des composants
- Le stockage
Partie 2 : Correction de l'Architecture
Exercice : Proposer une Meilleure Architecture
Redesinez l'architecture en corrigeant les problèmes identifiés.
Contraintes :
- Budget modéré (pas d'instances géantes)
- Site doit être disponible 99.9%
- Base de données doit être sécurisée
- Doit supporter les pics de trafic (soldes)
Template de Réponse
Remplissez ce template :
NOUVELLE ARCHITECTURE PROPOSÉE
==============================
Région : _____________
Zones de Disponibilité utilisées : ____________
COMPOSANT 1 : Serveur(s) Web
----------------------------
- Nombre d'instances : _____
- Type d'instance : _____
- AMI : _____
- Placement : _____
- Security Group :
- Inbound : _____
- Outbound : _____
COMPOSANT 2 : Base de Données
-----------------------------
- Service/Instance : _____
- Type : _____
- Placement : _____
- Security Group :
- Inbound : _____
COMPOSANT 3 : (Optionnel)
-------------------------
- _____
JUSTIFICATIONS
--------------
1. Pourquoi ce type d'instance ? _____
2. Pourquoi cette configuration réseau ? _____
3. Comment gérez-vous la haute disponibilité ? _____
Partie 3 : Schéma d'Architecture
Exercice : Dessiner l'Architecture
Créez un schéma d'architecture professionnel incluant :
Éléments obligatoires :
- La région AWS
- Au moins 2 zones de disponibilité
- Les instances EC2 (web)
- La base de données (séparée)
- Les Security Groups avec leurs règles
- Les connexions réseau
Outils suggérés :
- Draw.io (gratuit) : https://app.diagrams.net/
- Lucidchart (gratuit limité)
- PowerPoint/Google Slides
- Papier et crayon (photo à joindre)
Exemple de Structure
┌─────────────────────────────────────────────────────────────┐
│ RÉGION : __________ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────┐ │
│ │ [Votre composant] │ │
│ └──────────────────────────────────────┘ │
│ │
│ ┌───────────────────┐ ┌───────────────────┐ │
│ │ AZ : ____ │ │ AZ : ____ │ │
│ │ │ │ │ │
│ │ [Instances] │ │ [Instances] │ │
│ │ │ │ │ │
│ └───────────────────┘ └───────────────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ [Base de données] │ │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Partie 4 : Étude de Cas - Choix d'Instances
Scénario A : Startup - MVP
Contexte :
- Application web simple (blog + formulaire contact)
- 100 visiteurs/jour attendus
- Budget très limité (< $20/mois)
- Équipe de 2 développeurs
Questions :
1. Quel type d'instance recommandez-vous ?
2. Quelle région ?
3. Quels compromis faites-vous ?
Scénario B : PME - Application Métier
Contexte :
- ERP/CRM pour 50 employés
- Base de données PostgreSQL (20 GB)
- Utilisation 8h-18h, lundi-vendredi
- Besoin de performances constantes
Questions :
1. Quel type d'instance pour l'application ?
2. Quel type d'instance pour la base de données ?
3. Faut-il des instances Reserved ?
Scénario C : E-Commerce - Black Friday
Contexte :
- Site e-commerce existant
- Trafic normal : 1000 visiteurs/heure
- Black Friday : 50000 visiteurs/heure (pic)
- Catalogue de 10000 produits
Questions :
1. Comment gérer le pic de trafic ?
2. Quelle stratégie de scaling ?
3. Quels types d'instances pour chaque niveau de charge ?
Partie 5 : Tableau Récapitulatif des Choix
Complétez ce tableau pour chaque scénario :
| Critère | Scénario A | Scénario B | Scénario C |
|---|---|---|---|
| Instance Web | |||
| Instance BDD | |||
| Modèle de prix | |||
| Nombre d'AZ | |||
| Coût estimé/mois | |||
| Justification principale |
Livrables du Lab
Document à Remettre
Créez un document (Word, PDF ou Markdown) contenant :
1. Page de titre
- Nom, date, titre du lab
2. Partie 1 : Analyse (20%)
- Liste des 3+ problèmes de sécurité
- Liste des risques de disponibilité
- Analyse des problèmes de performance
3. Partie 2 : Correction (25%)
- Template rempli avec la nouvelle architecture
- Justifications détaillées
4. Partie 3 : Schéma (25%)
- Schéma d'architecture clair et lisible
- Légende des composants
- Security Groups documentés
5. Partie 4 : Études de Cas (20%)
- Réponses pour les 3 scénarios
- Justifications des choix
6. Partie 5 : Tableau (10%)
- Tableau récapitulatif complété
Grille d'Évaluation
| Critère | Points |
|---|---|
| Identification correcte des problèmes | 4 |
| Architecture corrigée cohérente | 5 |
| Schéma clair et complet | 5 |
| Choix d'instances justifiés | 4 |
| Tableau récapitulatif complet | 2 |
| Total | 20 |
Correction - Partie 1 (À consulter après avoir fait l'exercice)
📋 Voir la correction
Problèmes de Sécurité
-
SSH ouvert à tout le monde (0.0.0.0/0)
- Risque : Attaques brute-force
- Solution : Restreindre à l'IP de l'admin
-
MySQL exposé publiquement (0.0.0.0/0)
- Risque : Accès non autorisé à la BDD
- Solution : Fermer le port, accès interne uniquement
-
Tout sur la même instance
- Risque : Si l'instance est compromise, tout l'est
- Solution : Séparer web et BDD
-
Utilisation du SG par défaut
- Risque : Règles non auditées
- Solution : Créer des SG spécifiques
Problèmes de Disponibilité
-
Une seule AZ
- Risque : Panne de zone = site down
- Solution : Multi-AZ
-
Instance unique (SPOF)
- Risque : Panne instance = site down
- Solution : Multiple instances + Load Balancer
-
Pas de backup visible
- Risque : Perte de données
- Solution : Snapshots EBS, RDS Multi-AZ
Problèmes de Performance
-
t2.micro trop petit
- Crédits burst épuisés rapidement
- Solution : t3.small minimum pour production
-
MySQL sur la même instance
- Compétition pour les ressources
- Solution : Instance dédiée ou RDS
-
8 GB de stockage insuffisant
- Solution : EBS gp3, plus grand
Ressources pour le Lab
Icônes AWS
Documentation
Calculateur de Prix
Félicitations ! Vous avez complété le lab d'architecture EC2. Ces compétences de conception sont essentielles pour tout architecte cloud.