Остановка и перезапуск Spot‑инстансов AWS
persistent
```. Ниже — пошаговая инструкция, чек‑листы, SOP и ответы на частые вопросы.

## Быстрые ссылки
- Ограничения при остановке Spot‑инстанса
- Остановка и перезапуск Spot‑инстансов
## Ограничения при остановке Spot‑инстанса
Spot‑инстансы работают иначе, чем on‑demand или reserved. Их основная цель — использовать неиспользуемую ёмкость AWS за низкую цену. Главная особенность — возможная прерываемость работы. Это делает их хорошими для коротких, прерываемых задач, batch‑запусков и распределённых воркфлоу.
Однако Spot‑инстанс может жить долго, если ваш рабочий процесс допускает случайные рестарты. На практике рестарты для многих типов инстансов происходят редко — иногда несколько раз в месяц или реже. Тем не менее для долгосрочных нагрузок обычно лучше рассмотреть Reserved Instances или EC2 Savings Plans.
Начиная с января 2020 года AWS поддерживает остановку и перезапуск Spot‑инстансов. При остановке инстанс выключается, а EBS‑том остаётся прикреплённым и доступен при следующем старте. Чтобы иметь возможность останавливать и перезапускать Spot‑инстанс, он должен соответствовать трём требованиям:
- Не быть частью Auto Scaling Group.
- Быть EBS‑backed (корневой диск — EBS).
- Запрос на инстанс должен иметь модификаторpersistent , то есть сам запрос помечен как persistent. Модификатор ``persistent`` выбирается при запуске. Он означает: если AWS прервёт инстанс, платформа попытается автоматически восстановить его на следующем подходящем ресурсе. Для управляемых рабочих нагрузок это удобная настройка. Важно: модификатор persistent исключает состояние «hibernate» в настройках выключения — Hibernate обычно не используется для Spot‑инстансов. ## Как остановить и запустить Spot‑инстанс 1. При запуске Spot‑инстанса в консоле EC2 под настройками запроса выберите опцию persistent. Это обязательный шаг. 2. Убедитесь, что корневой том — EBS, и что инстанс не входит в Auto Scaling Group. 3. На странице инстанса в консоли EC2 используйте стандартные кнопки «Stop» и «Start». После остановки поведение идентично остановленному on‑demand‑инстансу: EBS‑том остаётся, IP‑адрес (если был приватный) сохраняется, публичный IP меняется, если он не Elastic.  4. Через AWS CLI можно остановить инстанс из скрипта: aws ec2 stop-instances –instance-ids i-0123456789abcdef0
5. Для перезапуска используйте `start-instances` или соответствующую кнопку в консоли.

## Практические рекомендации
- Планируйте сохранение состояния приложения на EBS или в удалённом хранилище (S3, RDS). Не рассчитывайте на постоянный локальный диск.
- Если нужен фиксированный публичный IP — используйте Elastic IP; при stop/start динамический публичный IP изменится.
- Для долгоживущих баз данных используйте Multi‑AZ и регулярные снимки (snapshots).
- Если вы управляете несколькими инстансами — автоматизируйте управление через Terraform, CloudFormation или автоматические скрипты CLI/API.
## SOP: остановка Spot‑инстанса (короткая версия)
1. Убедиться, что инстанс не в Auto Scaling Group.
2. Проверить, что корневой том — EBS.
3. Убедиться, что запрос помечен какpersistent
4. Сделать snapshot EBS (по желанию) для быстрого восстановления.
5. Выполнить: `aws ec2 stop-instances --instance-ids `.
6. Проверить состояние в консоли или CLI: `aws ec2 describe-instances --instance-ids `.
## Чек‑листы по ролям
- DevOps / SRE:
- Проверить модификатор запроса.
- Автоматизировать stop/start через CI/CD или SSM.
- Настроить мониторинг и алерты на рестарты.
- Разработчик:
- Гарантировать идемпотентность процессов при рестарте.
- Сохранать состояние в внешнем хранилище.
- Менеджер проекта:
- Оценить риск прерываемости для бизнес‑логики.
- Сравнить стоимость Spot vs Reserved для долгосрочных задач.
## Когда это не подойдёт (контрпример)
- Если приложение не переносит прерываний и не может быстро восстановить состояние — Spot не подойдёт.
- Если нужен постоянный публичный IP без Elastic IP — остановка/запуск приведёт к смене IP.
- Авто‑скейлинг с управляемыми правилами может конфликтовать с ручной остановкой инстансов.
## Мини‑методология выбора
1. Определите критичность прерывания (низкая/средняя/высокая).
2. Если низкая — используйте Spot с persistent и резервными snapshot'ами.
3. Если средняя — комбинируйте Spot и on‑demand или используйте Auto Scaling с mixed policy.
4. Если высокая — выберите Reserved или Savings Plans.
## Decision flowchart
flowchart TD A[Нужно ли приложение быть всегда доступным?] –>|Да| B[Не использовать Spot] A –>|Нет| C[Можно ли переносить состояние?] C –>|Да| D[Использовать Spot с persistent] C –>|Нет| B D –> E{Долговременное развертывание?} E –>|Да| F[Рассмотреть Reserved / Savings Plans] E –>|Нет| G[Spot — подходящий выбор]
## Критерии приёмки
- Инстанс успешно останавливается и переводится в состояние Stopped.
- EBS‑том оставлен нетронутым и доступен для attach при старте.
- При старте инстанса система возвращает требуемые службы в рабочее состояние в допустимое время RTO.
## Тесты и приёмочные сценарии
- Тест 1: Остановить Spot‑инстанс и запустить через 10 минут — проверка целостности данных на EBS.
- Тест 2: Проверить поведение при прерывании AWS (симулировать) — убедиться, что запрос persistent корректно перезапускает инстанс.
- Тест 3: Проверить смену публичного IP при stop/start без Elastic IP.
## Особые случаи и рекомендации безопасности
- Храните ключи и секреты в AWS Secrets Manager или Parameter Store, а не на локальном диске инстанса.
- Настройте IAM‑роли с минимальными правами для инстанса.
## Часто задаваемые вопросы
### Можно ли перевести уже запущенный Spot‑инстанс в persistent без удаления и пересоздания?
Обычно модификатор persistent задаётся при создании запроса. Изменить тип запроса для уже запущенного инстанса не всегда возможно — в большинстве случаев требуется пересоздать запрос.
### Сохраняется ли диск при перезапуске после stop?
Да. При остановке EBS‑том остаётся, и данные сохраняются. При следующем старте том будет подключён заново.
### Можно ли использовать Hibernate с Spot‑инстансами?
Нет. Опция persistent исключает использование Hibernate как поведения при остановке.
Итог: Spot‑инстансы хорошо подходят для прерываемых и экономичных сценариев. При соблюдении условий (EBS, не в ASG, persistent) вы можете безопасно останавливать и перезапускать их, но планируйте резервное хранение состояния и автоматизацию.