Lab : Gestion du Stockage EBS
Objectif du Lab
Dans ce lab, vous allez apprendre à gérer le stockage EBS : création de volumes, attachement à des instances, snapshots, et bonnes pratiques de gestion. C'est un exercice d'analyse et de documentation.
Approche Pédagogique
Ce lab combine théorie et analyse de scénarios. Vous documenterez vos réponses et justifications.
Partie 1 : Concepts Fondamentaux
Rappel des Types de Volumes EBS
┌─────────────────────────────────────────────────────────────┐
│ TYPES DE VOLUMES EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ TYPE │ USAGE │ IOPS │ COÛT │
│ ─────────────┼───────────────────┼───────────┼────────────│
│ gp3 │ Usage général │ 3,000-16K │ $0.08/GB │
│ gp2 │ Usage général │ 3,000 max │ $0.10/GB │
│ io2 │ I/O intensif │ 64,000 │ $0.125/GB │
│ st1 │ Big data, logs │ 500 │ $0.045/GB │
│ sc1 │ Archives froides │ 250 │ $0.025/GB │
│ │
│ Recommandation pour débutants : │
│ • gp3 pour tout usage général │
│ • st1 pour logs/données séquentielles │
│ │
└─────────────────────────────────────────────────────────────┘
Exercice 1.1 : Choix du Type de Volume
Pour chaque scénario, choisissez le type de volume EBS approprié et justifiez :
| Scénario | Votre Choix | Justification |
|---|---|---|
| Base de données MySQL production | ? | ? |
| Logs d'application (100GB) | ? | ? |
| Serveur web statique | ? | ? |
| Application de trading haute fréquence | ? | ? |
| Archives de documents (rarement accédés) | ? | ? |
💡 Solutions
| Scénario | Choix | Justification |
|---|---|---|
| Base de données MySQL production | io2 | IOPS élevées et consistantes nécessaires |
| Logs d'application (100GB) | st1 | Accès séquentiel, coût optimisé |
| Serveur web statique | gp3 | Bon équilibre coût/performance |
| Application de trading | io2 | Latence minimale critique |
| Archives de documents | sc1 | Accès rare, coût minimal |
Partie 2 : Cycle de Vie d'un Volume EBS
Diagramme du Cycle de Vie
┌─────────────────────────────────────────────────────────────┐
│ CYCLE DE VIE D'UN VOLUME EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Créer │ │
│ │ Volume │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ État: │ │ Attacher │ │
│ │ available │───────►│ à EC2 │ │
│ └─────────────┘ └──────┬──────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────┴──────┐ ┌─────────────┐ │
│ │ Détacher │◄───────│ État: │ │
│ │ de EC2 │ │ in-use │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Snapshot │ │
│ │ (backup) │ │
│ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Supprimer │ │
│ │ Volume │ │
│ └─────────────┘ │
│ │
│ ⚠️ Attention : Supprimer un volume efface toutes les │
│ données ! Toujours faire un snapshot avant. │
│ │
└─────────────────────────────────────────────────────────────┘
Exercice 2.1 : Commandes CLI
Associez chaque action à la commande CLI correcte :
| Action | Commande |
|---|---|
| Créer un volume de 100GB | ? |
| Lister tous les volumes | ? |
| Attacher un volume à une instance | ? |
| Créer un snapshot | ? |
| Détacher un volume | ? |
💡 Solutions
# Créer un volume de 100GB
aws ec2 create-volume \
--size 100 \
--volume-type gp3 \
--availability-zone us-east-1a
# Lister tous les volumes
aws ec2 describe-volumes
# Attacher un volume à une instance
aws ec2 attach-volume \
--volume-id vol-xxx \
--instance-id i-xxx \
--device /dev/sdf
# Créer un snapshot
aws ec2 create-snapshot \
--volume-id vol-xxx \
--description "Backup before maintenance"
# Détacher un volume
aws ec2 detach-volume --volume-id vol-xxx
Partie 3 : Scénarios Pratiques
Scénario A : Augmentation de Capacité
Contexte : Le volume root de votre serveur de base de données (20GB) est presque plein (95%). Vous devez augmenter la capacité à 50GB sans downtime.
Questions :
- Quelle méthode utiliseriez-vous ?
- Quelles sont les étapes ?
- Y a-t-il un risque de perte de données ?
💡 Solution Scénario A
Méthode : Modification du volume (EBS Elastic Volumes)
AWS permet de modifier la taille d'un volume EBS à chaud (sans arrêter l'instance) !
Étapes :
- Créer un snapshot (précaution)
aws ec2 create-snapshot --volume-id vol-xxx --description "Before resize"
- Modifier la taille du volume
aws ec2 modify-volume --volume-id vol-xxx --size 50
- Surveiller la modification
aws ec2 describe-volumes-modifications --volume-id vol-xxx
# Attendre que l'état soit "completed"
- Étendre le système de fichiers (sur l'instance)
# Pour ext4
sudo resize2fs /dev/xvda1
# Pour XFS
sudo xfs_growfs /
Risques :
- Minimal si snapshot fait avant
- Le volume reste accessible pendant la modification
- L'extension du filesystem est instantanée
Scénario B : Migration de Données
Contexte : Vous devez migrer une base de données MySQL d'une instance EC2 (us-east-1a) vers une autre instance dans une AZ différente (us-east-1b).
Questions :
- Pouvez-vous simplement détacher et réattacher le volume ?
- Quelle est la procédure correcte ?
- Comment minimiser le downtime ?
💡 Solution Scénario B
Réponse 1 : NON ! Un volume EBS ne peut être attaché qu'à des instances dans la même AZ.
Procédure correcte :
- Arrêter MySQL proprement (minimiser les données en cours)
sudo systemctl stop mysql
- Créer un snapshot du volume
aws ec2 create-snapshot --volume-id vol-xxx --description "Migration"
- Créer un nouveau volume depuis le snapshot dans la nouvelle AZ
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1b \
--volume-type gp3
- Attacher le nouveau volume à la nouvelle instance
aws ec2 attach-volume \
--volume-id vol-new \
--instance-id i-new \
--device /dev/sdf
- Monter et démarrer MySQL
sudo mount /dev/sdf /var/lib/mysql
sudo systemctl start mysql
Minimiser le downtime :
- Préparer la nouvelle instance à l'avance
- Utiliser une réplication MySQL avant la migration
- Faire la migration pendant une fenêtre de maintenance
Scénario C : Récupération après Incident
Contexte : Un développeur a accidentellement supprimé des fichiers importants sur un volume. Le volume fait 200GB et la dernière sauvegarde date d'hier.
Questions :
- Comment récupérer les fichiers ?
- Quelle est la procédure si le snapshot existe ?
- Comment éviter ce problème à l'avenir ?
💡 Solution Scénario C
Récupération via Snapshot :
- Identifier le snapshot le plus récent
aws ec2 describe-snapshots \
--filters "Name=volume-id,Values=vol-xxx" \
--query 'Snapshots[*].[SnapshotId,StartTime]' \
--output table
- Créer un nouveau volume depuis le snapshot
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1a \
--volume-type gp3
- Attacher le volume de récupération
aws ec2 attach-volume \
--volume-id vol-recovery \
--instance-id i-xxx \
--device /dev/sdg
- Monter et copier les fichiers manquants
sudo mkdir /mnt/recovery
sudo mount /dev/sdg /mnt/recovery
cp /mnt/recovery/path/to/files /path/to/restore/
- Nettoyer après récupération
sudo umount /mnt/recovery
aws ec2 detach-volume --volume-id vol-recovery
aws ec2 delete-volume --volume-id vol-recovery
Prévention :
- Snapshots automatiques avec Amazon Data Lifecycle Manager
- Backups réguliers (horaires pour données critiques)
- Permissions restrictives (IAM) pour éviter les suppressions accidentelles
- Versioning pour S3 si applicable
Partie 4 : Bonnes Pratiques
Checklist de Gestion EBS
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST BONNES PRATIQUES EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ SNAPSHOTS ET BACKUPS │
│ ☐ Snapshots automatiques configurés (DLM) │
│ ☐ Rétention définie (7 jours min pour prod) │
│ ☐ Snapshots testés (restauration validée) │
│ ☐ Snapshots cross-region pour DR │
│ │
│ PERFORMANCE │
│ ☐ Type de volume adapté à l'usage │
│ ☐ IOPS provisionnées si nécessaire (io2) │
│ ☐ Monitoring CloudWatch activé │
│ ☐ Alertes sur utilisation > 80% │
│ │
│ SÉCURITÉ │
│ ☐ Encryption activée (AES-256) │
│ ☐ Clés KMS gérées correctement │
│ ☐ Permissions IAM restrictives │
│ │
│ COÛTS │
│ ☐ Volumes non utilisés supprimés │
│ ☐ Snapshots anciens nettoyés │
│ ☐ Type gp3 préféré à gp2 (meilleur rapport coût) │
│ │
│ TAGS │
│ ☐ Nom descriptif │
│ ☐ Environnement (prod/dev/test) │
│ ☐ Application associée │
│ ☐ Propriétaire/équipe │
│ │
└─────────────────────────────────────────────────────────────┘
Data Lifecycle Manager (DLM)
┌─────────────────────────────────────────────────────────────┐
│ AMAZON DATA LIFECYCLE MANAGER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Automatise les snapshots EBS │
│ │
│ Exemple de politique : │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Nom : daily-backup-policy │ │
│ │ │ │
│ │ Cible : Volumes avec tag "Backup=true" │ │
│ │ │ │
│ │ Schedule : │ │
│ │ • Fréquence : Tous les jours à 03:00 UTC │ │
│ │ • Rétention : 7 snapshots (1 semaine) │ │
│ │ │ │
│ │ Options : │ │
│ │ • Copie cross-region : us-west-2 │ │
│ │ • Tags copiés : Oui │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Configuration CLI : │
│ aws dlm create-lifecycle-policy \ │
│ --description "Daily EBS backup" \ │
│ --state ENABLED \ │
│ --execution-role-arn arn:aws:iam::xxx:role/dlm-role \ │
│ --policy-details file://policy.json │
│ │
└─────────────────────────────────────────────────────────────┘
Partie 5 : Livrable
Document à Produire
Créez un document "Plan de Gestion EBS" pour une application fictive avec :
-
Inventaire des volumes (tableau)
- Nom, taille, type, AZ, instance attachée
-
Politique de snapshots
- Fréquence par environnement
- Rétention
- Tests de restauration
-
Procédures documentées
- Augmentation de capacité
- Migration inter-AZ
- Récupération après incident
-
Estimation des coûts mensuels
- Volumes
- Snapshots
- IOPS provisionnées (si applicable)
Critères d'Évaluation
| Critère | Points |
|---|---|
| Exercices 1-3 correctement complétés | /40 |
| Inventaire des volumes | /15 |
| Politique de snapshots claire | /15 |
| Procédures bien documentées | /20 |
| Estimation des coûts | /10 |
| Total | /100 |
Résumé
| Concept | Points Clés |
|---|---|
| Types de volumes | gp3 par défaut, io2 pour IOPS |
| Snapshots | Incrémentaux, stockés sur S3 |
| Contrainte AZ | Volume = 1 AZ uniquement |
| Migration | Via snapshot + nouveau volume |
| DLM | Automatisation des backups |
Retour : Vue d'ensemble MODULE 4