Как создать кастомный AMI из существующего EC2 и запустить новый экземпляр

Коротко о терминах

• AMI — образ машины AWS, содержащий шаблон корневого тома, параметры запуска и (опционально) скрипты для инициализации. Используется для запуска EC2‑экземпляров.
• EC2‑экземпляр — виртуальная машина в AWS, запущенная на основе AMI.

Зачем создавать кастомный AMI

• Быстрая и воспроизводимая развертка идентичных серверов.
• Предварительно настроенное окружение (пакеты, конфигурации, патчи).
• Средство стандартизации образов для команд разработки, тестирования и продакшна.

Важное: AMI — это метаданные и снимки (snapshots) томов. После удаления AMI снимки можно удалить отдельно; это повлияет на восстановление экземпляров, но не на уже запущенные машины.

Что потребуется

1. AWS аккаунт с правами на просмотр EC2 и создание AMI и ключей доступа.
2. Запущенный EC2‑экземпляр, который станет «исходником» для AMI.

План действий (вкратце)

1. Авторизоваться в AWS Console.
2. Найти EC2 -> Running instances.
3. Выбрать экземпляр -> Actions -> Image -> Create Image.
4. Настроить имя, описание и размер корневого тома -> Create Image.
5. Дождаться состояния AMI = available.
6. Выбрать My AMIs -> Launch -> выбрать тип, настройки, security group, key pair -> Launch.

Подробные шаги

Авторизация в AWS

Перейдите на страницу входа в AWS и войдите под учётной записью с нужными правами.

Навигация к EC2

1. В консоли нажмите “Services” и введите “EC2” в поиске.

2. В панели EC2 откройте “Running instances”.

Создание AMI из экземпляра

1. Выберите экземпляр, который вы хотите сохранить как образ.
2. Нажмите Actions → Image → Create Image.

3. На экране Create Image укажите уникальное имя и описание. При необходимости измените размер корневого тома.

4. Нажмите Create Image. Статус нового образа будет сначала “pending”; подождите, пока он станет “available”.

Примечание: Создание AMI может занять несколько минут в зависимости от объёма данных на корневом томе.

Запуск нового EC2 из AMI

1. В левой панели EC2 перейдите в “Instances”.

2. Откройте ленту “My AMIs” — здесь перечислены ваши образы.

3. Выберите AMI и нажмите Launch. Выберите подходящий тип инстанса (например, t2.micro для Free Tier).

4. На экране конфигурации можно оставить значения по умолчанию или настроить сеть, storage и IAM‑роль.

5. При необходимости измените размер корневого тома (в примере — 30 GiB).

6. Добавьте теги для идентификации экземпляра.

7. Настройте security group: можно выбрать существующую или создать новую. Убедитесь, что открыты только необходимые порты (например, 22 для SSH).

8. Нажмите Review and Launch → Launch. При запуске выберите key pair для SSH‑доступа или создайте новый и скачайте приватный ключ.

9. Подождите перехода состояния экземпляра в “running” и затем подключитесь по SSH или через AWS Session Manager.

Проверки и критерии приёмки

• AMI показан в My AMIs со статусом available.
• Новый EC2 успешно запускается из этого AMI.
• Все необходимые службы и приложения на новом экземпляре работают корректно.
• Сеть и правила брандмауэра соответствуют политике безопасности.

Рекомендации по безопасности и управлению образами

• Ограничьте доступ к AMI: делайте приватными, если образ содержит чувствительные данные.
• Не включайте в AMI секреты (пароли, ключи API). Если это произошло, пересоздайте AMI после удаления секретов и ротирования ключей.
• Храните список версий AMI и используйте наименование с тегами версии (example-app-v1.2.0).

Что важно учесть (когда метод НЕ подходит)

• Если экземпляр содержит временные или уникальные идентификаторы (например, SSH known_hosts, машины‑ID), очистите их перед созданием AMI.
• Не используйте AMI для миграции между регионами без копирования образа (AMI привязаны к региону).
• Если нужен полностью независимый конфиг при старте, добавляйте скрипты инициализации (user data), а не полагайтесь только на образ.

Процедура (микро‑SOP) — быстрое руководство для инженера

1. Проверить, что на исходном EC2 нет секретов и временных данных.
2. Остановить ненужные процессы (по желанию) или сделать чекпоинт.
3. Actions → Image → Create Image, задать имя и размер тома.
4. Подождать available → перейти в My AMIs → Launch.
5. Выбрать тип, security group, key pair → Launch.
6. Проверить работоспособность приложения на новом экземпляре.
7. Пометить AMI тегом и обновить документацию.

Ролевые чеклисты

• Администратор:
  • Создал AMI, проверил теги и права доступа.
  • Проверил наличие необходимых снапшотов.
• DevOps:
  • Убедился в корректности cloud‑init/user data.
  • Протестировал запуск в staging.
• Разработчик:
  • Проверил, что зависимости и окружение соответствуют требованиям приложения.

Мини‑методология версиирования образов

1. Формат имени: компонент-версия-датa (например, webapp-v1.3-2025-11-18).
2. Теги: environment=staging|prod, created_by, changelist.
3. Ротация: хранить N последних версий, удалять старые после проверки совместимости.

Матрица рисков и смягчение

• Утечка секретов: ревью образа и удаление секретов перед созданием; ротирование ключей.
• Потеря возможности восстановления: не удалять снапшоты, пока экземпляры не протестированы.
• Несовместимость версий: тесты при запуске в staging перед продом.

Краткий глоссарий (1‑строчно)

• Снапшот — сохранённое состояние тома EBS, используется для создания AMI.
• User data — скрипты/команды, выполняемые при первом запуске экземпляра.

Часто встречающиеся ошибки и как их избежать

• Образ не запускается: проверьте совместимость типа инстанса и параметры сети.
• Нет доступа по SSH: проверьте security group и правильность key pair.
• Приложение ведёт себя иначе: удалите временные файлы и кеш перед созданием AMI.

Заключение

Мы показали полный процесс создания кастомного AMI из запущенного EC2‑экземпляра и последующего запуска нового экземпляра из этого образа. Использование AMI упрощает масштабирование и стандартизацию инфраструктуры, но требует дисциплины при управлении секретами и версиями.

Сводные рекомендации:

• Очищайте экземпляр перед созданием AMI.
• Документируйте версии и теги образов.
• Тестируйте новые образы в staging перед продакшеном.