IaaS на примере Amazon EC2: что именно мы арендуем в облаке и где заканчивается ответственность провайдера

Разбираем модель Infrastructure as a Service на примере Amazon EC2: из чего складывается облачная инфраструктура, какие экономические обещания подтверждаются, а какие остаются маркетингом, и почему главные риски IaaS — не технические, а организационные.

Облако не снимает с вас ответственность за железо — оно лишь переносит её в плоскость, где ошибки стоят дешевле в моменте, но дороже в последствиях.

Понятие Infrastructure as a Service обросло таким количеством презентационных слайдов, что стало почти бессодержательным. Между тем модель проста и вполне инженерна: провайдер владеет физическими серверами, сетями и дата-центрами, а клиент получает через интернет абстракцию над всем этим — виртуальные машины, диски, каналы — и управляет ей через API или консоль. Физическое железо не покупается, арендуется по факту потребления, капитальные затраты (CapEx) превращаются в операционные (OpEx).

Классический учебный пример такой модели — Amazon EC2, сервис виртуальных серверов внутри Amazon Web Services. Именно на нём удобно проверить, как устроена IaaS в реальности, включая то, о чём в обзорах обычно умалчивают.

Из чего состоит «инфраструктура как сервис»

Чтобы говорить предметно, стоит разложить IaaS на составляющие — иначе термин превращается в ведро, куда попадает всё подряд.

• Виртуализация. Гипервизор — слой ПО, разделяющий физический сервер на несколько изолированных виртуальных машин. Именно он позволяет упаковать десятки независимых клиентов на одно железо и сделать аренду экономически целесообразной для обеих сторон.

• Вычисления. Виртуальные машины с разными конфигурациями: число vCPU, объём оперативной памяти, наличие ускорителей. Под vCPU понимается условная единица процессорного времени, которую гипервизор выделяет виртуальной машине, — она не равна физическому ядру один к одному.

• Хранилище. Блочное (диски, «прикручиваемые» к виртуальной машине), файловое (общие файловые системы) и объектное (хранилище вида «ключ — значение», где вместо иерархии каталогов используется плоское пространство с метаданными).

• Сеть. Виртуальные сети, подсети, IP-адреса, балансировщики нагрузки, VPN, межсетевые экраны. В облаке сеть — это тоже программируемая абстракция, а не кабель в стойке.

• Управление и автоматизация. API, веб-консоль, CLI, инструменты управления конфигурацией. От качества этого слоя зависит, насколько инфраструктура воспроизводима: всё, что делается руками через интерфейс, однажды будет сделано с ошибкой.

• Безопасность. Управление доступом (IAM — Identity and Access Management, управление идентификацией и доступом), шифрование, системы обнаружения вторжений. Здесь важно понимать границу: провайдер отвечает за безопасность «облака», клиент — за всё, что он внутри него запускает.

Amazon EC2: что стоит за словом «сервер в облаке»

Amazon Elastic Compute Cloud запустили в 2006 году, и это был фактически первый массовый коммерческий сервис такого рода. Формулировка «аренда виртуальных серверов» верна, но описывает лишь верхушку.

Внутри EC2 — это набор связанных компонентов. Собственно инстансы — виртуальные машины, запущенные на физическом оборудовании в дата-центрах AWS. Диски — тома EBS (Elastic Block Store), блочное хранилище, которое живёт отдельно от виртуальной машины и переживает её перезапуск. Балансировщик нагрузки ELB распределяет трафик между инстансами, чтобы отказ одной машины не обрушил сервис. Автоматические группы масштабирования (ASG) поднимают и убирают инстансы в зависимости от нагрузки.

Собственно, это и есть минимальный рабочий набор для отказоустойчивого сервиса: распределить трафик, масштабировать вычисления, не потерять данные. Всё остальное — надстройки.

Что важно понимать про виртуализацию в AWS: у Amazon собственный стек — Nitro System, который выносит гипервизор, управление сетью и хранилищем на выделенные аппаратные компоненты. Это снижает накладные расходы на виртуализацию и позволяет отдавать клиенту почти всё физическое железо хоста. Вплоть до того, что есть инстансы bare metal — клиент получает целый сервер без промежуточного слоя виртуальных машин. Это не маркетинговая деталь: для ряда нагрузок (лицензирование по ядрам, требования регуляторов, специфические гипервизоры клиента) разница между «виртуалкой» и «голым железом» принципиальна.

Экономика: где правда, а где презентация

Главное обещание IaaS — отказ от капитальных затрат и «эластичность»: ресурсы наращиваются под пик и сжимаются после него. Формулировка корректная, но с оговорками.

Во-первых, «сжимается» — это обязанность, а не автоматика. Без настроенных ASG и без дисциплины выключения ненужных инстансов облако превращается в медленно растущий счёт за постоянно включённые машины. Возврат от аренды к собственному железу — тоже экономически обоснованный сценарий: при стабильной и предсказуемой нагрузке собственный парк может быть дешевле, чем несколько лет оплаты инстансов. Универсального ответа «аренда всегда выгоднее» не существует, и любой, кто утверждает обратное, сравнивает разные режимы эксплуатации.

Во-вторых, эклектика моделей оплаты. Помимо оплаты по факту (On-Demand), есть резервирование на срок и спотовые инстансы — аренда избыточных мощностей по сильно сниженной цене с условием, что провайдер может отобрать ресурс с кратким уведомлением. Спотовые инстансы годятся для прерываемых задач (рендеринг, обучение моделей, пакетная обработка) и категорически не годятся для всего, что должно работать бесперебойно. Это тот случай, когда экономия до 90% в рекламе честна технически, но применима к узкому классу нагрузок.

Риски IaaS: пять слабых мест

Оригинальный разбор выделяет пять групп проблем — и здесь перечень вполне реалистичный, хотя с оговорками.

Незакрытые уязвимости гостевой ОС. В IaaS операционная система виртуальной машины — зона ответственности клиента. Провайдер обновляет гипервизор и физическую инфраструктуру, но не вашу Ubuntu или Windows Server. Машина, поднятая в 2023-м и забытая, к 2026-му представляет собой коллекцию известных уязвимостей с публичными эксплойтами.

Теневая IT и расползание ресурсов. Когда каждый инженер может создать инстанс одной командой, инфраструктура начинает расти быстрее, чем её инвентаризация. Немониторимые машины без агентов, без ответственных и без тегов — это не гипотетическая угроза, а штатная ситуация в любой организации, где доступ к облаку раздаётся свободно.

Кража учётных данных. Утечка API-ключа или токена доступа опаснее, чем взлом сервера: атакующий действует легитимными средствами и неотличим от обычного сервиса в логах. Регулярная ротация ключей и отказ от долгоживущих статических токенов — базовая гигиена, которую массово нарушают.

Слишком широкие права в IAM. Политики доступа, выданные «на всякий случай», позволяют злоумышленнику после компрометации одной учётной записи двигаться дальше по инфраструктуре. Для шифровальщиков это прямой путь: захватил сервисный аккаунт с широкими правами — зашифровал всё.

Ошибки конфигурации хранилища. Публичные бакеты S3 (объектное хранилище AWS) остаются классикой жанра. Однако тут стоит поправить саму постановку: утечка данных Capital One 2019 года, которую часто цитируют в этом контексте, была связана с уязвимостью типа SSRF в веб-приложении файрвола, защищавшего облако, — механизм был иной, хотя корень проблемы тот же: доступность поставлена выше безопасности при конфигурации. История с открытыми бакетами, связанными с приложениями Facebook*, тоже реальна, но это случаи сторонних разработчиков, а не собственной инфраструктуры платформы. Путаница здесь не безобидная: она маскирует разные классы ошибок под одну «проблему S3».

Так что же такое EC2 на самом деле

Возвратимся к исходному вопросу. Amazon EC2 — это не «сервер, который вы берёте напрокат», а программируемый слой над огромным парком физического оборудования, где железо абстрагировано гипервизором, хранение и сеть отделены от вычислений, а всё вместе управляется через API. Именно эта декомпозиция и делает возможной мгновенную масштабируемость: диски не привязаны к машинам, трафик не привязан к конкретному серверу, вычисления можно добавлять и убирать независимо.

Плата за это — распределённая ответственность. AWS отвечает за то, что внутри дата-центра; клиент отвечает за всё, что он туда загрузил. И практика показывает, что подавляющее число крупных инцидентов в облаке возникает не из-за провайдера, а на этой границе: неверная политика доступа, забытый ключ, открытый бакет, неотключённая машина.

Заключительная мысль обзора — о том, что успешные стратегии не ограничиваются чистым IaaS, а сочетают его с колокацией, частным облаком и edge-вычислениями (обработкой данных ближе к источнику), — здравая. Гибридные схемы возникают не от хорошей жизни: у вывода нагрузок обратно есть вполне конкретные причины — задержки сети, требования к локализации данных, стоимость трафика на выход и юридические ограничения. Вопрос не в том, «переходить в облако или нет», а в том, какие конкретно компоненты инфраструктуры выгоднее держать на арендуемых мощностях, а какие — на своих. Ответ на этот вопрос всегда частный и всегда зависит от профиля нагрузки, а не от моды.

✴ Meta* — входит в перечень общественных объединений и религиозных организаций, в отношении которых судом принято вступившее в законную силу решение о ликвидации или запрете деятельности по основаниям, предусмотренным Федеральным законом от 25.07.2002 № 114-ФЗ «О противодействии экстремистской деятельности».