Stockage AWS — Cheat Sheet Cloud Practitioner
Le stockage AWS couvre plusieurs services distincts selon le type d’usage : stockage bloc (EBS, Instance Store), stockage fichier partagé (EFS, FSx), et stockage objet (S3). Comprendre quand utiliser quoi est l’une des compétences les plus testées au CLF-C02.
Vue d’ensemble — les 5 services de stockage AWS
| Service | Type | Accès | Cas d’usage principal | Persistance |
| Amazon S3 | Objet | Via HTTP/API — depuis partout | Fichiers, médias, backups, sites statiques, data lake | Oui — multi-AZ natif |
| Amazon EBS | Bloc | Attaché à une instance EC2 | Disque OS, bases de données, apps haute performance | Oui — dans une AZ |
| Instance Store | Bloc local | Interne à l’instance (physique) | Cache temporaire, buffers, données éphémères | Non — perdu au stop/terminate |
| Amazon EFS | Fichier (NFS) | Monté sur plusieurs EC2 Linux simultanément | Systèmes de fichiers partagés, CMS, containers | Oui — multi-AZ natif |
| Amazon FSx | Fichier (SMB/Lustre) | Monté selon le protocole (Windows ou Linux HPC) | Environnements Windows, calcul haute performance | Oui — multi-AZ selon config |
1. Amazon EBS — Elastic Block Store
EBS est un service de stockage bloc réseau attaché à des instances EC2. Il fonctionne comme un disque dur externe — vous pouvez le détacher d’une instance et le rattacher à une autre dans la même AZ.
Caractéristiques clés
| Propriété | Détail |
| Attachement | Un volume EBS = une instance EC2 à la fois (sauf EBS Multi-Attach sur io1/io2) |
| Portée géographique | Lié à une zone de disponibilité (AZ) spécifique — ne peut pas traverser les AZ directement |
| Persistance | Les données persistent après arrêt de l’instance. Option “Delete on Termination” configurable. |
| Provisionnement | Capacité et IOPS définis à l’avance — peuvent être augmentés sans downtime |
| Facturation | Par Go provisionné/mois + par IOPS provisionnées (selon le type) |
| Performance | Dépend du type de volume — de quelques centaines à des dizaines de milliers d’IOPS |
Types de volumes EBS
| Type | Technologie | IOPS max | Débit max | Cas d’usage CLF-C02 |
| gp2 (General Purpose SSD) | SSD | 16 000 | 250 MB/s | Usage général, volumes de boot, applications standard |
| gp3 (General Purpose SSD) | SSD | 16 000 | 1 000 MB/s | Remplace gp2 — plus performant et moins cher, paramétrage indépendant IOPS/débit |
| io1 / io2 (Provisioned IOPS SSD) | SSD haute perf. | 64 000 (io1) / 256 000 (io2) | 1 000 MB/s | BDD critiques (Oracle, SQL Server, MySQL haute perf), latence sub-ms |
| st1 (Throughput Optimized HDD) | HDD | 500 | 500 MB/s | Big data, data warehouses, log processing — accès séquentiel fréquent |
| sc1 (Cold HDD) | HDD froid | 250 | 250 MB/s | Accès peu fréquent, archivage froid — coût le plus bas des volumes EBS |
| Règle examen : gp3 = volume de boot recommandé par défaut. io1/io2 = bases de données critiques haute performance. st1/sc1 = pas de volume de boot possible (HDD). gp3 remplace progressivement gp2 — même niveau mais plus flexible. |
EBS Snapshots
Un snapshot est une sauvegarde incrémentale d’un volume EBS, stockée dans Amazon S3 en arrière-plan.
| Propriété | Détail |
| Stockage | Dans Amazon S3 (géré par AWS, invisible dans votre console S3) |
| Incrémental | Seuls les blocs modifiés depuis le dernier snapshot sont sauvegardés — économique |
| Portée | Un snapshot est régional — peut être utilisé pour créer des volumes dans n’importe quelle AZ de la région |
| Transfert inter-région | Un snapshot peut être copié vers une autre région pour DR ou déploiement multi-région |
| Création pendant l’utilisation | Possible sans arrêter l’instance — arrêter garantit un snapshot cohérent |
| Restauration | Un snapshot crée un nouveau volume EBS — pas une restauration in-place |
| Tarification | Par Go de snapshot stocké/mois — économique grâce à l’incrémental |
| Mémo examen — snapshot vs AMI : Un snapshot = sauvegarde d’un volume EBS. Une AMI = image de lancement d’une instance (inclut un ou plusieurs snapshots + configuration de démarrage). Pour cloner une instance dans une autre AZ : créer un snapshot du volume EBS → créer un nouveau volume depuis le snapshot dans l’AZ cible. |
2. Instance Store — stockage local éphémère
L’Instance Store est un stockage physique directement attaché au serveur physique qui héberge l’instance EC2. Il offre des performances I/O très élevées mais ses données sont éphémères.
| Propriété | Instance Store | Amazon EBS |
| Localisation | Disque physique du serveur hôte | Stockage réseau attaché |
| Performance | Très haute (I/O directe, pas de réseau) | Élevée selon le type, via réseau |
| Persistance | Éphémère — données perdues au stop, terminate ou crash | Persistant — données conservées après stop |
| Coût | Inclus dans le prix de l’instance | Facturation séparée par Go/mois |
| Cas d’usage | Cache, buffers, fichiers temporaires, données de traitement intermédiaires | OS, bases de données, données persistantes |
| Disponibilité | Uniquement sur certains types d’instances (i3, c5d, m5d…) | Disponible sur tous les types d’instances |
| À retenir absolument : Instance Store = haute performance MAIS éphémère. Si l’instance est arrêtée (stop) ou résiliée (terminate) ou si le matériel tombe en panne → toutes les données sont perdues définitivement. Ne jamais stocker des données importantes sur un Instance Store sans réplication. |
3. Amazon EFS — Elastic File System
EFS est un système de fichiers réseau (NFS) managé par AWS, conçu pour être monté simultanément sur des centaines d’instances EC2 Linux dans plusieurs AZ.
| Propriété | Détail |
| Protocole | NFS (Network File System) — standard Linux |
| Compatibilité OS | Linux uniquement — pas compatible Windows |
| Attachement | Peut être monté simultanément sur des centaines d’instances EC2 dans différentes AZ |
| Multi-AZ | Oui — EFS réplique les données sur plusieurs AZ automatiquement |
| Scaling | Automatique — la capacité grandit et se réduit selon l’usage, pas de provisionnement manuel |
| Facturation | À l’usage réel (Go utilisé/mois) — pas de capacité à provisionner en avance |
| Coût | Environ 3x plus cher qu’un volume EBS gp2 en standard — mais pas de surprovisionnement |
| Performance | Deux modes : General Purpose (latence faible) et Max I/O (throughput élevé, latence plus haute) |
| Synchronicité | Les modifications d’un fichier sont visibles instantanément par toutes les instances connectées |
Classes de stockage EFS
| Classe | Accès | Coût relatif | Cas d’usage |
| EFS Standard | Fréquent | Référence | Données actives accédées régulièrement |
| EFS Standard-IA (Infrequent Access) | Peu fréquent | Jusqu’à 92% moins cher | Fichiers accédés rarement — politique de cycle de vie automatique |
| EFS One Zone | Fréquent — une seule AZ | 20% moins cher que Standard | Données ne nécessitant pas de haute disponibilité multi-AZ |
| EFS One Zone-IA | Peu fréquent — une seule AZ | Le moins cher | Backup, données de développement peu accédées |
| EFS Infrequent Access (IA) : Vous pouvez configurer une politique de cycle de vie EFS pour déplacer automatiquement les fichiers non accédés depuis N jours (ex : 60 jours) vers la classe EFS-IA. Les applications y accèdent de façon transparente — même API, même chemin de montage. Économies jusqu’à 92% pour les fichiers froids. |
4. Amazon FSx — systèmes de fichiers haute performance
Amazon FSx propose des systèmes de fichiers managés tiers haute performance pour des cas d’usage spécifiques que EFS ne couvre pas (Windows natif, HPC Linux).
| FSx for Windows File Server | FSx for Lustre | FSx for NetApp ONTAP | FSx for OpenZFS | |
| Protocole | SMB, NTFS | POSIX (Lustre) | NFS, SMB, iSCSI | NFS, SMB |
| OS cible | Windows (et Linux via SMB) | Linux | Linux et Windows | Linux et Windows |
| Performance | Standard à élevée | Extrême — centaines GB/s, millions IOPS, < 1ms | Haute | Haute |
| Intégration spéciale | Microsoft Active Directory | Amazon S3 (backend de données) | NetApp SnapMirror, DataOps | Snapshots ZFS natifs |
| Multi-AZ | Oui — 2 AZ | Non (Single-AZ) ou via S3 | Oui | Oui |
| Cas d’usage typique | Partage fichiers Windows, SQL Server, SharePoint, Active Directory | HPC, machine learning, simulation, traitement vidéo, modélisation financière | Migration workloads NetApp existants | Migration workloads ZFS / UNIX |
FSx for Windows File Server — détail
• Entièrement managé par AWS — pas de gestion de serveur de fichiers
• Supporte SMB et NTFS — compatible avec toutes les applications Windows nativement
• Intégration native avec Microsoft Active Directory — gestion des utilisateurs et permissions centralisée
• Peut être monté sur des instances EC2 Windows ET accessible depuis l’on-premises via VPN ou Direct Connect
• Déployé sur deux AZ pour la haute disponibilité — failover automatique
FSx for Lustre — détail
• Lustre = système de fichiers open-source conçu pour le calcul haute performance
• Débits : centaines de GB/s · Millions d’IOPS · Latence inférieure à la milliseconde
• Intégration native avec S3 : les données peuvent être lues depuis S3 à la demande et réécrits après traitement
• Idéal pour les pipelines de machine learning (lire rapidement des datasets massifs depuis S3)
5. Amazon S3 — stockage objet
Amazon S3 (Simple Storage Service) est le service de stockage objet d’AWS. Il n’est pas attaché à une instance EC2 — vous y accédez via des APIs HTTP depuis n’importe où. C’est un service fondamental du CLF-C02.
Concepts fondamentaux S3
| Concept | Description |
| Bucket | Conteneur racine dans S3 — nom unique mondialement, créé dans une région |
| Objet | Fichier stocké dans un bucket — jusqu’à 5 TB par objet |
| Clé (Key) | Chemin complet de l’objet dans le bucket (ex : photos/2026/vacances.jpg) |
| Durabilité | 99,999999999% (11 nines) — réplication multi-AZ automatique |
| Disponibilité | 99,99% (classe Standard) — varie selon la classe de stockage |
| Versioning | Conserve toutes les versions d’un objet — protection contre la suppression accidentelle |
| Accès | Via HTTPS, SDK, CLI, console AWS — pas monté comme un disque local |
| Chiffrement | Chiffrement côté serveur (SSE-S3, SSE-KMS, SSE-C) ou côté client |
Classes de stockage S3
| Classe | Disponibilité | Durée min. | Cas d’usage | Coût relatif |
| S3 Standard | 99,99% — multi-AZ | Aucune | Données actives, fréquemment accédées | Référence — le plus cher |
| S3 Standard-IA (Infrequent Access) | 99,9% — multi-AZ | 30 jours | Données peu accédées mais récupération rapide requise (DR, backups) | ~58% moins cher que Standard |
| S3 One Zone-IA | 99,5% — une seule AZ | 30 jours | Données peu accédées, reproductibles — pas de HA multi-AZ | ~80% moins cher que Standard |
| S3 Intelligent-Tiering | 99,9% — multi-AZ | Aucune | Accès imprévisible — AWS déplace automatiquement entre tiers | Petit frais de monitoring/objet |
| S3 Glacier Instant Retrieval | 99,9% — multi-AZ | 90 jours | Archives accédées rarement mais récupération en millisecondes | ~68% moins cher que Standard |
| S3 Glacier Flexible Retrieval | 99,99% — multi-AZ | 90 jours | Archives — récupération en minutes à heures (Expedited/Standard/Bulk) | ~75% moins cher que Standard |
| S3 Glacier Deep Archive | 99,99% — multi-AZ | 180 jours | Archivage long terme (7-10 ans) — récupération en 12-48h | Le moins cher (~95% moins cher) |
Fonctionnalités S3 importantes pour le CLF-C02
| Fonctionnalité | Description | Cas d’usage examen |
| S3 Lifecycle Rules | Règles automatiques pour transitionner les objets entre classes ou les supprimer après N jours | Réduire les coûts — déplacer vers Glacier après 30 jours, supprimer après 365 jours |
| S3 Versioning | Conserve toutes les versions d’un objet dans un bucket | Protection contre suppression/écrasement accidentel — activer avant de modifier |
| S3 Replication (CRR/SRR) | Cross-Region Replication ou Same-Region Replication — copie automatique des objets | DR multi-région (CRR), conformité réglementaire, réduction de latence |
| S3 Block Public Access | Paramètre au niveau compte ou bucket bloquant tout accès public | Security best practice — activer par défaut sur tous les nouveaux buckets |
| S3 Transfer Acceleration | Accélère les uploads via le réseau CloudFront Edge Network | Uploads rapides depuis des utilisateurs géographiquement éloignés |
| S3 Presigned URLs | URL temporaire et signée donnant accès limité dans le temps à un objet privé | Partager un fichier privé sans rendre le bucket public |
| S3 Event Notifications | Déclenche Lambda, SQS ou SNS lors d’événements (upload, delete…) | Traitement automatisé dès qu’un fichier arrive dans S3 |
| S3 Object Lock / WORM | Empêche la modification ou suppression d’un objet pendant une période définie | Conformité réglementaire (FINRA, SEC, HIPAA) — immuabilité des données |
| S3 vs EBS vs EFS — la règle des 3 questions : (1) Faut-il monter comme un disque sur une instance EC2 ? → EBS (une instance) ou EFS (plusieurs instances Linux). (2) Faut-il partager des fichiers entre instances Windows ? → FSx for Windows File Server. (3) Accès via API/HTTP, pas un disque → S3. S3 n’est jamais la réponse quand la question parle de disque, de volume ou de montage. |
6. Comparaison globale — EBS vs Instance Store vs EFS vs FSx vs S3
| Critère | EBS | Instance Store | EFS | FSx | S3 |
| Type | Bloc | Bloc local | Fichier NFS | Fichier SMB/Lustre | Objet |
| Attachement | 1 instance EC2 (même AZ) | 1 instance (physique) | N instances Linux (multi-AZ) | N instances Windows ou Linux | Accès API — pas d’attachement |
| OS compatible | Linux et Windows | Linux et Windows | Linux uniquement | Windows (SMB) ou Linux (Lustre) | Tous — accès HTTP |
| Persistance | Oui | Non — éphémère | Oui | Oui | Oui |
| Multi-AZ natif | Non — une AZ | Non — une instance | Oui | Oui (selon config) | Oui — standard |
| Scalabilité | Manuelle (augmenter la taille) | Fixe — dépend de l’instance | Automatique — élastique | Semi-auto selon type | Illimitée — automatique |
| Facturation | Go provisionné/mois | Inclus dans l’instance | Go utilisé/mois | Go + débit/mois | Go utilisé + requêtes |
| Coût relatif | Moyen | Inclus (économique) | Élevé (3x EBS gp2) | Élevé | Très faible pour archivage |
7. Scénarios CLF-C02 — stockage
| Scénario examen | Bonne réponse | Pourquoi |
| Volume de boot pour une instance EC2 | Amazon EBS (gp3 recommandé) | Instance Store ne peut pas être volume de boot sur la plupart des instances |
| Cache haute performance pour une application de trading — données non critiques | Instance Store | Haute performance I/O locale, données éphémères acceptables pour un cache |
| Système de fichiers partagé entre 50 instances EC2 Linux dans 3 AZ différentes | Amazon EFS | Seul EFS permet le montage multi-instances multi-AZ sur Linux |
| Partage de fichiers pour une application Windows avec Active Directory | FSx for Windows File Server | Protocole SMB + NTFS + intégration AD — EFS n’est pas compatible Windows |
| Pipeline de machine learning — lire des données depuis S3 à très haute vitesse | FSx for Lustre avec intégration S3 | Latence < 1ms, débit énorme, intégration native S3 comme backend |
| Stockage de fichiers logs — accédés fréquemment les 30 premiers jours, puis archivés | S3 Standard + S3 Lifecycle Rule vers Glacier | Transition automatique après 30 jours — S3 est prévu pour ça |
| Backup de volumes EBS dans une autre région pour le DR | Snapshot EBS → copier vers la région cible | Les snapshots peuvent être copiés inter-régions et recréer des volumes |
| Site web statique (HTML, CSS, JS, images) accessible publiquement | Amazon S3 Static Website Hosting | S3 peut héberger des sites statiques via HTTP — pas besoin d’EC2 |
| Images de produits e-commerce — accès depuis le monde entier avec faible latence | S3 + CloudFront (CDN) | CloudFront distribue le contenu S3 depuis des Edge Locations proches des utilisateurs |
| Fichiers de conformité réglementaire — immuables pendant 7 ans | S3 Object Lock (WORM) | Empêche toute modification ou suppression pendant la durée définie |
| Déplacer des fichiers EBS d’une AZ à une autre | Snapshot EBS → Nouveau volume dans l’AZ cible | Les volumes EBS sont liés à une AZ — un snapshot permet de les déplacer |
| Données rarement accédées, récupération en quelques millisecondes | S3 Glacier Instant Retrieval | Glacier avec récupération instantanée — moins cher que Standard-IA pour les archives |
| Données de sauvegarde long terme — récupération en 12 à 48h acceptable | S3 Glacier Deep Archive | Le coût le plus bas d’AWS — pour les archives que l’on consulte très rarement |
| Qui est responsable de l’OS sur une instance EC2 ? | Le client (vous) | Modèle de responsabilité partagée — l’OS et les patches relèvent du client |
| Les 3 règles d’or stockage au CLF-C02 : (1) Instance Store = performance maximale mais données perdues au stop/terminate — jamais pour des données importantes. (2) EBS = un disque pour une instance dans une AZ. EFS = un disque partagé pour N instances Linux multi-AZ. FSx = disque partagé Windows (SMB) ou HPC Linux (Lustre). S3 = stockage objet via API, pas un disque. (3) S3 Lifecycle = déplacer automatiquement vers des classes moins chères selon l’âge des données — toujours la réponse quand la question parle d’optimisation des coûts de stockage. |
| Préparez votre certification AWS Cloud PractitionerCours complet CLF-C02 en français · Vidéos · Quiz · Cas pratiques · Accès à vie Accéder au cours CLF-C02 sur LeCloudFacile.com |
Sources et références
AWS — Amazon EBS Documentation — types de volumes, snapshots, IOPS
AWS — Amazon EFS Documentation — montage, classes de stockage, cycle de vie
AWS — Amazon FSx Documentation — Windows File Server, Lustre, NetApp ONTAP
AWS — Amazon S3 Documentation — classes de stockage, lifecycle, Object Lock