☁️ Storage Systems — Chapitre 18 : Principes du Cloud Storage

• Séparer disques OS, data, logs pour bases critiques.
• Aligner type de volume avec workload : généraliste, provisioned IOPS, throughput optimisé.
• Activer snapshots réguliers mais gouvernés.
• Surveiller queue length, latency, burst credits si applicable.
• Prévoir restore cross-zone/cross-region pour DR.

• Débit souvent lié à la taille ou au tier provisionné.
• Les petits fichiers et metadata peuvent coûter plus cher en latence.
• SMB/NFS exigent réseau privé, DNS, firewall et identité.
• RWX Kubernetes est pratique mais pas toujours adapté aux bases transactionnelles.

• Versioning pour conserver anciennes versions.
• Lifecycle pour transition/expiration.
• Replication cross-region ou cross-account.
• Object Lock / immutability selon service.
• Events vers queues/functions.
• Encryption avec clés provider ou KMS client.

s3://company-prod-lake/raw/events/year=2026/month=05/day=03/part-0001.parquet
s3://company-backups/postgresql/prod/2026-05-03/base.tar
s3://company-media/products/sku-12345/image-main.webp
s3://company-logs/nginx/dt=2026-05-03/hour=10/access.json.gz

1. Identifier objet/prefix/version.
2. Lancer demande de restore archive.
3. Attendre disponibilité temporaire.
4. Copier vers classe hot si besoin d'exploitation.
5. Vérifier checksum et application.
6. Documenter délai réel.

• Minimum storage duration.
• Retrieval fees.
• Early deletion fees.
• Lifecycle transitions facturées selon provider.
• Inventaire et recherche plus difficiles si metadata pauvre.

Le placement détermine la latence, le blast radius, le coût de transfert et la conformité. Un disque bloc zonal, un filesystem régional et un bucket multi-region n'ont pas les mêmes propriétés.

• Cross-zone : protège contre panne zone.
• Cross-region : protège contre panne région ou contrainte DR.
• Cross-account/project : protège contre compromission du compte principal.
• Async replication : RPO non nul.
• Sync replication : latence et coût plus élevés.

La région impacte résidence des données, juridiction, latence utilisateur, coûts egress, services disponibles et exigences contractuelles.

• Replication multi-AZ.
• Erasure coding distribué.
• Checksums et scrubbing côté provider.
• Snapshots et backups.
• Object versioning et Object Lock.
• Cross-region replication.

• Un data lake avec petits JSON non compactés augmente les coûts de requêtes.
• Une politique versioning sans expiration garde toutes les anciennes versions.
• Un bucket répliqué en multi-region double presque la capacité et ajoute transfert.
• Un restore archive urgent peut coûter bien plus que prévu.

• Budgets et alertes par bucket/projet.
• Tagging obligatoire.
• Lifecycle par préfixe.
• Rapports objets non lus depuis X jours.
• Expiration multipart uploads incomplets.
• Dashboards egress et API calls.

1. Classer données par température d'accès.
2. Définir RTO restore.
3. Évaluer frais retrieval/API.
4. Créer lifecycle par préfixe.
5. Mesurer après 30/60/90 jours.

prefix: logs/nginx/
0-30 days: hot
31-180 days: cool
181-365 days: archive
after 365 days: delete unless legal hold

• Snapshots horaires/courts pour rollback proche.
• Snapshots journaliers/semaine/mois selon RPO.
• Expiration automatique.
• Copie cross-region/cross-account pour DR.

• Réplication par bucket/prefix.
• Versioning souvent nécessaire.
• Lag à monitorer.
• Attention aux suppressions répliquées.
• Tester failover applicatif.

1. Simuler indisponibilité région/source.
2. Restaurer données dans région DR.
3. Créer compute cible.
4. Basculer DNS/traffic.
5. Valider application.
6. Mesurer RTO/RPO.

La gestion de clés impacte disponibilité : désactiver ou perdre une clé KMS peut rendre les données illisibles. Les politiques KMS doivent être surveillées comme des éléments critiques.

• Restreindre par VPC/subnet/security groups.
• DNS privé stable.
• Pas d'exposition SMB/NFS publique.
• Latency et throughput entre zones à mesurer.

# Examples
nslookup storage.internal
curl -I https://bucket-endpoint
traceroute storage-endpoint
iperf3 for file services where possible
check firewall/security groups/routes/DNS

1. Choisir workload au hasard.
2. Restaurer dans réseau isolé.
3. Valider boot, données, application.
4. Mesurer RTO/RPO réel.
5. Corriger runbook et droits.

Les disques bloc cloud sont souvent zonaux. Utiliser WaitForFirstConsumer évite de créer un volume dans une zone incompatible avec le pod.

volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete

• PVC non supprimés après suppression d'app.
• Snapshots oubliés.
• EFS/Azure Files/Filestore provisionnés trop haut.
• Logs et backups dans buckets sans lifecycle.

• Surveiller latency p95/p99, queue depth, throughput.
• Séparer logs transactionnels si applicable.
• Tester restore PITR.
• Protéger backups par immutabilité ou compte séparé.
• Valider limites IOPS du type de stockage.

• Parquet/ORC pour analytics colonnaire.
• Iceberg/Delta/Hudi pour tables lakehouse.
• Partitionnement par date/tenant/domaine.
• Compression adaptée.
• Éviter millions de petits fichiers.

• VPN pour petits flux.
• Direct Connect/ExpressRoute/Interconnect pour flux importants.
• Mesurer latence et bande passante.
• Prévoir coûts egress lors du retour on-prem.

• Budget mensuel > seuil.
• Egress spike.
• Bucket public détecté.
• Snapshots sans tag/owner.
• Archive retrieval massif.
• Lifecycle rule disabled.

Tagging obligatoire : application, owner, environment, data_classification, retention, cost_center. Sans tags, FinOps devient de l'archéologie.

• Services disponibles dans la région.
• Souveraineté et conformité.
• Coût egress et API.
• Écosystème backup/analytics.
• Support Terraform/Kubernetes.
• Contrats et support.

• Aucun tag owner.
• Personne ne sait restaurer.
• Pas de budget par environnement.
• Logs d'accès désactivés.
• Rétention décidée par défaut technique, pas métier.

• Egress source ou destination.
• Permissions non migrées.
• Symbolic links/ACL incompatibles.
• Temps de sync delta sous-estimé.
• Checksum non vérifié.

1. Confirmer FS full dans OS.
2. Étendre volume cloud si possible.
3. Rescan OS.
4. Étendre partition/LVM/filesystem.
5. Ajouter alerte capacité.

1. Identifier bucket/service source.
2. Analyser access logs.
3. Vérifier CDN/cache miss.
4. Vérifier exfiltration possible.
5. Limiter policy si suspicion.
6. Créer budget alert spécifique.

1. Désactiver clé.
2. Révoquer sessions/tokens.
3. Auditer actions récentes.
4. Restaurer objets supprimés si versioning.
5. Rotation secrets.
6. Post-mortem IAM.

• Backup externe ou cross-account.
• Snapshots avec rétention.
• Object Lock/vault lock si critique.
• Replication testée.
• Restore drill réalisé.

• Alertes capacity, egress, public access, policy change.
• Runbooks incidents.
• Documentation owner et data classification.
• Table RPO/RTO par application.
• Revue mensuelle coûts et lifecycle.