Три больших облака решают одну и ту же задачу — иметь переиспользуемый шаблон для запуска одинаковых машин — своими подходами и со своей терминологией. Знание соответствий — первый шаг к мультиоблачной стратегии без трения.
В AWS это AMI (Amazon Machine Image); в Azure — Managed Image и, прежде всего, Azure Compute Gallery (ранее Shared Image Gallery); в Google Cloud — Custom Image. Все они инкапсулируют преднастроенный загрузочный диск, но отличаются тем, как версионируются, публикуются и распространяются.
Соответствия одним взглядом
| Понятие | AWS | Azure | Google Cloud |
|---|---|---|---|
| Образ машины | AMI | Managed Image | Custom Image |
| Каталог или галерея | Нативного нет: теги и SSM | Azure Compute Gallery | Image Family |
| Управляемое версионирование | Вручную, по имени и тегам | Нативно в Gallery | Image Family: последний в семействе |
| Мультирегиональная раздача | Копия AMI | Реплики в Gallery | Образы глобальны по умолчанию |
| Базовое хранилище | Снимки EBS | Managed Disks | Persistent Disk |
| Шифрование | KMS | Ключи платформы или клиента | Управляемые Google или CMEK |
Функциональные соответствия образов машин в трёх больших облаках.
AWS AMI: фактический стандарт
AMI — вероятно, самый известный формат образа с самой большой экосистемой. Его сила в зрелости: огромный каталог, интеграция с EC2 Image Builder, Marketplace и колоссальное сообщество. Историческая слабость — отсутствие нативной галереи образов с управляемым версионированием: версионирование и мультирегиональная раздача решаются соглашениями об именах, тегами, SSM Parameter Store и явными копиями между регионами.
Azure Compute Gallery: версионирование и реплики из коробки
Azure сделала серьёзную ставку на управление образами. Compute Gallery нативно даёт определения образов, версии и автоматические реплики в несколько регионов, плюс детальное управление доступом. Для крупных организаций, которым нужно упорядоченно раздавать образы по командам и регионам, это очень удобная модель. Плата за неё — чуть более крутая кривая освоения понятий.
GCP Custom Image: глобальная простота
Google Cloud выделяется простотой. Её образы глобальны по умолчанию — не нужно копировать их регион за регионом, — а понятие Image Family элегантно решает версионирование: вы указываете на семейство и всегда получаете последний неустаревший образ. Минималистичная модель, снижающая трение, особенно привлекательна для команд, ценящих операционную простоту.
Мультиоблачная стратегия: один шаблон, три образа
Если вы публикуете или разворачиваете в нескольких облаках, поддерживать три отдельных процесса сборки — боль. Ответ отрасли — Packer: единый шаблон с общими provisioners и блоком source на каждое облако, способный параллельно выпускать AMI, Managed Image и Custom Image из одного описания.
- Переиспользуйте одни и те же скрипты установки и усиления во всех трёх облаках.
- Снижайте расхождение сред: одна конфигурация, три назначения.
- Версионируйте согласованно, по общей схеме имён и метаданных.
- Автоматизируйте публикацию в каждую галерею: Gallery, Image Family, теги и SSM.
Что выбрать?
Абсолютного победителя нет; всё зависит от контекста. Нужна экосистема и зрелость — AWS. Нужно корпоративное управление образами с нативным версионированием и репликами — блистает Compute Gallery от Azure. Цените простоту и глобальный охват без копий — GCP. А если вы живёте в нескольких облаках, ответ — не платформа, а практика: описывайте образы как код и собирайте их переносимо.
Часто задаваемые вопросы
Можно ли напрямую перенести AMI из AWS в Azure или GCP?
Напрямую нет: форматы и базовые хранилища различаются. Обычно образ пересобирают в каждом облаке из общего шаблона, например с помощью Packer, либо импортируют диск через процессы импорта конкретного провайдера.
У какого облака лучшее версионирование образов?
Azure Compute Gallery даёт самое полное управляемое версионирование из коробки; GCP элегантно решает это через Image Families; AWS требует больше собственных соглашений, хотя и очень гибок.
Стоит ли мультиоблачная стратегия образов усилий?
Если вы работаете в нескольких облаках ради суверенитета данных, отказоустойчивости или чтобы не зависеть от поставщика — да. Ключ в том, чтобы использовать образы как код и не множить трудозатраты на поддержку.
В imaxe.cloud мы закладываем переносимость на этапе проектирования, чтобы ваши развёртывания не зависели от одного облака.
