Amazon SAA-C03: Stockage et cycle de vie des données — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. 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.

Classes de stockage S3 et le spectre coût/latence

Les classes de stockage S3 se situent sur un spectre qui arbitre entre la latence de récupération, la durée de stockage minimale et les frais de récupération par Go, par rapport au coût de stockage par Go. Choisir la bonne classe est le levier le plus important pour l’optimisation des coûts du stockage d’objets.

S3 Standard est la classe par défaut : une durabilité de onze 9 (99,999999999 %) sur trois AZ ou plus, une latence en millisecondes, pas de frais de récupération, et le prix par Go le plus élevé. Standard-IA et One Zone-IA réduisent le coût de stockage d’environ 40 à 50 %, mais ajoutent des frais de récupération par Go, une durée de facturation minimale de 30 jours et une taille d’objet minimale de 128 Ko (les objets plus petits sont facturés comme s’ils faisaient 128 Ko, ce qui érode les économies). One Zone-IA réduit encore le coût en stockant les données dans une seule AZ — ce qui n’est approprié que pour les copies secondaires reproductibles où la perte d’une seule AZ est tolérable.

S3 Intelligent-Tiering est le bon choix lorsque les modèles d’accès sont inconnus, imprévisibles ou changeants sur un grand corpus de données. Cette classe migre automatiquement les objets entre les niveaux d’accès fréquent, peu fréquent, archive instantané, archive et archive profonde en fonction de l’accès observé, moyennant de légers frais de surveillance par objet. Comme il n’y a pas de frais de récupération entre les niveaux d’accès fréquent et peu fréquent et aucune durée minimale, c’est le choix par défaut le plus sûr pour les data lakes et les charges de travail mixtes avec des objets ≥ 128 Ko. C’est le mauvais choix lorsque vous savez déjà que les objets sont en permanence à accès fréquent (coût de surveillance supplémentaire) ou en permanence à accès très peu fréquent pendant une décennie (Deep Archive est beaucoup moins cher).

Glacier Instant Retrieval fournit un accès en millisecondes à des prix d’archive pour les données consultées trimestriellement ou moins — images médicales, PDF de conformité qui doivent être produits immédiatement sur demande. Glacier Flexible Retrieval offre une récupération en quelques minutes à quelques heures. Glacier Deep Archive est le niveau le moins cher d’AWS, à environ 1 $/To/mois, avec une récupération standard en 12 heures (ou 48 heures en mode bulk) et un minimum de 180 jours — la bonne réponse pour la rétention réglementaire de 7 à 10 ans et le remplacement des bandes.

Les deux principaux pièges en matière de coûts sont des erreurs opposées. Sélectionner Standard pour des données à long terme rarement lues est un gaspillage d’argent, car Standard n’offre pas de réduction de prix pour le stockage à froid — un jeu de données de 5 To conservé pendant des années en Standard coûte plusieurs fois plus cher que les mêmes données en Deep Archive. Inversement, déplacer des objets tout neufs directement vers Standard-IA ou Glacier est un piège, car les frais minimaux de 30/90/180 jours, ajoutés aux frais de récupération, dépassent les économies réalisées lorsque les objets sont encore à accès fréquent. Glacier Flexible ou Deep Archive sont également totalement incompatibles avec toute charge de travail qui attend une lecture synchrone — un utilisateur attendant une requête HTTP GET ne peut tolérer un SLA de récupération de quelques minutes à 12 heures. Glacier Instant Retrieval est le seul niveau Glacier compatible avec un accès immédiat.

Politiques de cycle de vie et gestion des versions

La configuration du cycle de vie est un fichier déclaratif JSON/YAML attaché à un bucket, qui effectue la transition ou l’expiration des objets en fonction de leur âge, d’un tag ou d’un préfixe. Les transitions sont évaluées une fois par jour et ne se déclenchent qu’une fois l’âge spécifié atteint — une transition Days: 30 signifie que les tarifs Standard s’appliquent pendant les 30 premiers jours. Les transitions doivent se faire vers des niveaux progressivement plus froids, et les objets de moins de 128 Ko ne sont pas déplacés de Standard vers IA car les frais généraux par objet l’emportent sur les économies ; consolidez d’abord les petits objets via tar/zip ou S3 Batch Operations.

Voici une politique canonique pour une charge de travail avec accès fréquent pendant 30 jours, puis peu fréquent, nécessitant un accès immédiat tout au long de sa vie, conservée pendant quatre ans, avec une hygiène appropriée :

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Un piège fréquent dans la gestion des versions : sur un bucket versionné, une règle de cycle de vie qui fait expirer les objets actuels ne fait qu’insérer des marqueurs de suppression ; les versions antérieures s’accumulent silencieusement et continuent d’être facturées. Les versions non courantes nécessitent leurs propres règles explicites NoncurrentVersionTransitions et NoncurrentVersionExpiration. De même, incluez toujours AbortIncompleteMultipartUpload — les parties de chargements partitionnés (multipart) orphelines sont invisibles dans la liste de la console et consomment du stockage indéfiniment.

Pour les modèles d’accès mixtes — par exemple, de la télémétrie IoT avec un accès fréquent pour l’entraînement ML le premier mois, puis interrogée trimestriellement pendant un an, puis archivée — la bonne réponse est Intelligent-Tiering pour la première année (laissant la classe s’auto-optimiser entre les pics d’entraînement et les jours d’inactivité), suivie d’une transition planifiée vers Deep Archive au 365e jour.

Gestion des versions, MFA Delete et Verrouillage d’objet

Une fois activée, la gestion des versions ne peut être que suspendue ; elle ne peut pas être désactivée. Chaque opération PUT crée un nouvel ID de version ; DELETE insère un marqueur de suppression au lieu de supprimer les données. La gestion des versions protège contre l’écrasement accidentel mais n’est pas l’immuabilité : tout principal disposant de s3:DeleteObjectVersion peut supprimer définitivement une version spécifique. MFA Delete ajoute une exigence selon laquelle le compte racine doit présenter un jeton MFA pour supprimer définitivement des versions ou modifier l’état de la gestion des versions — comblant ainsi la lacune de la suppression accidentelle pour les buckets de grande valeur, mais n’empêchant toujours pas un acteur autorisé de détruire les données.

La véritable immuabilité nécessite S3 Object Lock, qui requiert la gestion des versions et doit généralement être activé lors de la création du bucket. Il dispose de deux modes qui sont fréquemment confondus :

La rétention peut être appliquée par objet (Retain-Until-Date) ou via une Conservation légale (Legal Hold), qui n’a pas de date d’expiration. Pour des archives comptables nécessitant un an en accès « chaud », neuf ans en archivage, et aucune suppression pendant dix ans, le modèle correct est S3 Object Lock en mode Conformité avec une rétention de dix ans, combiné à une transition de cycle de vie vers Deep Archive au 365e jour. Le mode Gouvernance n’est pas un substitut acceptable à une obligation légale — un régulateur n’acceptera pas « quelqu’un avec les permissions aurait pu supprimer ceci » comme preuve d’immuabilité.

Pour appliquer la rétention à un corpus existant de PDF en une seule tâche, utilisez S3 Batch Operations piloté par un manifeste S3 Inventory. S3 Batch Operations est la solution gérée pour les mutations à grande échelle — rétention, balisage, ré-chiffrement par copie-PUT, invocation de Lambda — sur des milliards de clés ; les scripts d’itération écrits à la main ne sont pas le bon modèle.

Chiffrement : SSE-S3, SSE-KMS et Clés de compartiment (Bucket Keys)

Chaque bucket a un chiffrement par défaut. SSE-S3 (AES-256, clés gérées par S3) est gratuit et ne nécessite aucune administration de clés. SSE-KMS utilise une clé maîtresse client (CMK) KMS, permettant des pistes d’audit CloudTrail par clé, des politiques d’accès aux clés basées sur IAM et le contrôle de la rotation des clés — au prix de frais d’API KMS et, plus important encore, d’une limitation des requêtes KMS qui peut étrangler les charges de travail de lecture à haut débit. Choisissez SSE-KMS lorsque vous avez réellement besoin de ces contrôles (attestation réglementaire, séparation des tâches, partage de clés entre comptes). Opter par défaut pour SSE-KMS « par sécurité » ajoute des coûts et une complexité inutiles lorsque SSE-S3 répond à l’exigence.

Les Clés de compartiment S3 (S3 Bucket Keys) répondent au problème du coût des requêtes SSE-KMS. S3 génère une clé éphémère au niveau du bucket à partir de la CMK et dérive localement les clés de données par objet, évitant ainsi un appel KMS GenerateDataKey/Decrypt par objet et réduisant les coûts des requêtes KMS jusqu’à 99 % :

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Passer à SSE-S3 pour « éviter les coûts KMS » est la mauvaise solution de contournement lorsque l’exigence impose KMS — les Clés de compartiment (Bucket Keys) satisfont à la fois les objectifs de conformité et de coût sans abandonner KMS.

L’activation du chiffrement par défaut du bucket garantit que tous les téléversements futurs sont chiffrés (les PUT non chiffrés sont chiffrés de manière transparente). Pour rejeter purement et simplement les PUT non chiffrés, refusez les écritures ne contenant pas l’en-tête :

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Le chiffrement par défaut n’a aucun effet sur les objets non chiffrés existants. Ré-chiffrez-les via S3 Inventory + S3 Batch Operations en exécutant une tâche de Copy qui écrase chaque clé sur place — le modèle standard de ré-chiffrement en masse.

Le chiffrement côté client ad-hoc est inférieur au chiffrement par défaut plus KMS : il disperse la gestion des clés entre les équipes applicatives, ne peut pas être audité de manière centralisée via les événements CloudTrail KMS et ne peut pas utiliser les Clés de compartiment (Bucket Keys).

Réplication inter-régions et Clés KMS multi-régions

La Réplication inter-régions (CRR) copie de manière asynchrone les objets vers un bucket dans une Région différente pour des raisons de conformité, de reprise après sinistre (DR) ou de latence. La Réplication dans la même région (SRR) sert à la séparation pour la conformité, à l’agrégation de journaux et aux copies inter-comptes. Les deux nécessitent l’activation de la gestion des versions sur la source et la destination, ainsi qu’un rôle IAM que le bucket source assume. La CRR est la solution à faible effort chaque fois qu’un bucket doit être répliqué dans une autre Région — scripter aws s3 sync, connecter des Lambdas sur ObjectCreated, ou exécuter des copies par lots planifiées introduit une surcharge opérationnelle, des conditions de concurrence et des échecs silencieux. Ni la CRR ni la SRR ne répliquent les objets existants par défaut ; utilisez S3 Batch Replication pour les rattrapages (backfills).

Les interactions avec le chiffrement sont un point où les conceptions échouent souvent :

• Les objets SSE-S3 se répliquent de manière transparente.
• Les objets SSE-KMS ne sont pas répliqués par défaut — vous devez l’activer explicitement, spécifier une clé KMS de destination dans la Région de destination, et accorder au rôle de réplication les permissions kms:Decrypt sur la clé source et kms:Encrypt sur la clé de destination. Une clé mono-région ne peut pas chiffrer des objets dans une autre Région.
• Les objets chiffrés côté client se répliquent en tant que texte chiffré opaque ; la Région de destination n’y gagne rien à moins que le matériel de clé du client y soit disponible.

La friction historique liée à la gestion de deux CMK indépendantes est résolue par les clés multi-régions AWS KMS, qui présentent le même matériel de clé et le même ID de clé (avec un préfixe de Région) dans plusieurs Régions. Un objet répliqué peut alors être déchiffré dans la Région de destination sans appels KMS inter-régions et sans ré-encapsuler (re-wrapping) la clé de données. C’est le modèle canonique pour les buckets chiffrés et répliqués qui doivent rester utilisables en cas de basculement régional (failover).

Le partage de snapshots et d’objets entre comptes sous une clé KMS gérée par le client exige que les principaux du compte cible détiennent les permissions kms:Decrypt, kms:CreateGrant, kms:DescribeKey et kms:ReEncrypt* sur la clé source via la politique de clé, en plus des permissions IAM correspondantes. Les clés gérées par AWS (par ex., aws/ebs, aws/s3) ne peuvent pas être partagées entre les comptes, donc les clés gérées par le client sont obligatoires pour les flux de travail inter-comptes.

Blocage de l’accès public et restriction de l’accès à CloudFront

Le Blocage de l’accès public (BPA) S3 comporte quatre paramètres — bloquer les nouvelles ACL publiques, ignorer les ACL publiques existantes, bloquer les nouvelles stratégies de compartiment publiques, restreindre les stratégies de compartiment publiques — configurables par compartiment et, plus important encore, au niveau du compte. Le BPA au niveau du compte prévaut sur toute stratégie de compartiment qui accorderait un accès public et constitue le contrôle approprié pour garantir qu’« aucun objet de ce compte ne peut être public ». Les stratégies au niveau du compartiment seules sont fragiles : un nouveau compartiment peut être lancé sans en avoir ; le BPA au niveau du compte est sécurisé par défaut.

Pour empêcher un administrateur dans un compte membre de désactiver le BPA, superposez une Politique de contrôle des services (SCP) au niveau de l’UO Organizations ou de la racine :

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Pour servir le contenu S3 uniquement via CloudFront, attachez un Contrôle d’accès à l’origine (OAC) — le remplaçant moderne de l’ancien OAI — à la distribution et conditionnez la stratégie de compartiment sur l’ARN de la distribution :

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

Le BPA reste activé sur le compartiment. Pour un accès limité dans le temps à des objets privés par un utilisateur spécifique (expiration du chargement/téléchargement), générez une URL présignée dont la signature intégrée hérite des autorisations du principal qui l’a signée.

Chemins réseau privés : Points de terminaison de type passerelle

Le trafic EC2 vers S3 au sein d’un VPC n’utilise pas automatiquement le réseau privé principal d’AWS. Sans configuration, les appels à l’API S3 sont résolus vers des points de terminaison publics et transitent par la passerelle Internet ou la passerelle NAT, ce qui entraîne des frais de traitement des données NAT et expose le trafic à Internet. Un point de terminaison de VPC de type passerelle pour S3 (et DynamoDB) est gratuit, est ajouté en tant que route de liste de préfixes dans les tables de routage spécifiées, et maintient le trafic sur le réseau AWS. Les points de terminaison d’interface (PrivateLink) pour S3 existent également et sont facturables, utiles lorsque l’accès provient d’un environnement sur site via Direct Connect. Associez le point de terminaison à une condition aws:SourceVpce dans la stratégie de compartiment pour garantir que le compartiment n’est accessible qu’à partir des points de terminaison de VPC approuvés — le modèle standard pour les charges de travail réglementées.

Object Lambda pour la transformation à la volée

S3 Object Lambda insère une fonction Lambda dans le chemin des requêtes GET/HEAD/LIST afin que l’objet retourné à l’appelant soit transformé au moment de la lecture. Cela évite de dupliquer les données pour chaque variante (anonymisée, redimensionnée, reformatée) et conserve une source de vérité unique dans le compartiment sous-jacent. Les cas d’usage typiques incluent : l’anonymisation des PII pour les analystes par opposition aux données complètes pour les auditeurs, l’ajout de filigranes aux images par utilisateur, la conversion XML vers JSON pour les clients hérités. IAM et les stratégies de compartiment contrôlent toujours l’accès à l’objet sous-jacent ; la fonction Lambda ne voit que ce que son rôle d’exécution lui permet.

Notifications d’événements

S3 émet des événements (s3:ObjectCreated:*, s3:ObjectRemoved:*, événements de réplication et de cycle de vie) vers Lambda, SQS, SNS ou EventBridge. EventBridge est à privilégier lorsque vous avez besoin de plusieurs cibles, d’un filtrage sur les métadonnées des objets ou d’un routage entre comptes ; les notifications directes sont plus simples et moins chères pour les pipelines à cible unique comme la génération de vignettes lors du chargement. Les notifications sont livrées au moins une fois, les consommateurs doivent donc être idempotents.

Optimisation du débit : Chargement partitionné et Transfer Acceleration

Pour les objets de plus de 100 Mo, le chargement partitionné est la meilleure pratique ; au-delà de 5 Go, il est obligatoire. Les parties sont chargées en parallèle, les tentatives pour les parties échouées sont indépendantes, et le débit augmente avec la simultanéité. Les requêtes GET par plage d’octets offrent un parallélisme équivalent pour les téléchargements. Comme indiqué, attachez toujours une règle de cycle de vie AbortIncompleteMultipartUpload pour éviter la facturation des parties orphelines.

S3 Transfer Acceleration achemine les chargements via le point de présence (edge) CloudFront le plus proche sur le réseau principal d’AWS — à utiliser pour les clients répartis dans le monde entier qui chargent des fichiers vers un seul compartiment. Pour les téléchargements, placez CloudFront devant S3 pour mettre en cache au niveau du point de présence. Transfer Acceleration est orienté chargement ; CloudFront est orienté téléchargement ; ils résolvent des problèmes connexes mais distincts.

EBS : Types de volumes, chiffrement et snapshots

Les volumes EBS sont des périphériques de stockage en mode bloc limités à une seule AZ (Zone de Disponibilité), attachés à une unique instance EC2. gp3 est le SSD à usage général par défaut ; son avantage crucial par rapport à gp2 est que les IOPS (jusqu’à 16 000) et le débit (jusqu’à 1 000 Mio/s) sont provisionnés indépendamment de la capacité, éliminant l’anti-pattern de gp2 qui consiste à surprovisionner le stockage juste pour atteindre les objectifs de performance. io2 Block Express fournit jusqu’à 256 000 IOPS avec une latence inférieure à la milliseconde pour les bases de données sensibles à la latence. st1 et sc1 sont basés sur des disques durs (HDD) pour les charges de travail séquentielles et froides axées sur le débit. La fonctionnalité Multi-Attach sur io1/io2 existe mais est limitée à 16 instances dans la même AZ exécutant un système de fichiers prenant en charge les clusters — une exception rare, et non un modèle général de « EBS partagé ». Tenter d’attacher un volume EBS à de multiples instances (par exemple, derrière un load balancer) est une erreur de catégorie qui produit exactement le symptôme « certains documents sont visibles après un rafraîchissement, d’autres non », car chaque volume est un périphérique de stockage en mode bloc privé.

Les volumes EBS sont chiffrés au repos avec AES-256 en utilisant des clés de données encapsulées par KMS. Le chiffrement est transparent — aucune pénalité de performance, aucune modification applicative. Une fois qu’un volume est chiffré, les snapshots et volumes qui en dérivent sont également chiffrés ; vous ne pouvez pas déchiffrer sur place. Activez le chiffrement EBS par défaut par Région pour que chaque nouveau volume et snapshot soit chiffré, quelle que soit la vigilance du développeur :

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Les volumes non chiffrés existants ne sont pas chiffrés rétroactivement — la remédiation nécessite de créer un snapshot, de le copier en activant le chiffrement, puis de créer un volume à partir du snapshot chiffré.

Les snapshots sont des sauvegardes incrémentielles au niveau des blocs, stockées sur une infrastructure gérée par S3 — mais ils ne sont pas gratuits (vous payez pour les blocs modifiés conservés), ils ne disparaissent pas lorsque le volume source est supprimé, et ils ne sont pas supprimés lorsqu’une AMI qui les référence est désenregistrée. Faites-les vieillir vers le niveau EBS Snapshots Archive (75 % moins cher, restauration en 24 à 72 heures) via aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM), ou AWS Backup. Fast Snapshot Restore (FSR) préchauffe un snapshot dans des AZ spécifiques afin que les instances lancées à partir de celui-ci délivrent immédiatement des performances maximales — activez-le pour les AMI derrière des groupes d’autoscaling qui doivent gérer une mise à l’échelle horizontale (scale-out) rapide.

La Corbeille (Recycle Bin) capture les snapshots EBS et les AMI supprimés dans une fenêtre de restauration (de 1 jour à 1 an). Sans elle, la suppression d’un snapshot est immédiate et permanente :

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

S’appuyer uniquement sur des snapshots EBS quotidiens pour la rétention à long terme à des fins de conformité est une erreur d’architecture courante — le prix des snapshots est plus proche de celui du stockage tiède (warm storage) et ils nécessitent des transitions explicites vers l’archivage.

Amazon EFS : Système de fichiers POSIX partagé pour les flottes Linux

EFS est un système de fichiers NFSv4.1 entièrement géré, élastique et compatible POSIX, montable simultanément depuis des milliers de clients EC2, ECS, EKS ou Lambda à travers plusieurs AZ dans une Région, et depuis des hôtes sur site (on-premises) via Direct Connect ou un VPN. La propriété déterminante est que le même système de fichiers, avec des descripteurs de fichiers (file handles) et une sémantique au niveau de l’octet identiques, est visible par tous les clients en même temps. EFS est donc la bonne réponse chaque fois qu’une flotte Linux derrière un load balancer doit partager un ensemble de fichiers commun — téléchargements des utilisateurs, configuration, répertoires personnels partagés.

Les cibles de montage (mount targets) résident dans chaque sous-réseau d’AZ que vous configurez. L’utilitaire amazon-efs-utils permet d’activer le chiffrement TLS en transit et l’autorisation de montage via IAM :

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Les classes de stockage EFS couvrent deux dimensions. La gestion du cycle de vie (Lifecycle management) déplace les fichiers non consultés pendant 7 à 90 jours de la classe Standard vers Infrequent Access et éventuellement vers Archive, réduisant le coût de stockage jusqu’à 92 % ; Intelligent-Tiering les ramène en arrière dès qu’ils sont consultés. Les classes One Zone stockent les données dans une seule AZ pour environ 47 % de moins — ce qui est approprié pour le dev/test ou les données reproductibles, mais jamais pour des données dont la perte lors d’une panne d’AZ est inacceptable. Une mesure d’optimisation des coûts pour une charge de travail déjà sur EFS Standard-IA consiste à passer à EFS One Zone-IA sans aucune modification applicative.

La performance a deux leviers indépendants. Mode de performance (défini à la création) : Usage général (General Purpose) offre la latence la plus faible et est adapté au service web avec beaucoup de métadonnées ; E/S max (Max I/O) est une option héritée remplacée par Elastic. Mode de débit : En rafale (Bursting) évolue avec la taille (50 Ko/s par Go de base, avec des crédits de rafale en dessous de la ligne de base), Provisionné (Provisioned) paie pour un débit fixe en Mo/s indépendant de la taille, et Élastique (Elastic) — le mode par défaut actuel — s’adapte automatiquement jusqu’à plus de 10 Go/s sans planification de capacité. Un petit système de fichiers sous une charge soutenue peut épuiser ses crédits de rafale et être limité à un débit de base faible, donc les charges de travail à fortes E/S avec une faible empreinte de stockage doivent utiliser le mode Élastique ou Provisionné.

EFS ne remplace pas le stockage en mode bloc à IOPS élevées. Chaque E/S EFS est un appel de procédure à distance (RPC) NFS sur le réseau, donc les charges de travail de type journal de transactions, à enregistreur unique et à latence inférieure à la milliseconde, doivent être sur EBS io2 Block Express — un seul volume fournit 256 000 IOPS avec une latence inférieure à la milliseconde, ce que EFS ne peut égaler par opération. EFS est également excessivement cher pour les données froides par rapport à Deep Archive ; conserver des données de conformité sur EFS « parce que c’est facile » est indéfendable.

FSx : Windows, Lustre, ONTAP, OpenZFS

FSx est une famille de systèmes de fichiers gérés, sélectionnés en fonction du protocole et de la charge de travail :

FSx for Windows File Server fournit un support natif SMB 2.0/3.1.1 avec les ACLs NTFS, les espaces de noms DFS (DFS Namespaces), les clichés instantanés (shadow copies) et Kerberos sur Active Directory. Le déploiement Multi-AZ déploie un serveur de fichiers actif dans une AZ avec un serveur de secours répliqué de manière synchrone dans une autre, et un nom DNS unique pour le basculement. L’intégration AD n’est pas optionnelle : FSx doit joindre un AWS Managed Microsoft AD ou un AD autogéré accessible, et les clients s’authentifient en tant qu’utilisateurs de domaine par rapport aux SID du domaine. Ignorer l’AD, ou pointer les clients vers un système de fichiers dans une forêt non approuvée sans une relation d’approbation inter-forêts, produit le symptôme classique de l’accès refusé malgré la visibilité du partage. FSx for Windows est la cible de remplacement direct (drop-in) pour le lift-and-shift des partages de fichiers Windows.

FSx for Lustre est un système de fichiers POSIX parallèle pour le HPC, l’entraînement ML, l’EDA et la génomique — des milliers de clients, un débit de plusieurs centaines de Go/s, des métadonnées en dessous de la milliseconde. Sa fonctionnalité AWS essentielle est l’association de référentiel de données (data repository association) avec S3 : les clés d’objet apparaissent comme des fichiers dans l’espace de noms Lustre et sont chargées paresseusement au premier accès (ou préchargées via

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

) ; les fichiers nouveaux/modifiés sont réexportés vers S3 de manière planifiée ou à la demande. Le modèle HPC canonique est le suivant :

1. Copier les jeux de données sur site (on-prem) vers S3 (via DataSync ou Storage Gateway).
2. Créer un système de fichiers Lustre lié à ce bucket.
3. Le monter sur tous les workers Spot ; lire les entrées, écrire les sorties à la vitesse maximale (line rate).
4. Exporter les résultats vers S3, qui reste le référentiel durable à long terme.
5. Supprimer le système de fichiers Lustre à la fin de la tâche.

Les déploiements Lustre de type Scratch n’ont pas de réplication et perdent les données en cas de défaillance matérielle — c’est la solution la moins chère et la plus rapide, appropriée pour les données de tâches transitoires. Les déploiements de type Persistent se répliquent au sein d’une AZ pour une durabilité plus élevée. Le débit est provisionné en Mo/s par Tio (50/125/250/500/1000), ce qui découple la capacité de la performance.

FSx for NetApp ONTAP est la réponse multi-protocole : NFS, SMB et iSCSI simultanément sur les mêmes données, avec des snapshots, la réplication SnapMirror, les FlexClones et la déduplication. Choisissez ONTAP lors de la consolidation de partages mixtes Linux NFS et Windows SMB nécessitant un accès multi-protocole avec une redondance Multi-AZ, ou lors d’une migration depuis une solution NetApp sur site. FSx for OpenZFS comble une niche pour les charges de travail Linux nécessitant des fonctionnalités ZFS (snapshots, clones) sur NFS. Ne confondez pas la force multi-protocole d’ONTAP avec les autres variantes.

Faire le mauvais choix mène à un échec prévisible : EBS pour une charge de travail partagée, EFS pour un partage SMB Windows, ou Lustre pour un partage Windows intégré à AD sont tous des choix inadaptés — faites correspondre d’abord le protocole et le modèle d’accès.

Storage Gateway : Accès Hybride

Storage Gateway présente le stockage cloud comme s’il était local. Ceci est différent de DataSync, qui déplace les données.

Pour une application de rendu qui a déplacé sa médiathèque vers S3 mais qui a toujours besoin de lectures à faible latence sur site, S3 File Gateway est la solution idéale — accès NFS/SMB, cache local, objets froids récupérés de S3 à la demande. FSx File Gateway est la réponse pour les agences distantes : un cache SMB à la vitesse du réseau local d’un partage FSx cloud central, et non une solution pour l’accès partagé entre des instances EC2 (qui devraient monter FSx directement). Volume Gateway s’applique lorsque la charge de travail utilise le protocole bloc iSCSI plutôt qu’une sémantique de fichier. Tape Gateway remplace les bibliothèques de bandes physiques sous les logiciels de sauvegarde existants.

Transfert et Migration de Données

AWS DataSync est un service de migration en ligne basé sur un agent pour NFS, SMB, HDFS et les stockages objet vers S3, EFS ou FSx — jusqu’à 10 fois plus rapide que les outils open-source, avec chiffrement, vérification de l’intégrité, planification et préservation des métadonnées POSIX et des ACLs NTFS. Pour une migration SMB à grande échelle avec des millions de petits fichiers et des hiérarchies profondes, la réponse avec le moins de surcharge est DataSync vers FSx for Windows : le protocole SMB est préservé, les ACLs/horodatages sont intacts, le débit pour les petits fichiers est géré par des transferts parallèles, sans modification des applications. Migrer un tel jeu de données directement dans S3 est un piège — le stockage objet gère mal le listage de petits fichiers dans des préfixes profonds et les clients SMB ne peuvent pas monter les buckets.

AWS Snow Family fournit des appareils physiques pour le transfert hors ligne : Snowcone (jusqu’à 8 To, renforcé pour l’edge), Snowball Edge (jusqu’à ~80 To utilisables, avec des options de calcul), et Snowmobile (à l’échelle de l’exaoctet). Règle générale : si le transfert réseau prend plus d’une semaine, Snowball est moins cher et plus rapide.

AWS Transfer Family expose les protocoles SFTP, FTPS, FTP et AS2, adossés à S3 ou EFS — c’est la bonne réponse lorsque des partenaires externes doivent continuer à utiliser des protocoles de transfert de fichiers standards.

AWS Backup, copie inter-régionale et Vault Lock

AWS Backup centralise les politiques pour EBS, EFS, FSx, RDS, DynamoDB, S3, et plus encore. Un plan de sauvegarde (backup plan) définit la planification, la durée de conservation à chaud, la transition vers le stockage à froid, et les actions de copie inter-régionale/inter-comptes :

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

La transition vers le stockage à froid nécessite au moins 90 jours de conservation à chaud plus au moins 90 jours en stockage à froid ; les cycles de vie mal configurés sont rejetés. Pour une véritable conservation réglementaire sur plusieurs années, associez-le à AWS Backup Vault Lock (WORM), qui empêche même les administrateurs de raccourcir la durée de conservation, satisfaisant ainsi à la norme SEC 17a-4 et à des mandats similaires. La copie inter-régionale répond aux besoins de reprise après sinistre (DR) régionale ; la copie inter-comptes répond aux scénarios de rançongiciels (ransomware) et de menaces internes en isolant les sauvegardes du rayon d’impact (blast radius) du compte de production.

Aide-mémoire de sélection

← Architectures Serverless et événementielles · Tous les domaines · Transfert et migration de données →

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

Parcourir Amazon →