Amazon SOA-C02: Stockage et gestion des données — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Le stockage et la gestion des données couvrent la conception, l’exploitation et l’optimisation du stockage objet, bloc et fichier dans AWS pour répondre aux exigences de disponibilité, de coût et de performance. Cela inclut les politiques de cycle de vie, le chiffrement et les contrôles d’accès, les stratégies de sauvegarde/snapshot, et la sélection des classes de stockage ou des systèmes de fichiers appropriés en fonction des modèles d’accès. L’importance opérationnelle réside dans le contrôle des coûts, la garantie de la capacité de restauration et le respect des SLA de performance tout en appliquant la sécurité et la conformité.

Cycle de vie des objets S3, gestion des versions et classes de stockage

S3 est un service de stockage objet doté d’un riche ensemble de classes de stockage (STANDARD, INTELLIGENT_TIERING, STANDARD_IA, ONEZONE_IA, GLACIER_INSTANT_RETRIEVAL, GLACIER_FLEXIBLE_RETRIEVAL, DEEP_ARCHIVE) optimisées pour différentes fréquences d’accès, latences de récupération et niveaux de résilience. Choisissez les classes en fonction du modèle d’accès (fréquent ou peu fréquent), du temps de récupération requis et de la durabilité inter-AZ. Utilisez des règles de cycle de vie (via la console ou

undefined

) pour faire transiter les objets automatiquement ; basez les transitions sur l’âge de l’objet, ses balises ou son préfixe. Intelligent-Tiering élimine les incertitudes pour les modèles d’accès inconnus ou changeants, mais entraîne des frais de surveillance ; Standard-IA offre un coût de stockage inférieur, mais implique des frais de récupération par Go et une durée de stockage minimale.

La gestion des versions doit être activée pour les compartiments critiques (

undefined

). Avec la gestion des versions, vous pouvez conserver l’historique des objets, récupérer des suppressions accidentelles et tirer parti de S3 Object Lock (modes gouvernance/conformité) et de MFA Delete pour une protection plus stricte. Les règles de cycle de vie peuvent faire expirer les versions non courantes ou nettoyer les marqueurs de suppression ; testez les règles de cycle de vie sur un compartiment de préproduction pour éviter les suppressions involontaires. Pour les contrôles d’accès, combinez les politiques de compartiment, les politiques IAM et S3 Block Public Access ; préférez SSE-KMS pour l’auditabilité (SSE-KMS utilise des clés CMK de KMS et produit des journaux CloudTrail sur l’utilisation des clés) ou SSE-S3 lorsque vous avez besoin d’un chiffrement simple côté serveur sans KMS.

Volumes EBS, gestion des snapshots et performance

EBS est un service de stockage bloc attaché aux instances EC2 qui fournit des types de volumes ciblés pour le coût et la performance : gp3/gp2 (SSD à usage général), io1/io2 (SSD à IOPS provisionnés), st1/sc1 (HDD optimisé pour le débit / HDD à froid). Sélectionnez gp3 pour découpler les IOPS et le débit de la taille (utilisez

undefined

pour définir les IOPS/le débit). Surveillez les métriques CloudWatch VolumeReadOps, VolumeWriteOps, VolumeThroughput et VolumeQueueLength pour détecter la saturation ; utilisez des instances optimisées pour EBS et les pilotes ENA appropriés pour un débit/des IOPS élevés.

Les snapshots sont incrémentiels : le premier snapshot copie tous les blocs, les snapshots suivants ne stockent que les blocs modifiés, mais les coûts des snapshots peuvent augmenter si de nombreux blocs modifiés s’accumulent ou si vous conservez de nombreuses générations. Gérez le cycle de vie avec Data Lifecycle Manager (DLM) ou AWS Backup pour planifier, conserver et copier les snapshots entre les régions. Utilisez

undefined

pour les snapshots ponctuels ; restaurez avec create-volume à partir d’un snapshot. N’oubliez pas que les snapshots capturent l’état du périphérique de bloc du point de vue de l’hôte — gelez les systèmes de fichiers (fsfreeze ou utilisez des agents assurant la cohérence applicative) pour la cohérence des bases de données ou utilisez des snapshots intégrés à des outils de sauvegarde.

Systèmes de fichiers : opérations EFS et FSx

EFS fournit un service NFSv4 géré (ou NFSv4.1/4.2) pour les charges de travail Linux, offrant une capacité élastique, plusieurs modes de débit (en rafale ou provisionné) et une gestion du cycle de vie pour déplacer les fichiers vers EFS Infrequent Access. Configurez des cibles de montage par zone de disponibilité, des règles de groupe de sécurité pour NFS (TCP 2049), et activez le chiffrement au repos avec KMS et le chiffrement en transit (TLS). Utilisez les modes de performance (General Purpose ou Max I/O) en fonction des besoins en latence et en débit de métadonnées, et provisionnez le débit pour les charges de travail nécessitant un débit élevé et constant (

undefined

FSx propose SMB (FSx for Windows File Server) et Lustre (FSx for Lustre) avec des sémantiques différentes : FSx for Windows s’intègre à AD pour SMB et prend en charge les ACL Windows, les espaces de noms DFS et les sauvegardes ; FSx for Lustre cible le HPC (calcul haute performance) et peut être lié à S3 pour une intégration avec un référentiel de données. Configurez des sauvegardes quotidiennes automatisées, définissez la capacité de débit et sélectionnez SSD ou HDD selon les besoins. Suivez les étapes de configuration d’Active Directory et montez via SMB (\fsx-dns\share) pour les clients Windows ou les clients SMB Linux avec cifs-utils.

Hiérarchisation du stockage, politiques de cycle de vie et archivage

La hiérarchisation (tiering) réduit les coûts en déplaçant les données tout au long d’un cycle de vie : chaud -> tiède -> froid -> archive. Mettez en œuvre la hiérarchisation via les règles de cycle de vie S3 et les politiques de cycle de vie EFS, et utilisez des outils de migration automatique (Intelligent-Tiering, EFS IA). Pour l’archivage à long terme, choisissez les classes Glacier en fonction des SLA de récupération : Instant Retrieval pour un accès rapide et fréquent, Flexible Retrieval pour les restaurations en masse standard, Deep Archive pour le coût le plus bas et des fenêtres de restauration de plusieurs heures. Pour EBS, exportez les snapshots vers une archive compatible S3 Glacier en utilisant Backup Vault Lock avec des copies inter-régions pour optimiser les coûts.

Lors de la conception des politiques, tenez compte des durées de stockage minimales, des frais de récupération et de suppression anticipée, et des modèles d’accès. Pour la conformité, combinez S3 Object Lock (modes gouvernance/conformité) avec des transitions de cycle de vie configurées pour n’expirer qu’après la période de rétention. Testez périodiquement les procédures de restauration (effectuez une restauration depuis Glacier Flexible Retrieval/Deep Archive pour valider le temps, le coût et les étapes opérationnelles) et automatisez les restaurations lorsque c’est possible en utilisant des scripts batch AWS CLI ou une orchestration Lambda.

Durabilité, cohérence et modèles d’accès des données

Les choix en matière de durabilité et de cohérence façonnent l’architecture : S3 offre une durabilité élevée (11 neufs) et une cohérence forte en lecture après écriture pour les opérations PUT/DELETE ; EBS fournit une durabilité sur une seule AZ pour les volumes, avec des snapshots stockés dans S3 pour la durabilité et des copies inter-régions pour la reprise après sinistre (DR) ; EFS offre une cohérence forte pour les clients simultanés. Sélectionnez le type de stockage en fonction du modèle d’accès :

Objet (S3) : idéal pour les données immuables ou en ajout seul à grande échelle, les ressources web, les grands ensembles de données, les zones d’atterrissage (landing zones) pour l’analytique.
Bloc (EBS) : idéal pour les systèmes d’exploitation et les bases de données nécessitant des lectures/écritures aléatoires à faible latence et une sémantique à rédacteur unique.
Fichier (EFS/FSx) : idéal pour les charges de travail de fichiers partagés, les répertoires personnels ou les applications Windows SMB nécessitant une sémantique POSIX/ACL.

Concevez pour la localité en lecture/écriture, envisagez des couches de mise en cache (Amazon ElastiCache, Amazon CloudFront pour les objets S3), et utilisez le cycle de vie et la hiérarchisation (tiering) pour aligner les coûts sur la fréquence d’accès. Chiffrez les données au repos et en transit (SSE-S3/SSE-KMS ou côté client, chiffrement EBS avec KMS, clés KMS pour EFS, et chiffrement SMB/SMB3 pour FSx), et appliquez le principe de moindre privilège en utilisant IAM, les politiques de bucket et les points de terminaison VPC pour un accès privé.

Pièges courants et critères de décision

Ne pas activer le versionnement S3 pour les données critiques : activez le versionnement et appliquez optionnellement S3 Object Lock pour une rétention immuable ; utilisez des règles de cycle de vie pour expirer les versions non courantes afin de maîtriser les coûts.
Coûts de snapshot et de stockage inattendus : planifiez l’élagage des snapshots avec DLM/AWS Backup, surveillez la consommation de stockage des snapshots, et souvenez-vous que les snapshots sont incrémentiels mais peuvent toujours référencer de nombreux blocs — supprimez les snapshots inutiles et ne copiez que les snapshots nécessaires entre les régions.
Choisir la mauvaise classe de stockage pour les modèles d’accès : utilisez Intelligent-Tiering pour les modèles inconnus, ou analysez les journaux d’accès et utilisez des règles de cycle de vie ; évitez les classes profondes de Glacier pour les objets fréquemment consultés.
Supposer que les snapshots EBS sont des sauvegardes instantanées et cohérentes au niveau applicatif : mettez en sommeil (quiesce) les systèmes de fichiers ou utilisez des sauvegardes prenant en compte l’application pour les bases de données ; utilisez AWS Backup pour capturer des snapshots cohérents au niveau applicatif lorsque cela est pris en charge.
Manque de contrôles d’accès aux clés de chiffrement : lors de l’utilisation de SSE-KMS, assurez-vous que les politiques IAM et de clé KMS autorisent les utilisateurs et services prévus ; effectuez la rotation des clés et surveillez l’utilisation de KMS dans CloudTrail.
Négliger les limites de débit/IOPS : provisionnez le débit/les IOPS pour io1/io2 ou gp3 selon les besoins, sélectionnez le mode de performance EFS approprié, et choisissez la capacité de débit de FSx pour éviter les goulots d’étranglement à l’exécution.

Problème pratique : Scénario d’utilisation

DataCorp Analytics stocke des exports de transactions de fin de mois dans S3 et des résultats traités nocturnement sur des instances EC2 adossées à EBS. Ils font face à des coûts de stockage croissants, des écrasements accidentels et des restaurations lentes à partir des données archivées.

Activer le versionnement S3 sur le bucket et définir Object Lock pour la rétention sur les ensembles de données réglementés ; ajouter des règles de cycle de vie pour faire passer les objets plus anciens vers Intelligent-Tiering, puis vers Glacier Flexible Retrieval après un certain âge.
Analyser les journaux d’accès S3 et les métriques CloudWatch sur une période de 30 jours ; ne déplacer les objets réellement froids vers Glacier Deep Archive qu’après avoir confirmé un faible accès.
Mettre en œuvre des politiques DLM/AWS Backup pour les volumes EBS avec des snapshots complets hebdomadaires et une politique de rétention ; mettre en sommeil les bases de données avant les snapshots et copier les snapshots critiques vers une autre région pour la reprise après sinistre (DR).
Introduire Intelligent-Tiering pour les données à modèle d’accès inconnu et utiliser des balises d’allocation des coûts pour suivre le coût par environnement ; automatiser les alertes en cas de croissance inattendue du stockage.
Valider les procédures de restauration trimestriellement en restaurant des exemples de données de Glacier et de snapshots pour s’assurer que les attentes en matière de temps de récupération et de coût sont respectées.

Justification : Cette approche fait correspondre la classe de stockage et le cycle de vie des snapshots aux modèles d’accès observés, assure la récupérabilité grâce au versionnement et à des restaurations testées, et utilise des outils automatisés de cycle de vie et de sauvegarde pour maîtriser les coûts tout en répondant aux besoins de durabilité et de conformité.

← Réseaux et diffusion de contenu · Tous les domaines · Calcul et Auto Scaling →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →