🪣 AWS S3 (Simple Storage Service)

9.2. Prix des Requêtes (API)

C'est le pilier n°2 (souvent oublié). Vous payez (un petit montant) par appel API, facturé (généralement) par 1 000 requêtes.

Coûts (Estimés) (us-east-1, Classe Standard)

• PUT, COPY, POST, LIST : ~ $0.005 / 1 000 requêtes. (Les requêtes "d'écriture" ou "de liste" (intensives) sont plus chères).
• GET, SELECT, HEAD : ~ $0.0004 / 1 000 requêtes. (Les requêtes "de lecture" (simples) sont moins chères).
• DELETE : Gratuit (généralement).
• Lifecycle Transitions : ~ $0.01 / 1 000 requêtes. (Coût pour chaque transition (ex: Standard -> IA)).

Le Piège des Petits Objets (FinOps)

(Scénario) : Vous stockez 1 Milliard (1 000 000 000) de petits fichiers (logs) (de 1 KB chacun).

Analyse de Coût (Mensuel) :

• (Coût Stockage) : 1 Milliard * 1 KB = 1 TB. (1 TB * $0.023/GB) ≈ $23.55 / mois (Négligeable).
• (Coût Requêtes - Upload) : 1 Milliard PUT. (1M * 1000 * $0.005) = $5 000.00 / mois.
• (Coût Requêtes - Lifecycle) : (Si vous archivez) 1 Milliard Transitions. (1M * 1000 * $0.01) = $10 000.00 / mois.

(Conclusion) : Le coût des Requêtes (API) ($15 000) est massivement supérieur au coût du Stockage ($23).

(Solution) : Compresser / "Batcher" (regrouper) les petits fichiers (logs) en un seul gros fichier (ex: 1 fichier de 100MB) (via Kinesis Firehose, ou batch local) avant l'upload. (1 PUT (100MB) coûte $0.000005).

9.3. Frais de Transfert (Data Transfer)

C'est le pilier n°3. (Le "coût réseau").

Optimisation (Éviter Egress $0.09/GB)

• 1. CloudFront (CDN) : (Si données publiques/statiques). Mettez CloudFront (devant S3). (Le S3 -> CloudFront est gratuit. Le CloudFront -> Internet est (généralement) moins cher (ex: $0.085/GB) et offre un "Free Tier" (1TB/mois)).
• 2. VPC Endpoint (Gateway) : (Si données privées/EC2). Si vos EC2 (dans un Subnet Privé) accèdent à S3 via un NAT Gateway (payant), le trafic (S3 -> NAT -> EC2) est facturé (Data Processed + Data Transfer).
  (Solution) : Utilisez un VPC Endpoint (Gateway) (pour S3). Le trafic (S3 -> EC2) devient privé (reste sur le réseau AWS) et GRATUIT.

9.4. Politiques de Réduction des Coûts (Checklist FinOps)

1. Utiliser le Bon "Tiers" (Stockage)

• (Auto) S3 Intelligent-Tiering : (Le choix "facile") Pour les workloads (charges) inconnus ou variables. Laisse AWS optimiser (Standard <-> IA).
• (Manuel) Lifecycle Policies : Pour les workloads prévisibles (ex: /logs/). (Action : Transition vers Glacier Deep Archive (9.1) après X jours).

2. Nettoyer (Expiration)

• (Action) : Utiliser les Lifecycle Policies (Expiration) (4.2).
• Expire current versions : (ex: Supprimer /logs/ après 7 ans).
• Expire noncurrent versions : (ex: Supprimer les anciennes versions (Versioning) après 30 jours (Coût caché n°1)).
• Abort incomplete multipart uploads : (ex: Nettoyer les "parts" (morceaux) échoués après 7 jours (Coût caché n°2)).

3. Réduire la Taille (Objet)

• (Action) : Compresser (gzip, zstd) les fichiers (texte, JSON, CSV) côté client (avant l'upload).
• (Gain) : Réduit (Stockage $/GB) + (Transfert $/GB) + (Améliore Vitesse Upload/Download).

4. Réduire les Requêtes (API)

• (Action) : Agréger (Batcher) les millions de petits fichiers (logs 1KB) en un seul gros fichier (100MB) (via Kinesis Firehose, ou script local) avant l'upload (9.2).

5. Réduire le Transfert (Réseau)

• (Action) : Utiliser CloudFront (CDN) (pour Internet) et VPC Endpoints (Gateway) (pour Interne/EC2) (9.3).

9.5. Cas Pratique (Calcul de Facture Mensuelle)

Disclaimer : Les prix (USD) sont fictifs (estimations) (basés us-east-1) à des fins illustratives.

Scénario 1 : "Standard" (Data Lake "Chaud")

• Stockage : 1 TB (1024 GB) (en S3 Standard)
• Objets : 10 000 000 (10M) (assez gros, 100KB/objet)
• Requêtes (Écriture) : 1 Million PUT / mois
• Requêtes (Lecture) : 50 Millions GET / mois
• Transfert (Sortie) : 100 GB (vers Internet)

                    1. Stockage: 1024 GB * $0.023/GB          = $ 23.55
                    2. Requêtes (PUT): (1M / 1000) * $0.005   = $  5.00
                    3. Requêtes (GET): (50M / 1000) * $0.0004  = $ 20.00
                    4. Transfert (OUT): 100 GB * $0.09/GB     = $  9.00
                    ---------------------------------------------------
                    TOTAL (Estimé) :                       = $ 57.55 / Mois
                

Scénario 2 : "Archive" (Backup Froid)

• Stockage : 1 TB (1024 GB) (en S3 Glacier Deep Archive)
• Requêtes (Écriture) : 1 Million PUT / mois (via Lifecycle Standard -> Glacier)
• Requêtes (Lecture) : 0 (Rien n'est lu, c'est une archive)

                    1. Stockage: 1024 GB * $0.00099/GB (Deep) = $  1.01
                    2. Requêtes (PUT/Transition):
                    (1M / 1000) * $0.005 (PUT Standard)    = $  5.00
                    (1M / 1000) * $0.05 (Transition Deep)  = $ 50.00  (Coût "one-shot" de l'archivage !)
                    ---------------------------------------------------
                    TOTAL (Mois 1) :                       = $ 56.01
                    TOTAL (Mois 2+) (Idle) :               = $  1.01 / Mois
                

8.2. Architecture Data Lake (S3 → Glue → Athena → QuickSight)

S3 est la fondation du "Data Lake" moderne. C'est le réceptacle (pas cher, durable, illimité) pour toutes les données de l'entreprise (brutes et transformées).

                    (Sources: IoT, Logs, BDD...)
                    |
                    v
                    [ 🪣 S3 (Zone "Raw" / "Bronze") ] (Stocke les .CSV, .JSON bruts)
                    |
                    v
                    [ 🤖 AWS Glue (Job ETL) ] (Script Spark/Python)
                    ( (1) Lit 'Raw', (2) Nettoie, (3) Joint, (4) Convertit en Parquet, (5) Partitionne )
                    |
                    v
                    [ 🪣 S3 (Zone "Processed" / "Gold") ] (Stocke les .parquet (partitionnés))
                    |
                    v
                    [ 📊 AWS Athena (Service SQL) ] (Scan S3/Parquet via 'Glue Data Catalog')
                    |
                    v
                    [ 📈 Amazon QuickSight (BI) ] (Dashboard / Visualisation)
                

Partitionnement (Data Lake)

(Le Piège du Coût) : Athena (et Glue/EMR) est facturé au $/TB scanné (lu).

(Mauvais Design) : /logs/log-01.parquet, /logs/log-02.parquet... (1 Pétaoctet).

(Requête) : SELECT * ... WHERE date = '2025-11-17' -> (Athena scanne 1 Pétaoctet = $5,000 USD).

(Bon Design - Partitionnement "Hive") : L'ETL (Glue) doit écrire (partitionner) les données dans S3 en utilisant des "préfixes" (pseudo-dossiers) Clé=Valeur.

                    /logs/year=2025/month=11/day=17/fichier1.parquet
                    /logs/year=2025/month=11/day=18/fichier2.parquet
                

(Requête) : SELECT * ... WHERE year=2025 AND month=11 AND day=17 -> (Athena (via "Partition Pruning") ne scanne que le préfixe day=17/ (ex: 500 GB) = $2.50 USD).

8.3. Architecture CDN (S3 + CloudFront)

C'est l'architecture standard pour la distribution (rapide, globale) et sécurisée d'assets (fichiers) statiques (Images, Vidéos, CSS, JS, Builds React/Vue).

Flux (Performant & Sécurisé)

                    (Utilisateur - Paris)
                    |
                    (1. GET 'logo.png' (Latence 10ms))
                    |
                    v
                    [ 🌍 CloudFront (Edge Location: Paris) ]
                    |
                    (2. Cache "MISS" (Première fois))
                    |
                    v
                    [ (Interne) OAC (Origin Access Control) ]
                    |
                    (3. Autorisé (via Bucket Policy))
                    |
                    v
                    [ 🪣 S3 Bucket (Origine: Francfort) ] (Reste 100% PRIVÉ)
                

Composants Clés

• S3 (Bucket Privé) : L'origine (source de vérité). Il doit rester 100% PRIVÉ (Block Public Access = ON).
• CloudFront (Distribution) : Le CDN (Réseau de Diffusion de Contenu). Il "met en cache" (copie) les objets (logo.png) dans 450+ Edge Locations (Points de Présence) (ex: Paris, Lyon, Marseille) (proche des utilisateurs).
• OAC (Origin Access Control) : (Remplace OAI (Legacy)). C'est la "permission" (basée Service) que vous mettez dans la Bucket Policy de S3, qui dit : "Allow s3:GetObject uniquement (Principal) au Service CloudFront (et (Condition) à ma Distribution (SourceArn))".

Signed URLs (Contenu Privé)

Pour distribuer du contenu privé (ex: facture-client-123.pdf) via le CDN :

1. (S3) L'objet facture.pdf est privé (OAC).
2. (App) Votre App (EC2/Lambda) génère (signe) une URL CloudFront Signée (pas une URL S3 Signée) (valide 5 min).
3. (Client) Le client utilise cette URL (.../facture.pdf?Expires=...&Signature=...).
4. (CloudFront) Valide la signature -> Si OK -> (Fetch) Récupère l'objet (via OAC) -> Sert au client.

8.4. Architecture Big Data (S3 comme Datastore EMR)

C'est le concept de Découplage (Désolidarisation) du Stockage (Storage) et du Calcul (Compute) pour les workloads Big Data (Hadoop, Spark).

Architecture Traditionnelle (Hadoop / HDFS)

(Serveur 1) [ CPU | RAM | Disque 1 (Data) ]
(Serveur 2) [ CPU | RAM | Disque 2 (Data) ]

(Problème) : Le Stockage (HDFS) et le Calcul (MapReduce/Spark) sont couplés (liés). Si vous voulez plus de stockage (Disque 3), vous êtes obligé d'acheter (et payer) plus de CPU/RAM (Serveur 3) (et vice-versa).

Architecture Moderne (EMR + EMRFS/S3)

                    (Stockage "Infini", Pas cher)
                    [ 🪣 S3 (Data Lake / HDFS "virtuel") ]
                    |
                    (EMRFS)
                    |
                    v
                    [ ⚙️ EMR Cluster (Calcul) ]
                    |
                    +-- [ EC2 Master Node ]
                    +-- [ EC2 Core Nodes (ASG) ]  <-- (Compute)
                    +-- [ EC2 Task Nodes (Spot) ] <-- (Compute)
                    

(Découplage) : EMRFS (E M R File System) est un "driver" qui permet à EMR (Spark/Hadoop) d'utiliser S3 comme s'il s'agissait d'HDFS.

(Avantages) :

• Scalabilité Indépendante : Vous pouvez scaler le Stockage (S3) (infini) ou le Calcul (EC2) (ASG) séparément.
• Fiabilité (11 9s) : Les données (sur S3) sont protégées (Multi-AZ), même si un Nœud EC2 (Compute) meurt.
• Coût (FinOps) : Vous pouvez terminer (éteindre) le Cluster EMR (Calcul) (ex: la nuit, coût EC2 = $0) et les données (Stockage) (sur S3) persistent (à faible coût).
• Coût (Spot) : Vous pouvez utiliser des Nœuds "Task" (Calcul pur) 100% Spot Instances (non-persistants, -90% coût).

8.5. Archivage Entreprise & DR (Disaster Recovery)

Utilisation de S3 (et de ses classes) pour la rétention (archivage) long-terme et la reprise après sinistre (Disaster Recovery Plan - DRP).

Flux 1 : Archivage (Lifecycle)

Remplacement des "bandes (Tapes) LTO". Les données (ex: Backups RDS, Snapshots EC2) sont envoyées sur S3 (Standard) puis "descendues" (automatiquement) via une Lifecycle Policy (Règle de Cycle de Vie).

                    (Data) -> [S3 Standard] -> (Après 30j) -> [S3 Standard-IA] -> (Après 90j) -> [S3 Glacier Deep Archive]
                

(Objectif) : Rétention long-terme (ex: 7-10 ans) au coût (GB/mois) le plus bas possible (Glacier Deep Archive).

Flux 2 : Disaster Recovery (DR) (Multi-Région)

Archiver c'est bien, mais si la Région (ex: Paris) tombe en panne ? Il faut une copie (DR) dans une autre Région (ex: Francfort).

On utilise CRR (Cross-Region Replication) (Réplication Inter-Région).

                    (Serveur Backup On-Premise)
                    |
                    (Upload)
                    |
                    v
                    [ 🪣 S3 Bucket (Source) (Région: Paris (eu-west-3)) ]
                    |  (Lifecycle: "Expire après 30 jours")
                    |
                    (CRR (Replication) Activée)
                    |
                    v
                    [ 🪣 S3 Bucket (Destination-DR) (Région: Francfort (eu-central-1)) ]
                    (Lifecycle: "Transition vers Glacier Deep Archive après 30 jours")
                    (S3 Object Lock: "Compliance Mode 7 ans")
                

(Flux Hybride) :

1. Le backup (On-Prem) est uploadé à Paris (Source) (pour restauration "chaude" rapide, si besoin).
2. CRR copie (immédiatement) le backup à Francfort (Destination-DR).
3. (Paris) La Lifecycle (Source) supprime le backup (chaud) après 30 jours (pour économiser).
4. (Francfort) La Lifecycle (Destination) archive le backup (froid) vers Glacier Deep Archive (pour rétention 7 ans (Compliance)).

7.2. S3 Object Lambda (Transformation "à la volée")

C'est une fonctionnalité (PaaS) qui permet d'exécuter une fonction Lambda (compute) pour modifier (transformer) le contenu d'un objet S3 pendant (à la volée) qu'il est téléchargé (GetObject).

(Important) : L'objet (original) sur S3 n'est jamais modifié. La transformation est (uniquement) appliquée à la réponse (GET).

Flux (Exemple : Redimensionnement d'Image)

                (Client/App) <-- (Requête HTTP 'GET image.jpg?width=200')
                |
                v
                [ ☁️ S3 Object Lambda (Access Point) ]
                |
                (Appel API 'GetObject' (interne))
                |
                v
                [ 🪣 S3 Bucket ] (Lit 'image.jpg' (Original, 10MB))
                |
                (S3 envoie l'objet (10MB) à la Lambda)
                |
                v
                [ 🔥 Fonction Lambda ]
                (Code Python (Pillow) :
                1. Lit '?width=200' (Request Params)
                2. Redimensionne l'image (10MB -> 150KB)
                3. Retourne (Stream) l'image (150KB) )
                |
                v
                (Client/App) <-- (Réponse HTTP 200) (Reçoit l'image (150KB))
                

Cas d'Usage

• Redimensionner / Watermarker des images (à la volée).
• Filtrer / Anonymiser (PII) des données (ex: "Masquer (***) la colonne 'Nom' d'un CSV (5GB) avant de le renvoyer à l'utilisateur 'Analyste-Junior'").
• Décompresser (.gz) un fichier (à la volée) pour un client (léger) qui ne gère pas Gzip.

7.3. S3 Event Notifications (Triggers)

C'est le "système nerveux" de S3. Il permet au Bucket de publier (pousser) un événement (notification JSON) (de manière asynchrone) lorsque quelque chose se passe.

Événements (Triggers) Configurables

• s3:ObjectCreated:* (Le plus courant) (Déclenché par PUT, POST, COPY, CompleteMultipartUpload).
• s3:ObjectRemoved:* (Déclenché par DELETE, DeleteMarkerCreated).
• s3:ObjectRestore:* (Déclenché quand une restauration (Glacier) est Initiated ou Completed).

(Vous pouvez (aussi) filtrer par Préfixe (ex: images/) ou Suffixe (ex: .jpg)).

Destinations (Où va l'événement ?)

• 🔥 AWS Lambda (Fonction) : (Le plus courant) "S3 -> Lambda".
• 📨 SQS (File d'attente) : (Bonne Pratique) (Pour le découplage/buffering) "S3 -> SQS -> Lambda". (Permet de gérer les "retries" et les pics de charge).
• 📣 SNS (Topic) : (Bonne Pratique) (Pour "Fan-out") "S3 -> SNS -> (Lambda + SQS + Email...)".

Architecture Serverless Typique (S3 → Lambda)

                    (Utilisateur)
                    |
                    (1. PUT 'photo.jpg' (Upload))
                    |
                    v
                    [ 🪣 S3 Bucket ]
                    |
                    (2. Event (s3:ObjectCreated) (JSON))
                    |
                    v
                    [ 🔥 AWS Lambda (Fonction) ]
                    (
                    3. Code Python (Boto3):
                    - Lit l'Event JSON (bucket/key)
                    - s3:GetObject('photo.jpg')
                    - Crée thumbnail (Pillow)
                    - s3:PutObject('thumb/photo.jpg')
                    )
                

7.4. S3 Inventory (Inventaire Complet)

Problème : J'ai 10 Milliards d'objets (10 Pétaoctets) dans un bucket. Comment puis-je les lister (tous) (pour audit/analyse) ?

(Anti-Pattern) : Utiliser l'API ListObjectsV2 (paginée). (Prendrait des semaines et coûterait très cher (en requêtes LIST)).

Solution : S3 Inventory

C'est un service (configuré sur le Bucket Source) qui génère (automatiquement) un "rapport" (inventaire) complet (de tous les objets) (quotidiennement ou hebdomadairement).

Fonctionnement

1. (Config) Vous activez "S3 Inventory" (sur Bucket-A).
2. (Config) Vous choisissez Quoi lister (Champs : Size, StorageClass, EncryptionStatus, ObjectLockInfo, LastModifiedDate...).
3. (Config) Vous choisissez le Format (Sortie) : CSV, ORC, ou (Recommandé) Apache Parquet.
4. (Config) Vous choisissez la Destination (ex: Bucket-B (Logs)).
5. (Run) (Tous les jours/semaines) S3 (service) scanne Bucket-A et écrit le "Manifest" (inventaire) (ex: .../inventory.parquet) dans Bucket-B.

Intégration Athena (Analyse SQL)

La vraie puissance est que cet inventaire (.parquet) est automatiquement intégrable (query-able) avec AWS Athena.

(Usage Audit/FinOps) : Vous pouvez (via Athena) "requêter" (SQL) l'état de vos 10 Milliards d'objets :

                    -- (Ex: Trouver tous les objets NON chiffrés)
                    SELECT * FROM s3_inventory_table
                    WHERE encryption_status = 'NOT_SSE';

                    -- (Ex: Trouver le coût (estimé) des anciennes versions)
                    SELECT sum(size) FROM s3_inventory_table
                    WHERE is_latest = false;
                

6.2. AWS CloudTrail (Audit API : "Qui a fait Quoi ?")

CloudTrail est le service d'Audit (Journal d'audit) de tout le compte AWS. Il répond à la question : "Qui (IAM User/Role) a fait Quoi (API Call) Quand (Timestamp) Où (Source IP) ?".

Management Events (Control Plane)

• (Activé par Défaut) (Rétention 90 jours (Event History)).
• Loggue les actions "sur" le bucket (le "Contrôle").
• Exemples : CreateBucket, DeleteBucket, PutBucketPolicy (!!), DeleteBucketLifecycle.
• Usage (Sécurité) : "Qui a modifié la Bucket Policy (pour la rendre publique) hier soir ?"

Data Events (Data Plane)

• (Désactivé par Défaut) (Payant, Volumineux, Opt-in).
• Loggue les actions "dans" le bucket (les "Données").
• Exemples : GetObject (Lecture), PutObject (Écriture), DeleteObject (Suppression).

(Bonne Pratique / Compliance) : Activer (via un "Trail" (audit)) les "Data Events" (au minimum "Write") sur les buckets sensibles (ex: bucket-prod-secrets) (malgré le coût).

Usage (Audit) : "Qui (IAM:UserA) a DeleteObject (supprimé) le fichier rapport-secret.pdf ?".

6.3. S3 Server Access Logging (Logs HTTP Bruts)

C'est l'équivalent du access.log (Apache/Nginx) pour S3. C'est un fichier texte (brut) (livré "best-effort" dans un autre bucket S3) qui loggue chaque requête HTTP reçue par le bucket.

CloudTrail (6.2) vs Server Access Logs (6.3)

Ils se ressemblent mais répondent à des questions différentes :

• CloudTrail (Audit) : "Qui (IAM) a fait l'appel API (GetObject) ?" (Focus : Sécurité AWS).
• Access Logs (HTTP) : "Qui (IP) a fait l'appel (GET) ? Quel était le User-Agent ? Quel était le Referer (Site d'origine) ? Quelle était la Raison du 403 (ex: SignatureDoesNotMatch) ?" (Focus : Analyse de trafic, Debug HTTP).

Exemple de Log (Format Brut)

                    [ID_BUCKET] 1.2.3.4 [Time] "GET /images/logo.png HTTP/1.1" 403 AccessDenied 102 10 
                    "https://mon-site.com/" "Mozilla/5.0... (Chrome)" - (HostId...)
                    (Raison de l'échec: SignatureDoesNotMatch)
                

(Inconvénient) : Extrêmement verbeux (génère des millions de mini-fichiers logs). (Difficile à analyser sans Athena (6.5)).

6.4. S3 Storage Lens (Dashboard FinOps & Sécurité)

C'est le Dashboard (Tableau de Bord) d'Observabilité de S3. Il fournit une vue (agrégée) (au niveau Organisation AWS, Compte, Bucket, ou Préfixe) de l'utilisation (Usage) du stockage.

Il est essentiel pour l'Optimisation des Coûts (FinOps).

Questions auxquelles Storage Lens Répond

• (Global) "Où sont mes 50 Pétaoctets ? (Répartition par Région, par Compte)".
• (FinOps) "Quel est le % de mes données en Standard vs Glacier ?"
• (FinOps) "Combien de GB de mes données sont des Anciennes Versions (NonCurrent) ?" (Coût caché du Versioning (4.3)).
• (FinOps) "Combien de GB sont des Uploads Multipart Incomplets ?" (Coût caché (4.2)).
• (FinOps) "Quel est mon Taux de Retrieval (Lecture) sur mes buckets Standard-IA ?" (Si 50%, c'est un mauvais choix de classe, il faut repasser en Standard).
• (Sécurité) "Quel % de mes buckets n'est pas chiffré (Encryption) ?"
• (Sécurité) "Quel % de mes buckets autorise l'accès public ?"

Tiers (Gratuit vs Payant)

• Free (Défaut) : (Gratuit) 15 métriques (niveau Bucket), rétention 14 jours. (Suffisant pour débuter).
• Advanced (Payant) : (Coût $/objet/mois) +35 métriques (descend au niveau Préfixe), rétention 15 mois, recommandations FinOps (IA).

6.5. Amazon Athena (Interroger les Logs S3 en SQL)

Problème (Logs Bruts)

Vos Logs d'Accès S3 (6.3) ou vos Logs CloudTrail (6.2) sont stockés dans un bucket S3 sous forme de millions de fichiers .log.gz (Texte/JSON).

(Question) : "Trouver toutes les IP (srcIP) qui ont eu une erreur 403 sur l'objet secret.pdf le 10 Novembre."
(Réponse Manuelle) : Impossible (grep sur des Pétaoctets ?).

Solution (Athena - Serverless SQL)

AWS Athena est un service Serverless (PaaS) qui permet d'exécuter des requêtes SQL (ANSI) directement sur les fichiers (données) stockés dans S3.

Flux (Mise en Place)

1. (Logs) (Automatique) Les Logs (CloudTrail/S3) arrivent dans s3://mon-bucket-logs/.
2. (Glue) (Semi-Auto) Utiliser un AWS Glue Crawler (Robot) pour scanner s3://mon-bucket-logs/ et inférer (deviner) le "schéma" (les colonnes: ip, timestamp, action...).
3. (Glue) Le Crawler crée (automatiquement) une "Table" (Métadonnées) (ex: cloudtrail_logs) dans le Glue Data Catalog.
4. (Athena) (Manuel) Ouvrir la console Athena, sélectionner la table cloudtrail_logs.

Exécution (Requête SQL)

                    -- (Syntaxe SQL Presto/Trino)
                    SELECT
                    useridentity.username,
                    sourceipaddress,
                    eventtime
                    FROM 
                    cloudtrail_logs
                    WHERE 
                    eventname = 'DeleteObject'
                    AND requestparameters LIKE '%secret.pdf%'
                    AND eventtime BETWEEN '2025-11-10T14:00:00Z' AND '2025-11-10T15:00:00Z';
                

(Coût FinOps) : Athena est facturé au $/TB (Téraoctet) scanné (ex: $5.00 / TB). (Bonne Pratique : Toujours stocker les logs en format Parquet (Colonnes) et Partitionné (par Date) (ex: /year=2025/month=11/) pour réduire (drastiquement) la quantité (TB) scannée (et le coût).

5.2. Optimisation du Stockage (FinOps)

1. Choix des Classes (Tiering)

C'est la stratégie n°1. Ne pas tout laisser en S3 Standard (le plus cher).

• Stratégie 1 (Automatique) : S3 Intelligent-Tiering. (Recommandé). Laissez AWS (IA) analyser l'accès (objet par objet) et le déplacer (automatiquement) vers le Tiers (IA/Archive) approprié (sans frais de "Retrieval").
• Stratégie 2 (Manuelle) : S3 Lifecycle Policies. (Pour les patterns prévisibles). (Ex: /logs/ -> (30j) -> Standard-IA -> (90j) -> Glacier Deep Archive -> (3650j) -> Expire (Delete)).

2. Analyse (Storage Lens)

S3 Storage Lens est le "dashboard" (gratuit ou payant (avancé)) d'observabilité FinOps. Il vous donne une vue (globale, par compte, par bucket, par préfixe) de votre stockage pour trouver les gaspillages.

Il répond à :

• "Où sont mes 10 Pétaoctets ?" (Total GB, Nb Objets).
• "Combien (%) de mes données sont dans Standard vs Glacier ?"
• (Action FinOps) "Combien (GB) de mes données sont des Anciennes Versions (NonCurrent) ?" (Coût caché du Versioning -> Activer Lifecycle (4.2)).
• (Action FinOps) "Combien (GB) de mes données sont des Uploads Multipart Incomplets ?" (Coût caché -> Activer Lifecycle (4.2)).
• "Combien (%) de mes objets ne sont pas chiffrés ?" (Audit Sécurité).

3. Compression (Client-Side)

C'est une optimisation (côté client) avant l'upload. (S3 ne compresse pas les données pour vous).

(Exemple) : Fichier logs.json (100 MB, Texte) -> gzip logs.json.gz (10 MB, Compressé).

(Tradeoff) : CPU (Client) vs (Économies x3) :

• Coût Stockage (S3) : Vous payez (stockage) 10 MB (au lieu de 100 MB).
• Coût Data Transfer (Out) : (Si lu par EC2/Athena) Vous payez (transfert) 10 MB (au lieu de 100 MB).
• Performance (Upload/Download) : Le transfert (PUT/GET) est 10x plus rapide (10 MB vs 100 MB).

(Recommandé) : Toujours compresser (gzip, zstd (moderne), snappy (Big Data)) les fichiers "texte" (Logs, JSON, CSV). (Ne pas compresser .jpg, .mp4 (déjà compressés)).

5.3. Optimisation des Requêtes (Performance)

Préfixes Optimisés (Contre le "Throttling")

Le Goulot d'Étranglement (Hot Prefix) : S3 garantit une performance (massive) de 3 500 PUT/s ou 5 500 GET/s... par Préfixe (pseudo-dossier).

(Problème) : 10 000 (IoT Devices) tentent d'uploader (simultanément) vers le même préfixe :

                    (Device 1) -> PUT /logs/2025/11/17/device1.log
                    (Device 2) -> PUT /logs/2025/11/17/device2.log
                    ...
                    (Device 10000) -> PUT /logs/2025/11/17/device10000.log
                

(Résultat) : Les 3500 premières requêtes/sec (sur le préfixe /logs/2025/11/17/) passent. Les 6500 suivantes reçoivent une erreur 503 Slow Down (Throttling).

(Solution) : Ajouter de l'Entropie (Randomness) au début (ou juste après) le préfixe (pour "Sharder" (éclater) le trafic sur plusieurs préfixes logiques) :

                    (Device 1 - Hash 'a1') -> PUT /logs/a1/2025/11/17/device1.log  (Prefix 1)
                    (Device 2 - Hash 'b2') -> PUT /logs/b2/2025/11/17/device2.log  (Prefix 2)
                    ...
                    (Device 10000 - Hash 'f9') -> PUT /logs/f9/2025/11/17/device10000.log (Prefix N)
                

Partitionnement Logique (Data Lake)

C'est une optimisation (similaire) mais pour le Coût (Scan) (ex: avec AWS Athena).

(Mauvais Design) : /logs/device1.log, /logs/device2.log ... (1 Pétaoctet dans 1 Préfixe).

(Requête Athena) : SELECT * FROM logs WHERE date = '2025-11-17' -> (Athena doit scanner 1 Pétaoctet = $5,000 USD).

(Bon Design - Hive Style Partitioning) :

/logs/year=2025/month=11/day=17/file1.parquet

(Requête Athena) : SELECT * FROM logs WHERE year=2025 AND month=11 AND day=17 -> (Athena (via "Partition Pruning") ne scanne que le préfixe day=17/ (ex: 500 GB) = $2.50 USD).

S3 Select (Filtrage Côté Serveur)

Permet d'exécuter une requête (SQL-like) directement sur 1 objet S3 (CSV, JSON, Parquet) et de ne récupérer que le résultat (pas le fichier entier).

(Problème) : Télécharger (GetObject) un fichier CSV (Gzip) de 5 GB (pour trouver 10 lignes) -> (Lent, coûteux (Data Transfer 5GB), intensif (CPU Lambda/EC2 pour dézipper/parser)).

(Solution) : SelectObjectContent (API) :

                    SELECT s._1, s._5 
                    FROM S3Object s 
                    WHERE s._2 = 'Paris' AND s._3 = 'Completed'
                

(Résultat) : S3 (côté serveur) dézippe, parse le CSV (5GB), filtre les 10 lignes, et ne vous renvoie (réseau) que 1 KB. (Jusqu'à 400% plus rapide, 80% moins cher).

4.2. Expiration Rules (Suppression Automatique)

L'Expiration est la deuxième action (après "Transition") d'une Règle de Cycle de Vie (4.1). Elle supprime (DELETE) définitivement les objets après X jours, pour éviter les coûts inutiles (FinOps).

Actions d'Expiration (Cas d'Usage)

4.3. Versioning (Historique des Fichiers)

Le Versioning (Gestion des versions) est un paramètre (Niveau Bucket) qui agit comme un "filet de sécurité" (protection contre la suppression accidentelle ou l'écrasement).

Une fois Activé (Enabled), il ne peut être que Suspendu (Suspended) (jamais "Désactivé" (Disabled)).

Flux (Avec Versioning Activé)

• (Upload v1) PUT rapport.pdf (v1) -> Crée ID: AAAA (Version Current (Actuelle)).
• (Upload v2) PUT rapport.pdf (v2) -> Crée ID: BBBB (Version Current). (ID: AAAA (v1) devient NonCurrent (Ancienne)).
• (Lecture) GET rapport.pdf -> Lit toujours la version Current (ID: BBBB (v2)).
• (Lecture v1) GET rapport.pdf?versionId=AAAA -> (Permet de lire l'ancienne version v1).

Le Piège du "Delete Marker" (Suppression)

• (Suppression) DELETE rapport.pdf (sur un bucket "versioned") :
• Ne supprime RIEN (ni v1, ni v2).
• Crée (au-dessus) un "Delete Marker" (Marqueur de suppression) (ID: CCCC) qui devient Current.
• (Lecture) GET rapport.pdf -> (Lit ID: CCCC (Current)) -> S3 renvoie 404 Not Found (l'objet "semble" supprimé).

(Restauration) : Pour "restaurer" le fichier (v2), il suffit de supprimer (DELETE) le "Delete Marker" (ID: CCCC). (ID: BBBB (v2) redevient Current).

Impact sur le Coût (FinOps)

Vous êtes facturé pour le stockage de TOUTES les versions (Current + NonCurrent (v1, v2...)).
(Bonne Pratique) : Toujours combiner le Versioning avec une Règle Lifecycle (4.2) (ex: "Expire noncurrent object versions après 60 jours") pour nettoyer les anciennes versions.

4.4. Object Lock (WORM - Rétention Légale)

C'est une fonctionnalité (type WORM : Write Once, Read Many) qui verrouille un objet (une version spécifique) pour empêcher sa suppression ou sa modification, (généralement pour des raisons légales ou de conformité).

(Pré-requis) : 1. Le Versioning (4.3) doit être activé. 2. L'Object Lock doit être activé à la CRÉATION du bucket (vous ne pouvez pas l'activer sur un bucket existant).

Les 2 Modes de Rétention (Retention)

Vous uploadez un objet (PUT) en spécifiant une "Date de Rétention" (ex: 1 an) et un "Mode" :

Legal Hold (Mise en attente légale)

C'est un verrou (booléen ON/OFF) indépendant de la Rétention. Il n'a pas de date de fin.

Usage : (Audit/Litige) Un Auditeur (avec permission s3:PutObjectLegalHold) active le Legal Hold (ON). L'objet ne peut plus être supprimé (même si la Rétention (ex: 1 an) expire). L'Auditeur doit (manuellement) le remettre (OFF) à la fin de l'enquête.

4.5. Replication (Cross-Region & Same-Region)

La Réplication est une règle (au niveau Bucket) qui copie (automatiquement et de manière asynchrone) les nouveaux objets (PUT, DELETE...) d'un Bucket (Source) vers un Bucket (Destination).

(Pré-requis) : Le Versioning (4.3) doit être activé sur le bucket Source ET le bucket Destination.

1. CRR (Cross-Region Replication) - (Inter-Région)

La Destination (Bucket B) est dans une autre Région AWS.

Exemple : Bucket-A (Paris, eu-west-3) -> (CRR) -> Bucket-B (Francfort, eu-central-1)

• Cas d'Usage 1 (DR/PRA) : Disaster Recovery. Si toute la Région eu-west-3 (Paris) tombe (panne majeure), les données (backups) sont saines et sauves à Francfort.
• Cas d'Usage 2 (Latence) : (Optimisation Lecture) Vous avez des clients (Lecteurs) en Asie. Vous répliquez (CRR) les objets (statiques) vers ap-southeast-1 (Singapour) (pour qu'ils (via CloudFront) lisent depuis Singapour (rapide) plutôt que Paris (lent)).

(RTC) : Vous pouvez (option payante) activer Replication Time Control (RTC), qui garantit (SLA) que 99.99% des objets sont répliqués en moins de 15 minutes.

2. SRR (Same-Region Replication) - (Même Région)

La Destination (Bucket B) est dans la même Région (ex: Paris -> Paris).

• Cas d'Usage 1 (Log Aggregation) : (Agrégation de Logs) 10 Buckets (ALB-Logs, App-Logs...) (Sources) répliquent (SRR) tous leurs nouveaux objets (.log) vers 1 seul Bucket central (central-log-bucket) (Destination) (pour analyse (Athena)).
• Cas d'Usage 2 (Sécurité / Multi-Compte) : (Isolation) Bucket-Prod (Compte A) -> (SRR) -> Bucket-Backup (Compte B). (Le Compte B (Backup) est 100% verrouillé (Deny All), protégeant les copies contre un piratage (ex: vol de clés) du Compte A).

3.2. Bucket Policies (Resource-based)

Les Bucket Policies (Politiques de Bucket) sont "Resource-based" (basées sur la Ressource). Elles sont attachées au Bucket S3 lui-même.

Elles répondent à la question : "Qui (Principal) a le droit d'accéder à moi (ce Bucket) ?".

C'est l'outil principal pour : 1) Donner un accès Cross-Compte (Compte B -> Compte A). 2) Restreindre l'accès (ex: IP, VPC). 3) Donner l'accès à un Service AWS (ex: CloudFront).

Exemple 1 : Forcer SSL (HTTPS)

(Refuse (Deny) toute action (*) si la connexion n'est pas aws:SecureTransport = true).

                    {
                    "Sid": "ForceSSL",
                    "Effect": "Deny",
                    "Principal": "*",
                    "Action": "s3:*",
                    "Resource": "arn:aws:s3:::mon-bucket/*",
                    "Condition": {
                    "Bool": { "aws:SecureTransport": "false" }
                    }
                    }
                

Exemple 2 : Restreindre à CloudFront (OAC) (Best Practice)

(Autorise (Allow) GetObject uniquement au Principal: Service: cloudfront.amazonaws.com ET si l'appel vient de votre Distribution (aws:SourceArn)).

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

3.3. ACL (Access Control List) - (Héritage/Legacy)

Les ACLs sont le système de sécurité "originel" (historique) de S3 (avant IAM/Bucket Policies). Elles sont (généralement) définies en XML et peuvent être attachées au Bucket ou (pire) Objet par Objet.

Pourquoi Éviter les ACLs (Le Piège de "l'Object Ownership")

(Problème Historique) : Par défaut (avec ACLs activées), si un Compte B (ex: un partenaire) uploade (PUT) un objet (fichier.log) dans un Bucket (appartenant au Compte A) :

• Le Compte B devient Propriétaire (Owner) de l'Objet (fichier.log).
• Le Compte A est propriétaire du Bucket.
• Résultat (Fou) : Le Compte A (Propriétaire du Bucket) ne peut pas lire/supprimer fichier.log (car il n'en est pas propriétaire).

La Bonne Pratique (Désactiver les ACLs)

Aujourd'hui, la meilleure pratique est de DÉSACTIVER les ACLs.

1. (Console S3 -> Bucket -> Permissions)
2. Paramètre "Object Ownership" (Propriété de l'objet)
3. Choisir : Bucket owner enforced (Propriétaire du bucket appliqué).

(Résultat) : Les ACLs sont désactivées. Le Propriétaire du Bucket (Compte A) devient (automatiquement) propriétaire de tous les objets (même ceux uploadés par le Compte B). (La sécurité est uniquement gérée via IAM (3.1) et Bucket Policies (3.2)).

3.4. Encryption (Chiffrement "At-Rest")

(Défaut 2023) : Aujourd'hui, S3 chiffre (crypte) automatiquement 100% des nouveaux objets uploadés (en utilisant SSE-S3 par défaut).

3.5. Block Public Access (BPA)

(Le Verrou de Sécurité n°1) C'est un "interrupteur" (garde-fou) qui écrase (override) toute autre configuration (Bucket Policy (3.2), ACL (3.3)) qui tenterait (accidentellement) de rendre un bucket public.

(Bonne Pratique) : Toujours ACTIVER (ON) (les 4 paramètres) au niveau du Compte (Account).

Les 4 Paramètres (Niveau Compte ou Bucket)

• Block new public ACLs (Bloquer les nouvelles ACLs publiques) :
  • (Refuse les PUT Object qui ont une ACL public-read).
• Ignore public ACLs (Ignorer les ACLs publiques existantes) :
  • (Ignore toutes les ACLs public-read sur le bucket).
• Block new public bucket policies (Bloquer les nouvelles policies publiques) :
  • (Refuse les PutBucketPolicy qui contiennent "Effect": "Allow" pour "Principal": "*").
• Restrict public buckets (Restreindre les policies publiques existantes) :
  • (Ignore toutes les policies publiques (sauf services (ex: CloudFront OAC (3.2)) ou Cross-Compte)).

(Seule Exception) : Le seul cas où l'on désactive (partiellement) BPA (Block... policies) est pour l'Hébergement de Site Web Statique (Legacy). (La bonne pratique (moderne) est d'utiliser CloudFront + OAC (3.2), qui permet de garder BPA Activé (ON)).

3.6. S3 Access Points (Points d'Accès)

C'est une fonctionnalité (avancée) pour gérer l'accès (granulaire) à un bucket partagé (Shared Bucket).

Problème (1 Bucket, 50 Équipes)

Vous avez 1 "Data Lake" (bucket-datalake). 50 équipes (Ventes, Marketing, BI...) y écrivent/lisent (dans leurs "préfixes" (/ventes/, /marketing/)).

(Le Piège) : Vous devez gérer 1 seule Bucket Policy (3.2) (JSON) monstrueuse (de 20 000 lignes) pour gérer les permissions (Allow Ventes -> /ventes/, Allow Marketing -> /marketing/...). (Ingérable, risque d'erreur élevé).

Solution (Access Points)

Vous (Admin) créez un Point d'Accès (Access Point) (un "alias" DNS) pour chaque équipe. Chaque Access Point a sa propre Policy IAM (simple).

                    (Bucket "bucket-datalake") <-- (Policy : Vide)
                    |
                    +--- [ AccessPoint "AP-Ventes" ] (ARN: ...:accesspoint/ap-ventes)
                    |      (Policy AP: "Allow (Principal: Role-Ventes) -> (Action: *) -> (Resource: .../ap-ventes/object/ventes/*)")
                    |
                    +--- [ AccessPoint "AP-Marketing" ] (ARN: ...:accesspoint/ap-marketing)
                    (Policy AP: "Allow (Principal: Role-Marketing) -> (Action: Get) -> (Resource: .../ap-marketing/object/marketing/*)")
                

(Résultat) : L'équipe "Ventes" (via son Rôle IAM) ne parle jamais au "bucket-datalake", elle parle (uniquement) à l'Alias (ARN) ap-ventes. (La sécurité est déléguée et segmentée).

Multi-VPC Access Points

Permet (via PrivateLink) de créer un Access Point (privé) qui est accessible (via VPC Endpoints (3.7)) depuis plusieurs VPCs (même Cross-Compte), sans nécessiter de Peering/TGW.

3.7. VPC Endpoints (Accès Privé)

Problème : Une EC2 (ou Lambda) est dans un Subnet Privé (sans accès Internet / NAT GW). Elle doit (via Boto3) appeler s3:GetObject. L'API S3 (s3.eu-west-3.amazonaws.com) est (par défaut) publique (sur Internet).

(Résultat) : Connection Timeout (L'EC2 Privée ne peut pas joindre l'API S3).

Solution : VPC Endpoint (Gateway Type)

C'est une "passerelle" (virtuelle) qui connecte (magiquement) votre VPC (privé) au service S3 (public), en utilisant le réseau privé (backbone) d'AWS (le trafic ne va jamais sur Internet).

Fonctionnement (Routage)

1. (Admin) "Create Endpoint" -> Type: Gateway -> Service: s3 (ou dynamodb).
2. (Admin) Cochez la Route Table (rt-private) de votre Subnet Privé.
3. (AWS) AWS ajoute (automatiquement) une nouvelle Règle (Route) à rt-private :

                    # (Dans la Route Table Privée)
                    Destination:  pl-12345... (C'est la "Prefix List" (IPs publiques) de S3 eu-west-3)
                    Target:       vpce-67890... (L'ID de l'Endpoint Gateway)
                

(Flux) : (EC2 Privée) boto3.client('s3') -> (Route Table) -> (Match pl-12345) -> (Envoie le trafic (privé) au vpce-67890) -> (AWS Backbone) -> (Service S3).

(Avantages) : 1. Sécurité (le trafic ne quitte pas AWS). 2. FinOps (Coût) (C'est GRATUIT, et cela vous évite de payer les frais $/GB (Data Processed) d'un NAT Gateway).

2.2. Objets (Données)

L'Objet (Object) est l'entité fondamentale (le "fichier") que vous stockez dans S3. S3 est un service "Key-Value" (Clé-Valeur).

Structure d'un Objet

Types d'Objets & Métadonnées

(Important) : S3 est "agnostique". Il ne "sait" pas ce qu'est un .jpg ou un .csv. Il ne stocke que des bytes.

C'est la métadonnée Content-Type (que vous (client/SDK) fournissez à l'upload) qui "dit" au navigateur (client) comment interpréter ces bytes.

• (Métadonnée Système) : Gérées par S3/HTTP (ex: Content-Type: image/jpeg, Content-Length: 1024, ETag: "checksum...").
• (Métadonnée Utilisateur) : (Optionnel) Ajoutées par vous (à l'upload). Doivent commencer par x-amz-meta- (ex: x-amz-meta-user-id: 12345).

2.3. Clés (Object Keys) & Préfixes (Pseudo-Dossiers)

Convention de Nommage (La Clé)

La "Clé" est le chemin (nom) complet de l'objet (max 1024 bytes, UTF-8). C'est l'identifiant unique (PK) dans un bucket.

Le Mythe des "Dossiers" (Préfixes)

(Piège n°2) : Il n'y a PAS de "dossiers" (répertoires) dans S3. S3 est un "Flat Namespace" (espace de nom plat).

Le caractère / (slash) n'est pas un séparateur de dossier. C'est juste un caractère (valide) dans le nom de la clé.

Exemple (Contenu d'un Bucket) :

                    (Clé 1) = "rapports/ventes/2024/janvier.pdf"
                    (Clé 2) = "rapports/ventes/2024/fevrier.pdf"
                    (Clé 3) = "index.html"
                    (Clé 4) = "images/logo.png"
                

(La Réalité) : Ce bucket contient 4 objets (clés). Il ne contient pas de "dossier" rapports/.

Simulation (Prefix & Delimiter)

La Console AWS (et les API) simulent des dossiers en utilisant le / comme Délimiteur (Delimiter).

Quand vous "Listez" (ListObjects) le bucket avec :

• Préfixe : rapports/ventes/2024/
• Délimiteur : /

S3 (l'API) vous renvoie :

• (Objets) : janvier.pdf, fevrier.pdf
• (CommonPrefixes) : (Aucun)

(Bonne Pratique) : Toujours utiliser des préfixes (/) logiques (app/user/id/) pour organiser les données (facilite le listage, le sharding (performance) et les règles (Lifecycle, IAM)).

2.4. Classes de Stockage (Tiering)

S3 offre différentes "Classes" (Tiers) de stockage, qui équilibrent Coût (Stockage GB/mois), Coût (Accès/Retrieval), et Latence (Temps d'accès).

(Note : Toutes les classes (sauf One Zone-IA) ont la même Fiabilité (Durabilité) de 11 9s (2.1)).

Archivage Automatique (Lifecycle & INT)

• 1. S3 Lifecycle Policy : (Manuel) Vous créez une Règle (ex: "IF préfixe=/logs/, THEN (Après 30j) -> Transition (vers Standard-IA), THEN (Après 90j) -> Transition (vers Glacier Deep Archive), THEN (Après 3650j) -> Expire (Delete)").
• 2. S3 Intelligent-Tiering (Classe) : (Automatique) (Recommandé) Vous stockez l'objet dans la classe "INT". S3 (IA) monitore l'accès (sans frais de retrieval) et le déplace (automatiquement) entre les tiers (Standard, IA, Glacier Instant) pour vous.

2.5. Consistency Model (Modèle de Cohérence)

(Mise à jour majeure de 2020) C'est un changement fondamental d'AWS S3. (L'ancienne "Eventual Consistency" est (presque) morte).

"Strong Read-after-Write Consistency" (Cohérence Forte)

S3 garantit désormais une cohérence forte (Strong Read-after-Write) pour toutes les opérations (PUT, GET, DELETE, LIST) dans toutes les Régions.

"Ce que vous écrivez (Write) est ce que vous lirez (Read) immédiatement après."

Impacts sur les Workloads

(Impact) : Simplification massive des applications (Data Lakes, Big Data). Plus besoin d'utiliser des "caches de consistance" (ex: DynamoDB, Redis) pour savoir si un objet S3 *existe vraiment* (ce qui était nécessaire avant 2020 pour les LIST ou DELETE).

1.2. Pourquoi utiliser S3 ? (Cas d'Usage)

S3 est utilisé lorsque vous avez besoin de stocker des "fichiers" (objets) de manière fiable, scalable, et économique, accessibles via une API HTTP universelle (s3:PutObject, s3:GetObject).

• Stockage de Fichiers (Assets) : Le cas d'usage principal. Stocker les "user uploads" (photos de profil, vidéos), les assets (CSS, JS, images) d'un site web, les logs (.log, .gz) des serveurs (EC2, ALB, CloudTrail).
• Data Lakes (Lac de Données) : C'est la fondation des Data Lakes sur AWS. C'est le "réceptacle" (pas cher, illimité) pour toutes les données brutes (JSON, CSV, Parquet, IoT streams) avant qu'elles ne soient nettoyées (ETL) et analysées (Analytics).
• Backups & Disaster Recovery (DR) : C'est la destination "par défaut" pour tous les backups :
  • Snapshots EBS (EC2)
  • Snapshots RDS (Base de données)
  • pg_dump (Exports BDD)
  • Archives (via Lifecycle Policies vers S3 Glacier).
• Hébergement de Site Web Statique (Static Web Hosting) :
  • Stocker (et servir) directement (via HTTP) un site web statique (ex: un build React, Vue, Angular, ou HTML/CSS). (L'option "Static Website Hosting" du bucket).
• Architectures Serverless & Big Data :
  • S3 sert de Trigger (Déclencheur) (ex: s3:ObjectCreated) pour AWS Lambda (ex: "Dès qu'un .jpg est uploadé, déclenche cette Lambda pour créer un thumbnail").
  • S3 sert de Source et de Destination pour les services Big Data (EMR, Glue, Athena).

1.3. S3 comme "Hub" Central des Données AWS

Dans AWS, S3 n'est pas "juste" un disque dur. C'est le "hub de données" (ou "databus") central (régional) qui connecte (presque) tous les autres services.

S3 Glacier Flexible Retrieval (Ex: "S3 Glacier")

L'archive "classique".

• Usage : Backups (où une attente de quelques minutes/heures est OK).
• Retrieval (Latence) :
  • Expedited : 1-5 minutes (Coûteux).
  • Standard : 3-5 heures (Défaut).
  • Bulk : 5-12 heures (Gratuit, si < 10% / mois).
• Min Durée : 90 jours.

S3 Glacier Deep Archive

Le stockage le moins cher du cloud AWS.

• Usage : Rétention légale (Compliance), remplacement des bandes (Tapes) LTO. Données "écrire 1 fois, ne jamais lire (sauf audit)".
• Retrieval (Latence) :
  • Standard : < 12 heures.
  • Bulk : < 48 heures.
• Min Durée : 180 jours.