Amazon EBS (Elastic Block Store) — Guide complet

1) Qu’est-ce qu’EBS ? Qu’est-ce que le stockage en mode bloc ?

Amazon EBS est un service de stockage persistant en mode bloc pour Amazon EC2. Un volume EBS se comporte comme un disque que l’on attache à une instance EC2 (NVMe/virtio).

• Stockage bloc : les données sont découpées en blocs de taille fixe (ex. 4–256 Ko). Le système de fichiers (ext4, XFS, NTFS) organise ces blocs en fichiers/dossiers.
  • Avantages : faible latence, IOPS élevées, idéal pour bases de données, volumes de démarrage, journaling, transactions.
• Comparaisons rapides :
  • Fichier (EFS/FSx) : accès partagé via NFS/SMB, parfait pour plusieurs serveurs qui lisent/écrivent les mêmes fichiers.
  • Objet (S3) : stocke des objets complets (fichiers) avec méta‑données, très durable et économique, pas de système de fichiers POSIX ni de montage bloc.

À retenir : EBS = disque hautes performances, attaché à une instance et limité à une Zone de Disponibilité (AZ). Pour partager entre plusieurs instances, voir EFS ou FSx (ou EBS Multi‑Attach avec volumes io1/io2 et un système/cluster compatible).

2) Caractéristiques clés d’EBS

• Portée AZ : un volume s’attache à des instances dans la même AZ.
• Persistance : indépendant du cycle de vie de l’EC2 ; configurable DeleteOnTermination.
• Durabilité & réplication : données répliquées dans l’AZ (tolérance pannes matérielles locales).
• Chiffrement : chiffrement au repos par EBS + AWS KMS (clé gérée AWS ou CMK). Héritée sur snapshots et volumes restaurés.
• Snapshots : sauvegardes incrémentales stockées dans S3 ; copie inter‑région possible ; Fast Snapshot Restore (FSR) pour pleine perf dès l’attache.
• Elastic Volumes : modifier en ligne la taille, le type, l’IOPS/Throughput (gp3) sans arrêter l’instance.
• Performances :
  • IOPS (opérations/s), débit (Mo/s) et latence (ms).
  • Instances EBS‑Optimized (Nitro) recommandées.
  • Limites par type de volume (voir tableau).
• Multi‑Attach (io1/io2) : attacher le même volume à plusieurs instances dans la même AZ (jusqu’à 16). ⚠️ Nécessite un cluster ou un FS compatible (ex. Oracle RAC, GFS2). Ext4/XFS seuls → risque de corruption.
• Taille : jusqu’à 64 TiB par volume.

3) Types de volumes EBS et usages

SSD (transactionnels : latence basse, IOPS élevées)

• io2 Block Express / io2 (ex‑io1) : performances et durabilité maximales ; charges critiques (SAP HANA, Oracle, SQL Server, NoSQL haute charge).

• gp3 (recommandé) : excellent ratio prix/perf. On règle taille, IOPS et débit indépendamment (jusqu’à 16k IOPS et 1 000 Mo/s). gp2 est l’ancienne génération (IOPS liés à la taille) → migrer vers gp3.

HDD (débit séquentiel : Mo/s élevés, coût bas)

• st1 : gros débit pour données “chaudes” (Big Data, ETL, logs). Pas de volume de démarrage.

• sc1 : le moins cher pour données “froides” peu accédées. Pas de volume de démarrage.

4) Choisir entre EBS, EFS, FSx, S3 (raccourci)

• EBS : 1 instance ↔ 1 volume (ou Multi‑Attach contrôlé). DB, boot, transactions.
• EFS : plusieurs instances Linux, partage POSIX. Sites web, micro‑services, home dirs.
• FSx : systèmes de fichiers managés hautes perfs (Windows/NetApp/Lustre/OpenZFS).
• S3 : objets, archivage, data lake, diffusion statique. Pas de bloc POSIX.

5) Bonnes pratiques (prod)

• gp3 par défaut, ajuster IOPS et débit au besoin (pas plus).
• Chiffrement activé par défaut (comply). Gérer KMS et rotations clés.
• Snapshots réguliers (AWS Backup ou DLM) + rétention/lifecycle. Tester la restauration.
• Surveiller VolumeReadOps/WriteOps, VolumeReadBytes/WriteBytes, VolumeQueueLength, BurstBalance (legacy).
• FSR pour restaurations critiques, sinon pré‑chauffage (dd/fio).
• Éviter Multi‑Attach sans stack cluster compatible.
• RAID0 (striping) pour agréger perfs de plusieurs volumes ; RAID1 pour mirroring au niveau OS (pas commun avec EBS réplica AZ).
• Alignement & tuning FS : XFS/EXT4, noatime si pertinent, fio pour tester.
• Coûts : supprimer volumes orphelins, nettoyer snapshots, DeleteOnTermination maîtrisé.

6) Exemple complet — Mettre à jour des données (PostgreSQL sur EC2 + EBS)

Contexte : PostgreSQL en prod sur EC2 avec un volume gp3 de 200 GiB. On doit :

1. préparer une mise à jour lourde de données, 2) augmenter l’espace, 3) prévoir rollback rapide.

Étapes (sécurité & rapidité)

1. Snapshot avant changement :

   aws ec2 create-snapshot --volume-id vol-XXXX --description "Pre-update pgdata"
   

2. Cloner en environnement de test (QA) :
   • Créer un volume depuis snapshot → attacher à une instance QA → monter en lecture/écriture.
   • Valider la procédure de mise à jour et mesurer les perfs (fio/pgbench).
3. Augmenter la taille en production (Elastic Volumes) :

   aws ec2 modify-volume --volume-id vol-XXXX --size 400  # de 200 à 400 GiB
   # Puis, sur l'instance (Linux) :
   sudo growpart /dev/nvme0n1 1
   sudo resize2fs /dev/nvme0n1p1   # ou xfs_growfs /mnt/data
   

4. Mise à jour des données (fenêtre courte) :
   • Arrêt applicatif minimal, opération SQL, redémarrage.
   • Surveiller latence/IOPS CloudWatch pendant l’opération.
5. Rollback rapide (si besoin) :
   • Créer un nouveau volume depuis le snapshot initial et remonter.
   • Avec FSR, pleine perf immédiate au redémarrage.

Variante “zéro surprise” : faire la mise à jour sur clone puis basculer l’EC2 sur le volume mis à jour (changement d’attache), validé au préalable.

7) Tarification — modèle (sans chiffres)

• Stockage : facturé au Go‑mois selon le type (gp3/io2/st1/sc1).
• Performance provisionnée :
  • io1/io2 : IOPS provisionnées facturées.
  • gp3 : IOPS et débit au‑delà du baseline sont facturés séparément.
• Snapshots : Go‑mois stockés (incrémental). FSR facturé par AZ et heure activée.
• Transfert : attache dans la même AZ ; copies inter‑régions de snapshots facturées.

Vérifier la page AWS EBS Pricing de votre région pour les montants à jour.

8) Intégrations utiles (“match” naturel)

• EC2 (nécessaire), AWS Backup / DLM (snapshots), CloudWatch (perf & alertes), CloudTrail (audit),
• KMS (clés), Compute Optimizer (reco EBS), Systems Manager (patch/automations),
• EFS/FSx/S3 (complémentarité selon le modèle d’accès).

9) Tableau comparatif

10) Décision rapide (cheat‑sheet)

• Base de données prod → io2 (ou gp3 si charge modérée).
• Serveur applicatif / boot → gp3.
• ETL/Big Data séquentiel → st1.
• Archives peu accédées → sc1.
• Partage multi‑instances → EFS/FSx plutôt qu’EBS (sauf cas Multi‑Attach expert).