Что произойдёт с instance store при reboot, stop и terminate EC2?

Instance Store: поведение при reboot, stop и terminate

Instance store — локальные физические диски хоста EC2 (NVMe SSD или HDD в зависимости от instance type). Производительность выше EBS (миллионы IOPS для NVMe instance store), но lifecycle привязан к физическому хосту — это ключевое отличие.

Поведение по операциям

• Reboot: инстанс остаётся на том же физическом хосте. Данные instance store сохраняются. Операционная система перезагружается, но диск не меняется.
• Stop → Start: инстанс может быть перемещён на другой физический хост (AWS не гарантирует тот же). Данные instance store полностью теряются.
• Hibernate: аналогично Stop — данные instance store теряются при hibernation/resume.
• Terminate: инстанс удаляется, данные instance store теряются безвозвратно.
• Hardware failure: если физический хост или диск выходит из строя, данные теряются без возможности восстановления из instance store.

Instance types с NVMe instance store

i3.xlarge    -> 1× 950 GB NVMe SSD (~3.3M IOPS random 4KB read)
i3en.3xlarge -> 1× 7500 GB NVMe SSD
c5d.large    -> 1× 50 GB NVMe SSD (compute-optimized with local disk)
r5d.xlarge   -> 1× 150 GB NVMe SSD (memory-optimized with local disk)

# Монтирование instance store NVMe (Amazon Linux 2)
lsblk  # найти nvme1n1 (nvme0n1 = EBS root)
mkfs.xfs /dev/nvme1n1
mount /dev/nvme1n1 /mnt/instance-store
echo '/dev/nvme1n1 /mnt/instance-store xfs defaults,nofail 0 2' >> /etc/fstab

Безопасные use cases для instance store

SAFE:
  Build artifact cache (CI/CD runner)    -> потеря = следующий build перепостроит
  Spark/Hadoop shuffle data              -> потеря = задача перезапустится
  Redis cache (если данные воспроизводимы) -> потеря = cache miss, cold start
  Replicated Cassandra/ScyllaDB node     -> потеря = данные реплицированы на другие nodes
  Temporary ML training scratch space    -> потеря = checkpoint с S3

UNSAFE:
  Primary PostgreSQL data directory      -> потеря = production data loss
  Kafka log storage без репликации       -> потеря = сообщения потеряны
  User uploads без sync в S3             -> потеря = файлы исчезли
  Session state без Redis/ElastiCache    -> потеря = все пользователи разлогинены

Паттерн: Cassandra с instance store

# cassandra.yaml — хранение данных на instance store
data_file_directories:
  - /mnt/instance-store/cassandra/data
commitlog_directory: /mnt/instance-store/cassandra/commitlog

# При замене ноды (stop/start) данные стримятся с живых нод:
# nodetool rebuild -- <datacenter>
# Cassandra replication factor >= 3 обязателен для безопасного использования

Подводные камни

• Воспринимать instance store как «бесплатный EBS»: он не является персистентным хранилищем и не подходит для production данных без репликации на уровне приложения.
• Записывать uploads, очередь задач или единственную копию БД на instance store: stop/start или terminate превращается в data loss incident без возможности восстановления.
• Не монтировать instance store в user data скрипте: после reboot точка монтирования сохранится (диск тот же), но после stop/start — нет. Нужна проверка наличия данных в user data / init script.
• fstab запись без nofail: если instance store NVMe недоступен (stop/start на новом хосте без instance store), система не загрузится.
• Рассчитывать на instance store для EBS-Only instance types: t3, m5, c5 (без суффикса 'd') не имеют локальных дисков вообще.
• Игнорировать Amazon Linux 2023 NVMe naming: диски могут появляться как /dev/nvme1n1 или /dev/nvme2n1 в зависимости от порядка инициализации — не хардкодить имя диска, использовать блочное устройство по UUID.

• Ожидать сохранения instance store после stop/start.
• Хранить единственную копию критичных данных на ephemeral disk.
• Не учитывать host failure как причину потери данных.

• Объясняет lifecycle reboot, stop и terminate.
• Отличает instance store от EBS.
• Называет безопасные сценарии использования.