AWS Storage Extras

AWS Snowball

1. Famille AWS Snowball : Le défi des données massives et isolées

Le besoin global

Imagine que tu as 100 To de données sur site (On-Premise) à transférer vers AWS. Avec une très bonne connexion internet dédiée de 100 Mbps, cela prendrait environ 100 jours en continu, sans compter la saturation du réseau.

Les variantes de Snowball

Snowball n'est pas juste une grosse clé USB, c'est une valise ultra-sécurisée et durcie qui se décline en deux versions selon le besoin :

2. Snowball vers Amazon S3 Glacier

Le besoin & Le contexte

Tu veux archiver des années de sauvegardes physiques (bandes magnétiques) vers la solution la moins chère d'AWS (Glacier), mais tu ne peux pas les uploader par internet.

⚠️ Point clé pour l'examen : Tu ne peux pas envoyer un Snowball directement dans un coffre-fort Glacier. Le flux physique impose une étape intermédiaire.

Le workflow exact

  1. Les données du Snowball sont déchargées par AWS dans un bucket Amazon S3 Standard (ou S3 Standard-IA).

  2. Tu configures une S3 Lifecycle Policy (Politique de cycle de vie) sur ce bucket.

  3. Cette politique va automatiquement et immédiatement (par exemple, après 0 jour) migrer (transférer) les données de S3 vers Amazon S3 Glacier Flexible or Deep Archive.

CheatSheet

Source : https://www.awsgeek.com/AWS-Snow-Family/

image.png

AWS FSx

AWS FSx : Les systèmes de fichiers partagés hautes performances

Le besoin global

Amazon EFS est excellent, mais il ne gère que le protocole POSIX (Linux). Amazon S3 n'est pas un système de fichiers (c'est du stockage objet).

Est-ce que AWS FSx permet de délocaliser mon système de fichier vers S3 ?

Non ! Quand tu crées un système AWS FSx (que ce soit pour Windows, Lustre, ONTAP ou OpenZFS), AWS provisionne des serveurs de stockage dédiés (généralement des disques SSD ou HDD ultra-rapides) cachés derrière le service.

La confusion vient souvent de FSx for Lustre, qui possède une fonctionnalité unique de liaison avec S3 :

A) FSx for Windows File Server
B) FSx for Lustre

Quand tu crées du FSx for Lustre, tu dois choisir entre ces deux modes :

Caractéristique Scratch File System (Stockage temporaire) Persistent File System (Stockage long terme)
Le Besoin Coût minimal pour du calcul brut à court terme. Données hautement disponibles qui doivent durer dans le temps.
Le Contexte Tu lances un calcul de 4 heures pour du Machine Learning. Si un serveur crash, tu relances le job, ce n'est pas grave. Tu as un pipeline de données sensible qui tourne en continu sur plusieurs semaines ou mois.
Comportement Pas de réplication. Si le matériel lâche, les données non sauvegardées sur S3 sont perdues. Réplication automatique au sein de la même Zone de Disponibilité (AZ). Remplacement automatique en cas de panne.
C) FSx for NetApp ONTAP
D) FSx for OpenZFS

Exemples

Scénario 1 : Le Cloud 100% Natif (Partage de fichiers entre VMs)

C'est le cas d'usage le plus classique. Tu as migré tes applications sur AWS, elles tournent sur des instances EC2, et elles ont besoin d'accéder en même temps aux mêmes fichiers.

Scénario 2 : Le "Lift-and-Shift" (Migration d'applications d'entreprise)

Tu as une application lourde dans ton centre de données local et ton patron te dit : "On déménage tout dans le cloud ce week-end, mais on n'a pas le temps de réécrire le code".

Scénario 3 : L'Hybride (Extension du On-Premise)

C'est le scénario où tes serveurs restent en local, mais tu utilises la puissance d'AWS.

AWS Storage Gateway

Le besoin global

Ton entreprise possède des serveurs locaux (On-Premise) qui manquent d'espace disque, ou tu veux sauvegarder tes données locales dans le cloud de manière transparente, sans que tes applications locales ne s'en rendent compte. Tu veux une extension de ton centre de données dans AWS.

Le contexte architectural

C'est le service phare du Cloud Hybride. Pour l'utiliser, tu as obligatoirement besoin d'installer une VM (sur VMware ESXi, Microsoft Hyper-V ou KVM) directement dans ton centre de données local. C'est cette VM (l'appliance Storage Gateway) qui va faire office de traducteur entre tes protocoles locaux et les API d'AWS.

AWS décline cette passerelle en 3 modes selon le type de stockage (Fichier, Bloc, ou Objet) :

A) S3 File Gateway (Mode Fichier)

image.png

B) Volume Gateway (Mode Bloc - iSCSI)

image.png

C) Tape Gateway (Mode Sauvegarde - VTL)

AWS Transfer Family : La porte d'entrée protocoles historiques

Introduction

Le besoin

Tu as des clients, des partenaires ou des applications externes qui doivent t'envoyer des fichiers (ex: des rapports financiers tous les soirs), mais ils refusent d'installer l'AWS CLI ou d'utiliser des clés d'API AWS. Ils veulent utiliser des protocoles standards et sécurisés de transfert de fichiers.

Le contexte (SAA-C03)

Exemple

🏢 Le Scénario : L'intégration des factures fournisseurs

Tu es architecte cloud pour une grande chaîne de supermarchés. Tous les soirs, 150 fournisseurs différents (qui ont des systèmes informatiques anciens) doivent t'envoyer leur catalogue de prix et leurs factures sous forme de fichiers CSV ou XML.

🛠️ Comment ça se passe en pratique (Étape par Étape)

Voici comment tu configures et comment fonctionne AWS Transfer Family pour répondre à ce besoin :

Étape 1 : La création du point d'accès (Endpoint)

Dans la console AWS, tu lances le service AWS Transfer Family et tu crées un serveur en quelques clics :

  1. Tu sélectionnes le protocole : SFTP.

  2. Tu choisis l'hébergement : Service managed (AWS gère l'infrastructure, la haute disponibilité et le scaling à ta place, c'est du Serverless).

  3. Tu lui associes une adresse publique (ex: sftp.mon-supermarche.com).

Étape 2 : La gestion des utilisateurs (Fournisseurs)

Tu crées un accès pour ton premier fournisseur, par exemple "Fournisseur_Alpha" :

Étape 3 : Le flux de données en direct

Le soir venu, le script automatisé du fournisseur s'exécute :

  1. Le serveur du fournisseur se connecte via son client SFTP standard (comme FileZilla ou un script WinSCP) à sftp.mon-supermarche.com.

  2. Il transfère le fichier facture_04_06_2026.csv.

  3. Côté AWS : Le service Transfer Family reçoit le flux SFTP "à la volée", traduit le protocole en requêtes HTTPS sécurisées pour S3, et écrit le fichier directement dans ton bucket.

  4. Le fournisseur reçoit un message "Transfert réussi" de la part de son client SFTP.

💡 Le gros avantage : Pour le fournisseur, il s'est connecté à un serveur de fichiers Linux classique. En réalité, il n'y a aucun serveur Linux à gérer pour toi, pas de disque dur à vider, pas de patch de sécurité à installer. Tout va directement dans le stockage illimité de S3.

AWS DataSync : L'accélérateur de migration de données

Introduction

Le besoin

Tu as des millions de fichiers (des téraoctets ou pétaoctets) en local et tu veux les migrer massivement et rapidement vers AWS, ou mettre en place une synchronisation régulière (ex: toutes les nuits).

Le contexte & Fonctionnement

DataSync est un outil de transfert de données à grande vitesse, optimisé pour saturer proprement ta bande passante réseau et aller 10 fois plus vite que des outils classiques (comme rsync ou un simple script de copie).

Exemple

🏢 Le Scénario : La sauvegarde et migration d'un studio d'animation 3D

Tu es l'architecte cloud d'un studio de cinéma d'animation. Vos graphistes travaillent en local sur des serveurs de stockage ultra-rapides (des NAS de marque NetApp ou des serveurs de fichiers Linux Windows). Chaque nuit, les artistes génèrent 20 To de nouvelles images et vidéos haute définition (des millions de petits fichiers de rendu).

🛠️ Comment ça se passe en pratique (Étape par Étape)

Voici comment tu mets en place AWS DataSync pour automatiser cela :

Étape 1 : Installer l'Agent en local

Dans ton centre de données, tu télécharges l'Agent DataSync fourni par AWS sous forme de machine virtuelle (VM) et tu l'installes sur tes serveurs (VMware ou Hyper-V).

Étape 2 : Configurer la "Tâche" (Task) dans AWS

Dans la console AWS, tu crées une Task DataSync :

  1. Source : Tu indiques le chemin de ton NAS local (ex: via le protocole NFS ou SMB).

  2. Destination : Tu choisis ta cible AWS (ex: un système de fichiers AWS FSx for NetApp ONTAP ou un bucket S3).

  3. Fréquence : Tu planifies l'exécution (ex: tous les soirs à 1h du matin).

Étape 3 : La synchronisation intelligente en action

À 1h du matin, la tâche démarre :

  1. L'agent local analyse les fichiers. Contrairement à un outil classique, DataSync utilise un protocole réseau propriétaire d'AWS ultra-optimisé qui parallélise le transfert. Il s'adapte pour saturer au maximum (mais proprement) ta bande passante.

  2. Transfert incrémental : DataSync compare la source et la destination. Si un fichier vidéo de 5 Go n'a pas changé, il ne le renvoie pas. Il n'envoie que les nouveautés ou les modifications.

  3. Préservation des métadonnées : Si le fichier appartenait à l'utilisateur "Graphiste_Jean" avec des droits de lecture spécifiques en local, DataSync réapplique exactement les mêmes droits une fois le fichier arrivé dans AWS FSx.

  4. Vérification de l'intégrité : À la fin du transfert, DataSync calcule une clé de vérification (checksum) pour chaque fichier pour s'assurer qu'aucun octet n'a été corrompu pendant le voyage sur internet.

🎯 Ce qu'il faut retenir pour l'examen SAA-C03 (La différence clé)

On confond souvent Storage Gateway et DataSync. Voici le moyen infaillible de ne plus les mélanger :