EC2 Instance Store

EC2 Instance Store (anciennement appelé "ephemeral storage") est le stockage bloc local physiquement attaché à l'host EC2 hyperviseur sur lequel votre instance tourne. Contrairement à EBS (network-attached), Instance Store offre des performances IOPS/throughput extrêmes (NVMe SSD jusqu'à plusieurs millions IOPS) mais perd toutes les données au stop/terminate de l'instance, lors d'un host failure, ou lors d'une live migration.

Caractéristiques : (1) NVMe SSD local sur la plupart des familles d'instances modernes (i3, i3en, i4i, i4g, m5d, m6id, c5d, c6id, r5d, r6id, x1d, etc.) ; (2) capacité varie de 50 GB à 30+ TB selon famille ; (3) gratuit (inclus dans le prix instance) ; (4) IOPS lecture jusqu'à 3 million+ sur i4i.32xlarge ; (5) latency <100 μs ; (6) jamais sauvegardable via snapshots (contrairement EBS) ; (7) non transférable entre instances (lié à l'host physique).

Lifecycle data — données perdues sur : (1) instance stop ; (2) instance terminate ; (3) underlying hardware failure (rare mais possible) ; (4) instance retirement (when AWS schedules host maintenance — pas de live migration possible pour instances avec Instance Store). Données conservées sur : (1) reboot OS-level ; (2) reboot instance via API.

Cas d'usage parfaits : (1) caching layer (Redis, Memcached) — données reconstruites depuis source si perdues ; (2) scratch space pour processing (Spark shuffle, ETL temp files, ML training intermediate data) ; (3) buffer pour streaming ingestion avant flush vers S3/EBS ; (4) databases avec replication built-in (Cassandra, MongoDB replica set, Elasticsearch — autre noeud répliqué offre durabilité) ; (5) HPC compute avec working set ; (6) gaming session servers ; (7) high-frequency trading low-latency.

À NE PAS utiliser pour : (1) databases primary single-node (perte data garantie au prochain stop/failure) ; (2) any data not backed up or reconstructible ; (3) workloads needing snapshot/backup native ; (4) workloads needing to move data entre instances/régions facilement.

Familles d'instances et capacités exemples : i4i.16xlarge = 4× 3750 GB NVMe SSD (15 TB local), c6id.8xlarge = 2× 950 GB, r6id.16xlarge = 2× 1900 GB. Vérifier toujours "Instance Store Volumes" dans la doc.

Monitoring : EBS metrics ne s'appliquent pas, il faut monitorer disk IOPS via OS-level CloudWatch agent metrics ou monitoring tools (Datadog, Prometheus node exporter).

Alternative moderne : pour workloads needing high IOPS persistent, EBS io2 Block Express (jusqu'à 256k IOPS, sub-ms latency) ou io2 (64k IOPS). Pour temporary storage at scale avec snapshots, EFS ou FSx for Lustre. Compétences SAA-C03, DEA-C01.