Облако: модели, аккаунт, деньги и соответствие AWS

Зачем это нужно

До сих пор все твои серверы жили на твоём компьютере: виртуальная машина в Multipass, контейнеры в Docker, кластер kind. Настоящие сервисы так не живут. Их запускают в облаке (cloud): это чужие серверы, диски и сети в больших дата-центрах, которые ты арендуешь на часы и минуты и которыми управляешь через интернет. Такой запуск нужен, чтобы сервис был доступен всем, а не только твоему ноутбуку. Без облака пришлось бы купить сервер, держать его в серверной и самому чинить железо.

Начнём с байки, которую знает каждый, кто работал с облаком. Новичок на учебном проекте создал виртуальную машину, поиграл час и закрыл ноутбук. Через две недели пришло письмо о счёте втрое больше ожидаемого. Машина стояла остановленной, и он был уверен, что «выключенное не платит». А платили два диска и зарезервированный адрес. Такие истории случаются не от глупости, а от того, что облако не спрашивает «точно ли тебе это ещё нужно». Поэтому в этом уроке мы сначала настраиваем деньги и доступы и только в следующем создаём ВМ.

ВМ (виртуальная машина, VM) это компьютер, который целиком существует как программа внутри другого компьютера, как квартира в многоквартирном доме: стены общие, а жильцы друг друга не видят. Ты уже делал такие в Multipass. В облаке ВМ выдают за минуту, и без неё сервису негде было бы работать.

На работе тебя спросят не «что такое IaaS» (модель, где провайдер даёт тебе ВМ, диски и сеть, а всё остальное ты делаешь сам; разберём ниже), а «почему счёт вырос втрое», «кто удалил бакет» (бакет, bucket, это хранилище файлов в облаке, как шкаф с ячейками на вокзале: кладёшь файл, получаешь по имени; подробно в уроке 6.2) и «чем это отличается от AWS, где мы работали раньше». Первая ошибка новичка в облаке стоит денег или утёкшего ключа.

Ты заведёшь аккаунт Yandex Cloud, поставишь бюджет-алерт (письмо, которое придёт, когда траты дойдут до порога: как сигнал «на карте осталась половина денег»), установишь консольную программу yc (управление облаком командами вместо кнопок в браузере), создашь сервисный аккаунт (учётку для программы, а не для человека, как служебный пропуск для робота: у него свои права, и его можно отключить, не трогая твой вход) и получишь таблицу соответствий Yandex Cloud и AWS (Amazon Web Services, самое известное облако), по которой часто спрашивают на собеседованиях.

Каталог (folder) это папка внутри облака, в которой лежат ресурсы одного проекта: так их проще считать и выдавать права (подробно в теории ниже).

Шаг проекта: аккаунт Yandex Cloud, каталог notes, сервисный аккаунт notes-deployer, бюджет-алерт и yc готовы; сами «Заметки» не меняются (остаются на версии 0.4.1).

Что нужно знать

Урок 1.3: пользователи и права: принцип минимальных прав тот же, что для пользователя notes на сервере: он владеет только своими данными и не является root.
Урок 2.1: адреса и маршруты: публичный адрес виден из интернета, приватный только внутри сети; между ними работает NAT (подмена адресов, как секретарь, который звонит наружу от имени всего офиса).
Урок 2.2: порты, TCP и SSH: SSH-ключи понадобятся уже в следующем уроке.
Урок 3.1: основы Git: для задания про ключ в публичном репозитории нужно понимать, что коммит остаётся в истории навсегда.

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

Картина целиком

Можно построить собственный конференц-зал: купить землю, здание, стулья, свет. Дорого и долго, зато всё твоё. А можно арендовать зал в бизнес-центре на нужные часы. Тогда здание, охрана и электричество на арендодателе, а ты платишь по счётчику и приносишь только своё выступление. Облако это аренда зала: провайдер (тот, кто сдаёт в аренду) строит дата-центры, ты берёшь ровно столько ресурсов, сколько нужно, и платишь за время использования.

Аренда порождает три вопроса. Кто за что отвечает: если в зале сломался свет, это арендодатель, а если ты забыл выключить проектор, счёт твой. Как арендодатель понимает, что ты это ты: у тебя нужен пропуск, и не всем сотрудникам стоит давать ключи от всех комнат. Вход человека защищает MFA (multi-factor authentication, вход в два шага: пароль плюс код из телефона; украденный пароль один не поможет). Раздачу прав называют IAM (Identity and Access Management: кто, что и с чем может делать, как список допусков на проходной). И сколько это стоит: счёт растёт молча, если оставить зал арендованным.

flowchart TD
    A["Ты<br>человек или программа"] -->|"логин + MFA<br>или ключ аккаунта"| B["Облако<br>организация → облако → каталог"]
    B --> C["Каталог notes<br>ВМ, диски, сети, бакеты"]
    C --> D["Биллинг<br>платёжный аккаунт → грант → счёт"]
    D --> E["Бюджет-алерт<br>письмо при 50% и 100% порога"]

На схеме видно путь сверху вниз: сначала доказываешь, кто ты, потом работаешь с ресурсами в каталоге, а всё созданное попадает в счёт, за которым следит алерт.

За урок ты разберёшь каждый блок этой схемы: что такое облако и виртуализация, кто за что отвечает (IaaS: провайдер даёт железо, остальное твоё; PaaS: провайдер даёт ещё и готовую среду для программы; SaaS: готовая программа, ты её только используешь, как почтовый сервис), где физически живут ресурсы (регион это город или страна, где стоят дата-центры провайдера, а зона это отдельное здание или зал внутри региона со своим питанием), из чего складывается счёт, как устроены права доступа (IAM), чем ключ отличается от пароля и как сопоставить всё это с AWS.

Теория

Что такое облако и почему оно так работает

Раньше, чтобы запустить сайт, компания покупала сервер, ставила его в стойку, подключала к сети и питанию. Пока сервер едет и настраивается, проходят недели. Если сайт вдруг стал популярным, докупить сервер быстро нельзя. Если популярность упала, железо простаивает, а деньги уже потрачены. Как избавиться от обеих проблем сразу?

Так же, как ты избавляешься от своей электростанции: подключаешься к общей сети и платишь по счётчику. Облако работает так же: ресурс появляется за минуту и исчезает, когда не нужен, а платишь только за время. Аналогия ломается в одном: счётчик воды не создаёт лишний водопровод, если ты ошибся в скрипте, а в облаке ошибка в скрипте может создать сотни платных ресурсов. Поэтому есть квоты и алерты (разберём ниже).

Внутри дата-центра стоят обычные физические серверы. На каждом работает программа-гипервизор (hypervisor): она делит один физический сервер на много изолированных виртуальных машин (virtual machine, ВМ). Каждая ВМ думает, что у неё свой процессор, память и диск, хотя на деле это доли общего железа. С виртуальной машиной ты уже работал: Multipass в уроке 1.1 тоже запускал ВМ, только на твоём Mac. Разница в масштабе: провайдер держит десятки тысяч серверов и раздаёт ВМ всем желающим.

Когда ты просишь у облака ВМ, происходит цепочка (vCPU это виртуальное ядро процессора, «рабочие руки» машины; ГБ это объём оперативной памяти):

flowchart TD
    A["Ты: создай ВМ<br>2 vCPU, 2 ГБ"] -->|"запрос по HTTPS<br>это и есть API облака"| B["Управляющая часть облака<br>кто ты, есть ли права,<br>квота и деньги"]
    B --> C["Выбор физического сервера<br>со свободными ресурсами"]
    C --> D["Гипервизор создаёт ВМ,<br>подключает диск и сеть"]
    D --> E["Ты получаешь адрес ВМ<br>и заходишь по SSH"]

Главное слово в этой схеме: API (application programming interface). Это набор запросов, которые понимает облако. Ты вводишь yc compute instance create ..., программа yc формирует запрос, добавляет к нему твой токен (подтверждение, что это ты) и отправляет в API. Через полминуты API отвечает: «ВМ создана, вот её идентификатор». То же самое ты сделал бы кнопкой «Создать ВМ» в консоли.

Прикинь сам: на ВМ из примера выше (2 vCPU, 2 ГБ) ты потратил час на эксперименты и сразу удалил её. Сколько ВМ ты арендовал: целый сервер или его долю, и сколько времени?

Долю одного физического сервера, и ровно один час: ВМ существует как программа на общем железе, а счёт идёт по времени её жизни.

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

Главное: облако это общий парк серверов, который гипервизор нарезает на ВМ по запросу в API, а ты платишь за время жизни ресурса.

Запрос в API можно отправить разными способами. Какими именно?

Консоль, CLI и API: три способа сказать облаку одно и то же

Создать ВМ можно кнопками в браузере, но кнопки нельзя повторить сто раз одинаково и нельзя положить в Git. Поэтому у облака несколько «дверей» в одну комнату.

Это как заказ в ресторане: можно сказать официанту лично (консоль в браузере), заполнить бланк заказа (CLI, команды в терминале) или отправить заказ через окошко доставки по строгой форме (API, запрос программы). Кухня одна, результат одинаков. Аналогия ломается в одном: официант простит неточность и переспросит, а API и CLI выполнят ровно то, что написано, даже если это ошибка.

Внутри облака работает только API: это набор адресов, по которым программа отправляет запросы по HTTPS («создай ВМ», «покажи диски»). Консоль в браузере и команда yc сами отправляют такие запросы за тебя. Поэтому всё, что можно сделать кнопкой, можно сделать командой, а потом и скриптом.

Команда yc compute instance list (список ВМ) разворачивается так: yc читает твой профиль (кто ты и какой каталог), отправляет в API запрос «покажи ВМ каталога notes», получает ответ и печатает таблицей. Если запрос отправлен не от твоего имени, а от сервисного аккаунта, облако проверит права этого аккаунта, а не твои.

Осторожно: «CLI это что-то другое, чем облако». Нет, это тот же API в удобной обёртке. Второе заблуждение: «в консоли безопаснее». Права и счёт одинаковы для всех трёх способов.

Прикинь сам: ты создал ВМ кликами в консоли, а коллега хочет получить такую же. Что ему нужно, чтобы повторить это без твоей помощи?

Команда yc или скрипт: консоль и yc отправляют один и тот же запрос в API, поэтому клики можно записать командами и положить в Git, а повторить клики один в один нельзя.

Главное: консоль, yc и скрипты это разные способы отправить один и тот же запрос в API, поэтому всё, что делается мышкой, записывается командой.

Мы научились создавать ресурсы. Теперь вопрос, кто отвечает за их работу: ты или провайдер?

Модели: IaaS, PaaS, SaaS, FaaS и общая ответственность

Не всем нужно управлять ВМ. Одному человеку хочется только базу данных, а как она работает внутри, ему безразлично. Поэтому облачные услуги делят по тому, сколько работы остаётся тебе, а сколько берёт на себя провайдер. От модели зависит, кого будить ночью, когда что-то сломалось.

Это как получить ужин. Купить продукты и готовить самому: вся работа твоя (IaaS). Заказать набор для готовки, где продукты нарезаны: ты только готовишь (PaaS). Прийти в ресторан: ты только ешь (SaaS). Аналогия ломается тем, что в облаке «продукты» ещё и подключены к сети, поэтому вопрос доступа (кто вообще может зайти на кухню) остаётся твоим в любой модели.

Четыре модели:

IaaS (Infrastructure as a Service, инфраструктура как услуга): провайдер даёт ВМ, диск и сеть. Операционная система, обновления, nginx и бэкапы на тебе. Пример: Compute Cloud в Yandex, EC2 в AWS.
PaaS (Platform as a Service, платформа как услуга): провайдер ведёт платформу целиком, ты приносишь код или данные. Пример: Managed PostgreSQL (управляемый PostgreSQL; в AWS это RDS). Провайдер делает бэкапы (запасные копии данных), патчи ОС (обновления системы с исправлениями уязвимостей) и автоматическое переключение на запасной сервер при сбое (failover: как запасной водитель, который садится за руль, когда основной заболел; подробно в уроке 6.4). Схему таблиц, индексы и запросы по-прежнему пишешь ты.
SaaS (Software as a Service, программа как услуга): готовая программа, ты только пользуешься: почта, Jira, GitHub.
FaaS (Function as a Service, «функция как услуга», её же называют serverless, «бессерверные»): ты приносишь одну функцию кода, она запускается по событию, платишь за число вызовов. Пример: Cloud Functions в Yandex, AWS Lambda. Серверы там, конечно, есть, просто ты о них не думаешь.

Разделение работы называется моделью общей ответственности (shared responsibility model). Граница проходит так: провайдер отвечает за безопасность самого облака (здания, железо, гипервизор), а ты за то, что запускаешь в облаке: правила сетевого доступа, права пользователей, данные и обновления ОС на своих ВМ.

	IaaS (ВМ)	PaaS (Managed PG)	SaaS (почта)
данные, доступы	ТЫ	ТЫ	ТЫ
схема БД, запросы	ТЫ	ТЫ	-
приложение	ТЫ	ТЫ (твой код)	провайдер
runtime, ПО	ТЫ	провайдер	провайдер
ОС и патчи	ТЫ	провайдер	провайдер
железо, гипервизор	провайдер	провайдер	провайдер

Читай таблицу по столбцам: чем правее модель, тем больше строк занято провайдером. Но две верхние строки (данные и доступы, а для баз ещё схема и запросы) остаются твоими в любой колонке.

Возьмём «Заметки». Приложение app.py и nginx на ВМ: это IaaS, ты патчишь Ubuntu, следишь за диском, настраиваешь nginx. PostgreSQL в контейнере на той же ВМ: тоже твоя работа целиком (бэкап, обновление версии, восстановление). Тот же PostgreSQL как Managed: провайдер делает бэкапы по расписанию и обновляет ОС под базой. Но если запрос SELECT без индекса делает БД медленной, это по-прежнему твоя зона: провайдер отвечает за то, что база жива, а не за то, что твой запрос умён.

Прикинь сам: сервис «Заметки» работает с Managed PostgreSQL. В три часа ночи провайдер обновил ОС под базой, а через час у тебя в логах пошли ошибки «таймаут запроса» из-за запроса без индекса. Кто виноват и кто чинит?

Чинишь ты: обновление ОС было работой провайдера и закончилось успешно (база жива), а медленный запрос это схема и запросы, то есть твоя зона. Поэтому первым делом смотри свой запрос, а не пиши в поддержку.

Осторожно: «провайдер безопасен, значит, я в безопасности». Почти все громкие утечки из облака это открытый всем бакет или утёкший ключ, а не взлом провайдера. Строка «доступы и данные» в таблице всегда твоя.

Главное: чем выше модель (IaaS, PaaS, SaaS), тем больше работы берёт провайдер, но данные, доступы и качество своих запросов остаются на тебе всегда.

Мы выяснили, кто за что отвечает. А где физически живут ресурсы и что будет, если дата-центр потеряет питание?

Регионы, зоны доступности, квоты и точка отказа

Дата-центр может остаться без питания, у него может порваться оптика, в нём может случиться пожар. Если всё твоё живёт в одном здании, сервис умрёт вместе с ним. Поэтому облако раскладывает ресурсы по нескольким физически разным площадкам, и ты выбираешь, где и сколько копий держать.

Это сеть магазинов в городе: один закрылся на ремонт, остальные работают. Но если у сети один магазин, ремонт останавливает бизнес. Аналогия ломается на расстоянии: соседние зоны облака связаны быстрой сетью, и разница в задержке между ними доли миллисекунды, а не «поездка через город».

Регион (region) это географическая область, например ru-central1 в Yandex Cloud. В регионе несколько зон доступности (availability zone, AZ): отдельные площадки со своим питанием и сетью. В Yandex Cloud это ru-central1-a, ru-central1-b и ru-central1-d; актуальный список смотри в документации, он может меняться. Отказ одной зоны не должен ронять другие.

flowchart TD
    R["Регион ru-central1<br>быстрая сеть между зонами"] --> A["Зона ru-central1-a<br>своё питание и сеть<br>ВМ notes-vm"]
    R --> B["Зона ru-central1-b<br>своё питание и сеть<br>пусто"]
    R --> D["Зона ru-central1-d<br>своё питание и сеть<br>пусто"]

На схеме у «Заметок» одна ВМ, и она стоит только в зоне a. Две другие зоны работают, но сервису не помогают: у него там нет копий.

Одна ВМ живёт в одной зоне. Поэтому «сервис на одной ВМ» остаётся единой точкой отказа (SPOF, single point of failure): место, где поломка одного элемента останавливает всё. Даже если зона надёжная, ВМ нужно перезагружать и обновлять. Чтобы пережить отказ, нужны минимум две ВМ в разных зонах и балансировщик, который направляет запросы на живую.

Квота (quota) это лимит провайдера на число ресурсов в твоём облаке: сколько vCPU (виртуальных процессорных ядер: «рабочих рук» ВМ), дисков, публичных адресов. Квоты защищают тебя и провайдера: ошибка в скрипте не создаст тысячу ВМ. Квоту можно поднять запросом в поддержку, но делать это нужно заранее, а не во время инцидента.

vCPU (virtual CPU) это виртуальное ядро процессора: доля реального ядра, которую гипервизор отдаёт ВМ. У части тарифов есть «гарантированная доля» (в Yandex core-fraction): ВМ с долей 20% гарантированно получает пятую часть ядра, а всплеском может использовать больше, если сосед не занят. Это дешевле, но ВМ будет тормозить под постоянной нагрузкой. Память измеряется в ГБ RAM, диск в ГБ, причём HDD дешевле, а SSD быстрее.

Пример: у «Заметок» одна ВМ в зоне ru-central1-a. Зона на два часа потеряла питание. Что видит пользователь: сайт не открывается. Что видишь ты: ВМ в консоли недоступна, и сделать ничего нельзя, надо ждать. Если бы вторая ВМ стояла в ru-central1-b, балансировщик перекинул бы трафик на неё. Для учебных задач курса мы держим одну ВМ (дешевле), но на собеседовании честно называй её SPOF.

Прикинь сам: у «Заметок» две ВМ, но обе в ru-central1-a. Переживёт ли сервис отказ этой зоны?

Нет: обе ВМ в одной зоне, при её отказе недоступны обе. Нужны ВМ в разных зонах.

Осторожно: регион и зону путают, а зона это часть региона. Ещё путают «надёжная зона» и «отказоустойчивый сервис»: надёжность зоны провайдера не заменяет вторую копию у тебя.

Главное: регион делится на зоны, ВМ живёт в одной зоне, поэтому одна ВМ это SPOF, а отказоустойчивость дают копии в разных зонах.

С надёжностью разобрались. Теперь о том, что обычно ломает новичка: о деньгах.

Деньги: биллинг, грант, бюджет-алерт, метки

Облако отдаёт ресурсы по одному запросу без проверки, нужно ли тебе их держать. Забытая ВМ будет тихо расходовать деньги месяцами. Значит, деньги нужно защищать с первого дня.

Это такси с включённым счётчиком: пока машина ждёт у подъезда, счётчик идёт. Аналогия ломается в том, что таксист напомнит о себе, а облако молчит, пока ты сам не поставишь оповещение.

Биллинг (billing) это учёт расходов. Он привязан к платёжному аккаунту (billing account): к нему подключена карта, и с него списываются деньги за все ресурсы. В облаке платят за использование:

минуты работы ВМ (за vCPU и RAM);
гигабайт-месяцы диска: диск стоит денег, пока существует, включён он или нет;
исходящий трафик (egress): данные, которые уходят из облака в интернет; входящий трафик обычно бесплатен;
публичные IP-адреса: отдельная строка счёта;
запросы и объём в объектном хранилище.

Отсюда три главные причины неожиданных счетов:

Забытые ресурсы. Остановленная ВМ не платит за vCPU и RAM, но диск и зарезервированный публичный IP продолжают списываться.
Исходящий трафик, о котором никто не думал: например, сервис отдаёт много файлов.
Снапшоты (snapshot, снимок диска) и бакеты (bucket, хранилище файлов), которые копятся без срока хранения.

Защита из трёх слоёв:

Грант (grant): бонусные деньги на пробный период; у нового аккаунта Yandex Cloud он обычно есть, размер и срок смотри в «Биллинге», они меняются. Курс рассчитан так, чтобы уложиться в грант, если удалять ресурсы после уроков.
Бюджет-алерт (budget alert): уведомление на почту, когда расходы достигли порога. Он только сообщает, но ресурсы сам не останавливает. Ставим порог 500 руб и письма на 50% и 100%.
Метки (labels): пары ключ=значение на ресурсах, например project=notes, owner=<твоё имя>. По ним в счёте видно, что чьё и что можно удалить.

В сценарии «Сломай и почини» ниже ты увидишь остановленную ВМ, два диска и зарезервированный адрес. ВМ не платит за процессор, но 50 ГБ загрузочного диска, 200 ГБ диска данных и адрес тарифицируются постоянно. Самая заметная строка там диск на 200 ГБ: цена диска растёт вместе с размером. Точные суммы сверяй в калькуляторе Yandex Cloud, тарифы меняются.

Прикинь сам: ты остановил ВМ и ушёл в отпуск на две недели. Что продолжает списывать деньги?

Загрузочный диск и любые другие диски, зарезервированный публичный адрес, а также снапшоты и бакеты, если они есть. За vCPU и RAM остановленной ВМ платы нет.

Как искать причину роста счёта: открой детализацию расходов и сгруппируй её по сервису, затем по метке. Так за минуту видно, что выросло: вычисления (ВМ), диски, трафик или хранилище. Если меток нет, придётся угадывать по именам и времени создания, поэтому метки ставят в момент создания ресурса, а не «потом». Ещё одна привычка: раз в неделю просматривать список ресурсов каталога (ВМ, диски, адреса, снапшоты, бакеты) и удалять всё, что не узнаёшь. Это называется инвентаризацией.

Правило курса: каждое задание с платными ресурсами заканчивается чек-листом удаления. Пока он не выполнен, задание не закончено.

Осторожно: «остановил ВМ, значит, не плачу». Плата за процессор действительно прекращается, но за диск и адрес нет. И «алерт защитит»: алерт лишь пишет письмо, а решает человек.

Главное: платишь за всё, что существует (диски, адреса, снапшоты, бакеты), а не только за работающие ВМ; алерт сообщает, а удаляешь ты.

Деньги защищены. Остался вопрос, кому в облаке можно трогать ресурсы.

Иерархия ресурсов и IAM: кто что может

В облаке работают десятки людей и программ: разработчик смотрит на логи, CI (система автоматической сборки, тема 3) выкладывает новую версию, бухгалтер смотрит счета. Дать всем один общий пароль от всего нельзя: если он утечёт или кто-то ошибётся, пострадает всё. Нужна система, где каждый получает ровно те права, которые нужны для его дела.

Это пропуска в офисе. У курьера пропуск только до ресепшена, у разработчика до его этажа, у директора до всех комнат. Если пропуск потерян, блокируют один пропуск, а не меняют все замки. Аналогия ломается на количестве: в облаке «пропуск» можно выдать на одну комнату, на этаж или на здание, и выбор уровня это отдельная задача.

Система называется IAM (Identity and Access Management, управление личностями и доступом). Она отвечает на вопрос: кто (субъект) может что (действие) делать над чем (ресурс). Из чего она состоит:

Пользователь (user): человек. Входит с паролем и вторым фактором.
MFA (multi-factor authentication, многофакторная аутентификация): вход по двум разным подтверждениям, например пароль и код из приложения. Если пароль украли, без второго фактора войти не получится.
Сервисный аккаунт (service account): «пользователь для программы»: для CI, скрипта или ВМ. Пароля у него нет, он входит по ключу или токену.
Роль (role): именованный набор прав. Например, compute.viewer позволяет только смотреть ВМ, а editor менять почти всё.
Привязка роли (access binding): запись «субъект X имеет роль R на ресурсе Y».

Ресурсы в Yandex Cloud вложены друг в друга: организация, в ней облако (cloud), в нём каталог (folder), в каталоге сами ресурсы (ВМ, диски, сети). Права, выданные на верхнем уровне, действуют на всё ниже: роль на каталог работает на все ресурсы в нём.

flowchart TD
    O["Организация"] --> C["Облако (cloud)"]
    C --> D1["Каталог default"]
    C --> D2["Каталог notes<br>роль editor выдана сюда"]
    D2 --> R1["ВМ notes-vm"]
    D2 --> R2["Диск notes-data"]
    D2 --> R3["Бакет notes-backups-..."]
    SA["Сервисный аккаунт<br>notes-deployer"] -.->|"editor на каталог"| D2

Пунктирная стрелка показывает привязку роли: notes-deployer может менять всё внутри каталога notes, но не видит и не меняет каталог default.

У каждого ресурса есть два названия: имя (notes, его выбираешь ты, удобно людям) и идентификатор (id, например b1g... у каталога или aje... у сервисного аккаунта; его выдаёт облако, он уникален и не меняется). Команды yc принимают и то и другое: --folder-name notes или --folder-id b1g.... Имена могут повторяться в разных каталогах, идентификаторы никогда, поэтому в выводе и логах ты видишь идентификаторы, а в командах удобнее имена.

Принцип наименьших привилегий (least privilege): выдай ровно то, что нужно для задачи, и на минимальном уровне (на каталог, а не на всё облако). Ровно как для пользователя notes на Linux в уроке 1.3: он владеет только своими данными и не root. Мы создадим каталог notes и всё курсовое положим в него: удалить каталог значит удалить всё сразу, это удобная уборка.

CI-скрипту нужно только загружать бэкапы в один бакет. Есть три варианта: admin на облако, editor на каталог, узкая роль на бакет. С первым вариантом скомпрометированный ключ отдаёт злоумышленнику всё облако: он запустит майнеры криптовалют на твой счёт, удалит бакеты, прочитает данные. Со вторым ущерб ограничен одним каталогом. С третьим только одним бакетом. Чем меньше права, тем дешевле ошибка.

Прикинь сам: у notes-deployer роль editor на каталог notes. Сможет ли он удалить ВМ в каталоге default?

Нет: привязка роли действует вниз по иерархии от каталога notes, а соседний каталог ей не подчиняется.

Осторожно: роль и субъект путают. Роль это набор прав, она ничего не делает, пока не привязана к кому-то. Ещё путают «выдать на облако» и «выдать на каталог»: первое действует на всё облако, включая чужие каталоги.

Главное: IAM отвечает на вопрос «кто, что и над чем может», права выдаются ролями на каталог и ниже, и чем уже права, тем дешевле ошибка.

Сервисному аккаунту нужен способ доказать, что это он. Как он это делает?

Ключи, токены и секреты: как программа доказывает, кто она

Когда yc или CI отправляют запрос, облаку нужно понять, от кого он. Человек вводит пароль и код, но программа не может «набрать» их. Ей нужно постоянное подтверждение, которое хранится в файле.

Это ключ от квартиры, который ты отдал курьеру. Он откроет дверь без тебя, но кто угодно, нашедший ключ, тоже откроет. Аналогия ломается в том, что в облаке ключ можно мгновенно отозвать, а замок менять не нужно.

Ключ сервисного аккаунта это JSON-файл с закрытой частью пары ключей (такую пару ты уже создавал для SSH в уроке 2.2). По нему программа получает токен (token): короткоживущую строку, которую облако принимает как подтверждение личности. Токен живёт часы и устаревает сам, а ключ живёт, пока его не отзовут. Поэтому ключ опаснее и хранить его нужно как пароль.

sequenceDiagram
    participant П as Программа (CI, yc)
    participant О as Облако
    П->>О: ключ сервисного аккаунта
    О-->>П: токен, живёт часы
    П->>О: запрос + токен
    О-->>П: ответ
    Note over П,О: токен устарел: берём новый по ключу

На схеме ключ участвует один раз, чтобы получить токен, а все остальные запросы идут с токеном. Украденный токен перестаёт работать сам, а украденный ключ даёт новые токены, пока его не отозвали.

Правила хранения секрета:

Никогда не класть в репозиторий. Коммит остаётся в истории git, даже если файл потом удалить.
Хранить вне рабочей папки проекта (~/.config/notes-cloud/), права 600 (читать и писать может только владелец, урок 1.3).
В .gitignore добавить шаблон *-key.json как страховку.
Один ключ на одну задачу, чтобы отзывать точечно.

Ты закоммитил notes-deployer-key.json и запушил в публичный репозиторий, потом удалил файл следующим коммитом. Кажется, что ключа больше нет. Но git log -p -S <часть ключа> находит его в старом коммите, а боты, сканирующие GitHub, находят такие ключи за минуты. Поэтому считай ключ скомпрометированным (украденным) сразу. Разбор порядка действий в разделе «Сломай и почини».

Осторожно: «удалил файл, значит, ключа нет». И «приватный репозиторий безопасен для ключей»: репозиторий видят все, у кого есть доступ, а ключи в истории остаются навсегда.

Прикинь сам: файл статического ключа случайно попал в публичный репозиторий. Что делаешь первым?

Отзываешь (удаляешь) ключ в облаке и выпускаешь новый: удаление файла из git не поможет, пока ключ действует, его могли уже скопировать. Затем проверяешь журнал использования ключа.

Главное: ключ это постоянный секрет, токен его короткоживущая производная; ключ не кладут в git, хранят вне проекта с правами 600 и при утечке отзывают первым делом.

Права и секреты разобраны. Осталось связать всё с тем, что ты увидишь в чужих статьях и на собеседованиях: с AWS.

Соответствие AWS

AWS самое распространённое облако. Документация, статьи и собеседования часто написаны в терминах AWS, даже если компания работает в Yandex Cloud или другом. Принципы те же, названия разные, поэтому полезно знать «словарь перевода».

Задача	Yandex Cloud	AWS	Что важно помнить
Виртуальная машина	Compute Cloud (`yc compute instance`)	EC2	образ, тип, диск, зона; у EC2 ещё instance profile: доступ ВМ к API без ключей
Сеть и подсети	VPC (`network`, `subnet`)	VPC	подсеть привязана к зоне
Фаервол ВМ	группа безопасности (security group)	Security Group	у обоих stateful (помнит соединения), правила только разрешающие
Объектное хранилище	Object Storage	S3	оба S3-совместимы по API, ключи доступа статические
Управляемая БД	Managed Service for PostgreSQL	RDS	бэкапы, патчи и реплики на провайдере
Управляемый Kubernetes	Managed Service for Kubernetes	EKS	control plane ведёт провайдер
Доступы	IAM, роли, сервисные аккаунты	IAM, роли, policies, instance profile	у AWS права описываются JSON-политиками
Функции	Cloud Functions	Lambda	платишь за вызовы
DNS	Cloud DNS	Route 53	публичные и приватные зоны
Балансировщик	Network / Application Load Balancer	NLB / ALB	L4 и L7 соответственно (L4 раскидывает соединения по адресу и порту, не читая содержимое; L7 читает запрос HTTP и решает по адресу страницы; подробно в уроке 6.4)

S3 (Simple Storage Service) это объектное хранилище от Amazon: ты кладёшь файлы («объекты») в «бакеты» и достаёшь их по HTTP. Его API стал стандартом, и Yandex Object Storage понимает те же запросы: поэтому программа для S3 работает и с Yandex, если поменять адрес (endpoint) и ключи. L4 и L7 это уровни сетевой модели: L4 балансировщик смотрит на адрес и порт, L7 разбирает содержимое HTTP-запроса (путь, заголовки).

Главное различие в IAM. В Yandex ты выдаёшь готовую роль субъекту на каталог. В AWS права описываются политикой (policy) в формате JSON, и её нужно уметь читать. Разбор в задании 4.

Как читать политику AWS: внутри Statement (утверждение) стоят четыре поля: Effect (Allow разрешить или Deny запретить), Action (что делать: s3:GetObject это чтение файла), Resource (над чем, записывается как ARN: уникальный адрес ресурса в AWS) и необязательный Sid (метка для человека). Всё, что не разрешено явно, запрещено. Явный Deny побеждает любой Allow.

Прикинь сам: коллега просит «дать доступ как в AWS S3, роль ReadOnly, но в Yandex». Как это делается?

Выдать сервисному аккаунту или пользователю роль storage.viewer (только чтение) на каталог или на нужный бакет. В Yandex не нужно писать JSON-политику: используется готовая роль.

Осторожно: сервисы похожи, но не одинаковы. Названия и цены у провайдеров разные, а самая большая работа при переезде это IAM: JSON-политики превращаются в роли.

Главное: сервисы Yandex Cloud и AWS сопоставляются один к одному, S3 API работает в обоих, а главная разница в правах: в Yandex готовые роли, в AWS JSON-политики.

Остался последний вопрос: что дешевле и как не застрять у одного провайдера?

Цена и привязка: TCO и vendor lock-in

Облако кажется дешёвым: ВМ стоит рубли в час. Но полная стоимость складывается не только из цены ВМ, и не всё облако выгоднее собственных серверов. Руководство спрашивает у SRE, что дешевле и как не застрять у одного провайдера.

TCO (total cost of ownership, полная стоимость владения) это вся цена, а не только строка счёта: железо и его амортизация, электричество, помещение, зарплата людей, простой при поломке. Свои серверы (on-premises, в своём дата-центре) выгоднее на стабильной большой нагрузке, где железо загружено на 70% и больше годами. Облако выгоднее при неравномерной нагрузке, быстром старте и когда не хочется держать команду на железе.

Vendor lock-in (привязка к поставщику) это ситуация, когда уйти от провайдера дорого, потому что ты использовал его уникальные сервисы (свои очереди, проприетарные функции, специальные базы данных). Чем «умнее» сервис, тем дороже уйти. Снизить привязку помогают стандарты: контейнеры, Kubernetes, S3-совместимое API, PostgreSQL вместо проприетарной БД. Поэтому «Заметки» в контейнере с обычным PostgreSQL можно перенести в любое облако.

Прикинь сам: стартап запускает продукт и не знает, сколько будет пользователей. Свой сервер или облако?

Облако: нагрузка неизвестна и неравномерна, а облако позволяет быстро начать и менять размер. Когда нагрузка стабилизируется и вырастет, можно пересчитать TCO.

Осторожно: «облако всегда дешевле». Не всегда: постоянная большая нагрузка часто дешевле на своём железе. И «lock-in это всегда плохо»: иногда управляемый сервис экономит месяцы работы, и привязка осознанная цена.

Главное: считай полную стоимость владения, а не цену одной ВМ, и выбирай привязку к провайдеру осознанно.

Практика

Как не потратить деньги: работаем в отдельном каталоге notes, ставим бюджет-алерт на 500 руб, в конце задания 5 есть чек-лист удаления. Ресурсы этого урока бесплатны (аккаунт, каталог, сервисный аккаунт). Если облака у тебя нет, задания 3 и 4 выполняются локально, а остальные прочитай и повтори у любого провайдера с грантом (Cloud.ru, VK Cloud): принципы те же.

Интерфейс консоли и вывод yc в этом уроке не запускались автором (нет доступа к облаку): команды и формат вывода взяты из документации Yandex Cloud CLI. Идентификаторы (b1g..., aje...) у тебя будут другими, названия столбцов могут слегка отличаться в твоей версии yc.

Задание 1. Аккаунт, MFA и бюджет-алерт

Цель: завести аккаунт, включить второй фактор и поставить защиту от неожиданного счёта.

Предскажи: алерт на 500 руб останавливает ВМ при превышении порога?

Ответ

Нет. Алерт только шлёт уведомление, ВМ продолжит работать и платить. Поэтому он нужен вместе с чек-листом удаления.

Шаги:

Открой консоль console.yandex.cloud, войди через Яндекс ID и включи двухфакторную аутентификацию в настройках Яндекс ID (id.yandex.ru, раздел про безопасность и вход).
Привяжи платёжный аккаунт и активируй пробный грант, если он доступен. В «Биллинге» проверь баланс и срок гранта.
В «Биллинге» создай бюджет: расходы, порог 500 руб на месяц, письма на 50% и 100%.
Создай каталог notes (кнопка «Создать каталог» в облаке).

Что должно получиться:

Биллинг: платёжный аккаунт активен, грант виден
Бюджет: notes-budget, порог 500 RUB/мес, уведомления 50% и 100%
Каталоги: default, notes

Это описание того, что ты должен увидеть в консоли, а не вывод команды.

Объясни себе: почему бюджет-алерт не заменяет удаление ресурсов? Что даст второй фактор, если пароль утёк?

Типичные ошибки:

Billing account is not active: способ оплаты не подтверждён: заверши привязку в разделе «Биллинг».

Задание 2. Установка `yc` CLI

Цель: управлять облаком из терминала.

Предскажи: что хранится на диске после yc init?

Ответ

Профиль в ~/.config/yandex-cloud/config.yaml: токен, идентификаторы облака и каталога, зона по умолчанию. Токен береги как пароль.

Шаги:

Скачай установочный скрипт в файл (а не curl ... | bash, когда чужой код запускается сразу и вслепую), прочитай и только потом запусти. Адрес может измениться: сверься с официальной документацией Yandex Cloud CLI.

Разберём команды. curl -fsSL <адрес> -o yc-install.sh: curl скачивает страницу по адресу; -f не сохраняет страницу с ошибкой, -s молчит, -S всё же показывает ошибку, -L идёт по перенаправлениям, -o сохраняет в файл. less листает файл (выход клавишей q). bash yc-install.sh -n запускает скрипт, -n говорит ему не править твой ~/.bashrc (файл, который читает оболочка при старте). export PATH="$HOME/yandex-cloud/bin:$PATH" добавляет папку с yc в список мест, где оболочка ищет команды (переменная PATH, урок 1.6): только для текущего окна терминала.

# скачиваем скрипт в файл, не запуская
curl -fsSL https://storage.yandexcloud.net/yandexcloud-yc/install.sh -o yc-install.sh
# читаем, что он собирается делать
less yc-install.sh
# запускаем без правки .bashrc и подключаем yc в текущую сессию
bash yc-install.sh -n
export PATH="$HOME/yandex-cloud/bin:$PATH"
yc version

yc version печатает версию программы (что-то вроде Yandex Cloud CLI <номер> linux/amd64). У тебя номер будет свой.

Инициализируй профиль: yc init спросит про вход (откроет браузер или попросит токен), облако, каталог и зону. Выбери каталог notes и зону ru-central1-a. yc config list покажет получившиеся настройки, yc resource-manager folder list перечислит каталоги.

yc init
yc config list
yc resource-manager folder list

Что должно получиться:

token: y0_AgAAAA...
cloud-id: b1g...
folder-id: b1g...
compute-default-zone: ru-central1-a

Как читать вывод: token это то, чем yc доказывает облаку, что это ты (он длинный, здесь обрезан), cloud-id и folder-id идентификаторы облака и каталога, с которыми работают команды по умолчанию, compute-default-zone зона, где будут создаваться ВМ, если не указать другую. Последняя команда покажет каталоги notes и default. Вывод yc config list не публикуй: в нём токен.

Объясни себе: зачем читать скрипт перед запуском? Что случится, если по умолчанию выбран не тот каталог?

Типичные ошибки:

bash: yc: command not found: каталог не в PATH: выполни export PATH="$HOME/yandex-cloud/bin:$PATH" и добавь эту строку в ~/.bashrc.

Не понимаешь строку из вывода yc config list или ошибку PermissionDenied? Скопируй их в нейросеть без значения токена (замени его на <токен>) и спроси, что они значат. Проверь ответ по документации Yandex Cloud CLI.

Задание 3. Стоимость стека «Заметок»

Цель: прикинуть цену до создания ресурсов и сопоставить стек с моделями.

Предскажи: какая строка самая дорогая: ВМ, диск, публичный IP или Managed PostgreSQL?

Ответ

Managed PostgreSQL: в цену входят вычисления, диск и работа провайдера над бэкапами и failover. Она дороже БД в контейнере на ВМ, но снимает операционную работу. Точные суммы зависят от тарифа, проверь калькулятор.

Шаги:

В калькуляторе Yandex Cloud (yandex.cloud/ru/prices) найди цены: ВМ 2 vCPU и 2 ГБ RAM, диск SSD 20 ГБ, публичный IPv4, Managed PostgreSQL минимального класса. Запиши дату просмотра: цены меняются.
Подставь цифры в скрипт. Числа ниже условные, учебные, а не настоящие тарифы: замени их своими.

Разбор скрипта: vm=1500; disk=400; ip=300; pg=3500 создаёт четыре переменные (без пробелов вокруг =, урок 1.6); $((vm + disk + ip)) арифметика в bash: вычисляет сумму и подставляет число в строку.

# цены за месяц в рублях (условные, замени на актуальные с сайта)
vm=1500; disk=400; ip=300; pg=3500
echo "всё на одной ВМ: $((vm + disk + ip)) руб/мес"
echo "ВМ + Managed PostgreSQL: $((vm + disk + ip + pg)) руб/мес"

Запиши модель для каждого компонента: app.py и nginx (IaaS), PostgreSQL в контейнере (IaaS) или Managed (PaaS), бэкапы в бакете, почта для алертов (SaaS).

Что должно получиться (с условными числами выше; проверено запуском):

всё на одной ВМ: 2200 руб/мес
ВМ + Managed PostgreSQL: 5700 руб/мес

Как читать вывод: первая строка показывает вариант «всё сам на одной ВМ», вторая добавляет управляемую базу. Разница между ними цена того, что провайдер берёт на себя бэкапы и failover. С твоими настоящими числами вывод изменится.

Объясни себе: что важнее в разнице: деньги или время дежурного на бэкапы и патчи БД? Какая строка счёта растёт даже при остановленной ВМ?

Типичные ошибки:

bash: vm: command not found: пробелы вокруг =: пиши vm=1500 без пробелов.

Задание 4. Читаем IAM-политику AWS и роли Yandex

Цель: прочитать JSON-политику доступа и сопоставить с ролями Yandex. Облако не нужно.

Предскажи: политика даёт s3:ListBucket и s3:GetObject на бакет notes-backups. Сможет ли пользователь записать туда файл?

Ответ

Нет. Всё, что не разрешено явно, запрещено (неявный deny). Два Resource: сам бакет для листинга (ListBucket) и объекты внутри для чтения (GetObject, поэтому /*).

Шаги:

Сохрани политику и проверь, что JSON валиден. cat > файл <<'JSON' ... JSON записывает всё между строками-маркерами в файл (кавычки вокруг JSON отключают подстановки внутри). python3 -m json.tool файл читает JSON и печатает его, при ошибке синтаксиса сообщает строку; > /dev/null прячет печать, оставляя только ошибки; && echo выводит «JSON ok» только при успехе.

mkdir -p ~/notes/docs && cd ~/notes
cat > docs/backup-read-policy.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadBackups",
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetObject"],
      "Resource": ["arn:aws:s3:::notes-backups", "arn:aws:s3:::notes-backups/*"]
    }
  ]
}
JSON
python3 -m json.tool docs/backup-read-policy.json > /dev/null && echo "JSON ok"

Запиши, какая роль Yandex ближе: storage.viewer на каталог или бакет. Запись даёт storage.editor, полный доступ storage.admin. Файл docs/backup-read-policy.json оставь как учебный, коммитить его не обязательно.

Что должно получиться:

JSON ok

Как читать вывод: JSON ok значит, что синтаксис верен. Если бы файл был сломан, вместо этого появилась бы ошибка с номером строки и не было бы слов JSON ok.

Объясни себе: что изменится, если в Action написать s3:*? Чем выдача готовой роли в Yandex отличается от политики в AWS?

Типичные ошибки:

Expecting ',' delimiter: line 8 column 7: пропущена запятая: найди строку из ошибки и добавь.
Expecting property name enclosed in double quotes: лишняя запятая в конце списка или одинарные кавычки: JSON допускает только двойные и без висящих запятых.

Выдаёшь роль сервисному аккаунту и сомневаешься, какая нужна? Спроси нейросеть, какая минимальная роль нужна для задачи, а потом найди её в документации ролей: нейросеть часто называет роли, которых нет.

Задание 5. Шаг проекта: сервисный аккаунт и ключ

Цель: создать сервисный аккаунт с минимальными правами для следующих уроков и не дать ключу попасть в репозиторий.

Предскажи: какую роль на каталог выдать аккаунту, который в уроке 6.2 создаёт ВМ, сети и диски: viewer, editor или admin?

Ответ

editor на каталог notes. admin лишняя: она управляет доступами, для ВМ не нужна. viewer мало: создавать нельзя. Выдаём на каталог, не на облако.

Шаги:

Создай аккаунт и выдай роль только на каталог notes. Флаги: --name имя аккаунта, --role роль, --service-account-name кому выдаём. \ в конце строки переносит команду на следующую строку.

yc iam service-account create --name notes-deployer --folder-name notes
# привязка роли на каталог, не на облако
yc resource-manager folder add-access-binding notes \
  --role editor --service-account-name notes-deployer
yc resource-manager folder list-access-bindings notes

Создай ключ вне репозитория и закрой права: chmod 600 оставляет доступ только владельцу.

mkdir -p ~/.config/notes-cloud
yc iam key create --service-account-name notes-deployer \
  --output ~/.config/notes-cloud/notes-deployer-key.json
chmod 600 ~/.config/notes-cloud/notes-deployer-key.json

Защити репозиторий и проверь чек-лист удаления. printf '%s\n' a b >> файл дописывает строки a и b в конец файла; sort -u ... -o убирает повторы, если команду запустили дважды; git check-ignore -v имя показывает, какое правило .gitignore игнорирует файл.

cd ~/notes
printf '%s\n' '*-key.json' 'key.json' >> .gitignore
sort -u .gitignore -o .gitignore
git check-ignore -v test-key.json
# платных ресурсов быть не должно
yc compute instance list --folder-name notes
yc compute disk list --folder-name notes
yc vpc address list --folder-name notes

Что должно получиться:

ROLE ID  SUBJECT TYPE     SUBJECT ID
editor   serviceAccount   aje...
.gitignore:1:*-key.json	test-key.json

Как читать вывод: первая часть это строка привязки в таблице list-access-bindings: роль editor, субъект типа «сервисный аккаунт» (у тебя там будет свой идентификатор; в таблице могут быть и другие строки, например владелец облака). Вторая часть ответ git check-ignore: файл:номер строки:шаблон и имя проверенного файла. Если после sort -u порядок строк в .gitignore изменился, номер строки будет другим, это нормально. Три list-команды выводят пустой результат: ВМ, дисков и адресов нет. Формат пустого ответа зависит от версии yc.

Объясни себе: почему ключ лежит вне ~/notes, а не только в .gitignore? Что сломается, если удалить аккаунт, чей ключ ещё используется?

Типичные ошибки:

ERROR: service account with name "notes-deployer" already exists: аккаунт уже создан: пропусти создание, посмотри его через yc iam service-account get notes-deployer.
ERROR: rpc error: code = PermissionDenied desc = Permission denied: у тебя нет права выдавать роли: нужна admin на каталог или облако (у владельца облака есть).
git check-ignore ничего не печатает: .gitignore создан не в корне репозитория: выполни команды из ~/notes.

Чек-лист удаления (повторяется в каждом уроке темы): yc compute instance list, disk list, vpc address list, compute snapshot list, storage bucket list пусты, расходы за сегодня в биллинге равны нулю.

Сломай и почини

В этом уроке два ручных сценария (скрипта поломок нет: ломать нечего, всё происходит в консоли и в git). Читай симптом, формулируй гипотезы, проверяй и только потом открывай разбор.

Симптом

Сценарий 1. Счёт за забытую ВМ. Через неделю после первого урока пришло письмо: «Расходы достигли 50% бюджета». Ты помнишь, что «всё удалял». Вот вывод команд по каталогу (схематично, столбцы сокращены):

instance test-vm      ru-central1-a  STOPPED
disk     test-vm-boot 50 GB          READY
disk     data-old     200 GB         READY
address  ip1          158.160.x.x    RESERVED=true

Сценарий 2. Ключ в публичном репозитории. Сервисный ключ notes-deployer-key.json случайно закоммичен и запушен в публичный репозиторий, потом удалён следующим коммитом. Придёт ли ущерб?

Смоделируй сценарий 2 локально без настоящего ключа:

mkdir -p ~/leak-demo && cd ~/leak-demo
git init -q && git config user.email "x@example.com" && git config user.name "demo"
# фейковый ключ, не настоящий
echo '{"private_key": "FAKE_KEY_CHANGE_ME"}' > key.json
git add key.json && git commit -qm "add key"
git rm -q key.json && git commit -qm "remove key"

Гипотезы

Для сценария 1: какие ресурсы платят, даже когда ВМ остановлена? Что забыли удалить, кроме самой ВМ? Что ещё может быть в каталоге (снапшоты, бакеты)?

Для сценария 2: удаление файла удаляет ключ из истории? Кто уже мог его скопировать? Что нужно сделать в первую очередь: почистить историю или отозвать ключ?

Проверки

# сценарий 2: находим ключ в истории, хотя файла в дереве уже нет
cd ~/leak-demo
git log --oneline -- key.json
git log -p -S FAKE_KEY --all | head -20

Разбор: git log --oneline -- key.json показывает коммиты, которые трогали файл; -p добавляет сами изменения; -S FAKE_KEY оставляет только коммиты, где число вхождений строки изменилось; --all смотрит все ветки; | head -20 берёт первые 20 строк.

Ожидаемый результат (хэши и даты у тебя будут другие):

df1f0f8 remove key
60ce3a2 add key
commit df1f0f8bf506a3c79cacf238ead76f07a4abc135
Author: demo <x@example.com>
...
-{"private_key": "FAKE_KEY_CHANGE_ME"}

Как читать вывод: два коммита, которые касались файла, и в старом коммите строка с «ключом» видна целиком: файл удалён из рабочей папки, а из истории нет.

Для сценария 1 проверь ещё снапшоты и бакеты: yc compute snapshot list --folder-name notes и yc storage bucket list --folder-name notes.

Исправление

Разбор сценария 1: забытая ВМ и счёт

Остановленная ВМ не платит за vCPU и RAM, но платит за всё, что к ней привязано: загрузочный диск (50 ГБ), диск данных data-old (200 ГБ, самый дорогой) и зарезервированный публичный IP ip1 (платится всегда, пока не освобождён). Порядок уборки:

# сначала смотрим, что именно останется
yc compute instance delete test-vm --folder-name notes
yc compute disk delete data-old --folder-name notes
yc vpc address delete ip1 --folder-name notes

Диск данных перед удалением проверь: нужен ли он. Если данные нужны, сначала сделай снапшот. Дальше: проверь снапшоты и бакеты, поставь метки owner, project, а в конце проверь биллинг: расходы за день должны упасть до нуля. Профилактика: чек-лист удаления в конце каждого урока, бюджет-алерт на 50% и 100%.

Разбор сценария 2: ключ в публичном репозитории

Удаление файла следующим коммитом не убирает ключ из истории: git log -p -S его находит. Публичные репозитории сканируют боты за минуты, поэтому считай ключ скомпрометированным. Порядок действий:

Немедленно отзови ключ: yc iam key list --service-account-name notes-deployer, затем yc iam key delete <id>. Создай новый, положи вне репозитория.
Проверь журнал аудита и биллинг за период утечки: не создавались ли чужие ресурсы.
Только потом чисти историю (git filter-repo) и делай force push, зная, что копии уже могли разойтись.
Добавь *-key.json в .gitignore и включи сканер секретов в CI.

Главное: отзыв важнее очистки истории. Чистка не вернёт ключ, который уже скопировали.

После разбора: rm -rf ~/leak-demo.

ИИ в помощь

Нейросеть хорошо объясняет термины облака и сопоставляет сервисы разных провайдеров, но тарифов, актуальных названий ролей и цен она не знает: они меняются. Общие правила: ИИ-помощник.

Задача: составить таблицу соответствия сервисов для твоего стека.

У меня стек: приложение на Python за nginx на ВМ, PostgreSQL, бэкапы в объектном хранилище.
Сопоставь сервисы Yandex Cloud и AWS в таблице: задача, Yandex Cloud, AWS, чем отличаются
в управлении доступом. Отметь, где перенос с одного провайдера на другой самый трудоёмкий.

Проверь ответ: сверь названия с таблицей в уроке и с документацией провайдера. Типичная ошибка нейросетей: выдумывать названия сервисов и имена ролей (например, storage.reader вместо storage.viewer), поэтому каждую роль проверяй командой yc iam role list или в документации.

Задача: разобрать IAM-политику AWS.

Объясни по полям эту политику: Effect, Action, Resource. Что она разрешает, чего не разрешает,
что будет, если в Action написать s3:*? Предложи более узкий вариант для чтения одного бакета.
<вставь JSON-политику из задания 4>

Проверь ответ: сверь с правилами чтения политики из урока: что не разрешено явно, то запрещено, явный Deny побеждает Allow. Проверь ARN бакета и /* для объектов: нейросети часто путают ARN бакета и ARN объектов внутри него.

Задача: посчитать, почему вырос счёт.

Вот список ресурсов каталога в облаке: <вставь вывод yc compute instance list, disk list, vpc address list>.
ВМ остановлена. Какие из этих ресурсов продолжают тарифицироваться и в каком порядке
их безопаснее удалять? Что сделать с данными перед удалением?

Проверь ответ: сверь с разделом про деньги: за остановленную ВМ не платят только vCPU и RAM. Типичная ошибка нейросетей: предложить удалить диск с данными без снапшота. Цены и тарифы бери только из калькулятора провайдера, не из ответа нейросети.

Словарик урока

Термин	Простыми словами
Облако (cloud)	чужие серверы, диски и сети, которые арендуют на время и создают через API
Провайдер	компания, которая сдаёт облако в аренду (Yandex Cloud, AWS)
Гипервизор (hypervisor)	программа, делящая физический сервер на несколько виртуальных машин
ВМ (virtual machine)	«компьютер внутри компьютера»: изолированная машина на общем железе
API	набор запросов, которые понимает облако; консоль, `yc` и Terraform шлют именно их
IaaS	облако даёт ВМ, диск и сеть, остальное твоё
PaaS	облако ведёт платформу целиком (например, базу), ты приносишь данные и код
SaaS	готовая программа, ты только пользуешься
FaaS (serverless)	ты приносишь функцию, платишь за вызовы
Модель общей ответственности	разделение: провайдер отвечает за облако, ты за то, что в нём запущено
Регион (region)	географическая область с несколькими зонами
Зона доступности (AZ)	отдельная площадка со своим питанием и сетью внутри региона
SPOF	единая точка отказа: поломка одного элемента останавливает всё
API, CLI, консоль	три способа управлять облаком: запросы программы, команды в терминале, кнопки в браузере
Квота (quota)	лимит провайдера на число ресурсов в твоём облаке
vCPU	виртуальное ядро процессора: доля реального ядра для ВМ
Egress	исходящий из облака трафик, тарифицируется
Грант (grant)	бонусные деньги на пробный период
Бюджет-алерт	письмо при достижении порога расходов, ресурсы сам не останавливает
Метка (label)	пара `ключ=значение` на ресурсе для учёта и поиска
Каталог (folder)	контейнер ресурсов внутри облака; на него выдают роли и его удаляют целиком
IAM	система «кто что может»: пользователи, роли, привязки
MFA	вход с двумя подтверждениями (пароль и код)
Сервисный аккаунт	«пользователь для программы», входит по ключу или токену
Роль (role)	именованный набор прав
Привязка роли (access binding)	запись «субъект имеет роль на ресурсе»
Наименьшие привилегии	выдавать ровно то, что нужно, на минимальном уровне
Токен	короткоживущее подтверждение личности, которое выдаёт облако
Политика (policy, AWS)	JSON-описание разрешений
S3	объектное хранилище Amazon; его API стал стандартом
TCO	полная стоимость владения, не только счёт за ВМ
Vendor lock-in	привязка к сервисам одного провайдера, из-за которой трудно уйти

Вопросы с собеседований

Раздел для повторения: ответь вслух, потом открой ответ. Короткие вопросы с пометкой [на скорость] тренируй на время: ответ за 30 секунд.

1. [junior] [часто] Чем IaaS отличается от PaaS и SaaS? Приведи пример на своём проекте

Ответ

IaaS даёт ВМ, диск и сеть: ОС и приложение на мне. PaaS даёт платформу: например, Managed PostgreSQL, где патчи и бэкапы делает провайдер. SaaS это готовый продукт, как почта. Мои «Заметки» на ВМ это IaaS, БД в Managed сервисе это PaaS.

Что хотят услышать: граница ответственности, конкретные примеры, понимание, что данные и доступы всегда на клиенте.

Красный флаг: пересказ определений без примеров и без слов «кто патчит».

2. [junior] [часто] Что такое регион и зона доступности? Что случится с сервисом на одной ВМ при отказе зоны?

Ответ

Регион это географическая область, зона это независимая площадка внутри неё. Если зона недоступна, ВМ в ней не работает, и сервис лежит. Отказоустойчивость дают экземпляры в разных зонах и балансировщик, который направляет запросы на живые.

Что хотят услышать: одна ВМ равна SPOF (единой точке отказа), минимум две зоны, балансировщик, состояние БД отдельно.

Красный флаг: «облако не падает».

3. [junior] Пришёл счёт в 5 раз больше ожидаемого. Что делаешь?

Ответ

Смотрю детализацию по сервисам и по меткам: какой ресурс дал рост. Проверяю забытые ВМ, диски, публичные IP, снапшоты, бакеты и исходящий трафик. Виновника останавливаю или удаляю, для нужных данных сначала делаю снапшот. Потом ставлю бюджет-алерт и метки.

Что хотят услышать: биллинг по сервисам, инвентаризация всех типов ресурсов, egress, профилактика (алерт, метки, чек-лист).

Красный флаг: «удалю всё подряд» без проверки, что нужно.

4. [junior] [на скорость] Что такое сервисный аккаунт и зачем он нужен?

Ответ

Это «пользователь» для программы: CI, скрипта или ВМ. У него нет пароля, доступ по ключу или токену. Ему выдают минимальные роли на нужный каталог, а его ключ можно отозвать, не трогая людей.

Что хотят услышать: отдельный аккаунт на каждую задачу, минимальные роли, ротация (замена на новый) и отзыв ключа.

Красный флаг: используют личную учётку владельца облака в CI.

5. [middle] Ключ от облака утёк в публичный репозиторий. Порядок действий

Ответ

Сначала отзываю ключ и выпускаю новый: удаление из истории не помогает, ключ уже могли скопировать. Потом смотрю журнал аудита (запись действий в облаке) и биллинг за период утечки, ищу чужие ресурсы и удаляю их. После этого чищу историю и включаю сканер секретов в CI.

Что хотят услышать: «сначала revoke, потом чистка», аудит, ограничение прав ключа, автоматический поиск секретов.

Красный флаг: «сделаю force push и удалю файл» без отзыва.

6. [middle] Как ты выдашь CI право деплоя в облако?

Ответ

Отдельный сервисный аккаунт с ролью на конкретный каталог (или конкретный ресурс), а не на облако. Лучше короткоживущие токены (федерация, OIDC: CI получает токен от облака без хранимого ключа) вместо статического ключа в секретах. Ключ, если он нужен, хранится в секретах CI и ротируется.

Что хотят услышать: least privilege, область ролей (каталог), OIDC или ротация, отсутствие ключа в репозитории.

Красный флаг: admin на облако «чтобы работало».

7. [middle] Остановил ВМ, а списания продолжаются. Почему?

Ответ

Остановка снимает оплату vCPU и RAM, но диски и зарезервированный публичный IP продолжают тарифицироваться. Плюс снапшоты и бакеты. Чтобы не платить, ВМ надо удалить вместе с дисками и освободить IP, а данные сохранить снапшотом или в бакете.

Что хотят услышать: что именно платит после остановки, инвентаризация ресурсов, снапшот перед удалением.

Красный флаг: уверенность, что остановленная ВМ бесплатна.

8. [middle] Мигрируем из AWS в Yandex Cloud. Как сопоставишь сервисы и где будут подводные камни?

Ответ

EC2 в Compute Cloud, S3 в Object Storage (S3-совместимо, меняется endpoint и ключи), RDS в Managed PostgreSQL, EKS в Managed Kubernetes, Security Group в группы безопасности. Больше всего работы в IAM: политики JSON превращаются в роли, а привязки к проприетарным сервисам (Lambda, DynamoDB) переписываются.

Что хотят услышать: таблица соответствий, S3 API как мост, IAM как самое сложное, lock-in на проприетарных сервисах.

Красный флаг: «сервисы одинаковые, просто поменять названия».

9. [junior] [на скорость] Публичный и приватный IP в облаке: в чём разница и что платное?

Ответ

Приватный IP из подсети виден только внутри сети, бесплатен. Публичный нужен для доступа снаружи, тарифицируется отдельно, а зарезервированный платит, даже если не привязан к ВМ. Для внутренних сервисов публичный адрес не нужен.

Что хотят услышать: NAT, экономия, публичный адрес только там, где нужен, риск лишней экспозиции (доступности из интернета).

Красный флаг: «всем ВМ по публичному адресу, так проще».

10. [middle] Прочитай политику: Allow, Action s3:, Resource “”. Что не так и как исправишь?

Ответ

Она разрешает любое действие над любым бакетом аккаунта: это скрытый admin для хранилища. Исправляю: перечисляю нужные действия (s3:GetObject, s3:PutObject) и ограничиваю Resource конкретным бакетом и префиксом.

Что хотят услышать: least privilege, явный список действий, конкретный ARN, отказ от *.

Красный флаг: «политика нормальная, главное, чтобы работало».

11. [junior] Что такое модель разделения ответственности (shared responsibility) в облаке?

Ответ

Провайдер отвечает за безопасность самого облака: дата-центры, железо, гипервизор, сеть провайдера. Клиент отвечает за то, что внутри: учётки и права, сетевые правила, ОС на ВМ, данные, шифрование, бэкапы. Чем выше модель (IaaS, PaaS, SaaS), тем больше берёт на себя провайдер: в managed-БД он патчит систему, но права доступа и схема остаются моими. Большинство инцидентов - неверные настройки клиента, например открытый бакет.

Что хотят услышать: граница ответственности, зависит от модели, примеры, ошибки конфигурации на стороне клиента.

Красный флаг: «Облако всё делает за меня, бэкапы и безопасность тоже».

12. [junior] Что сделаешь в первые дни после создания облачного аккаунта?

Ответ

Первым делом защищаю корневую учётку: включаю MFA и не использую её для работы. Создаю отдельных пользователей или роли с минимальными правами, для автоматики - сервисные аккаунты. Настраиваю бюджет и оповещения о расходах, включаю аудит-логи действий. Задаю соглашение об именах и метках. Ключи не храню в репозитории, для CI выдаю отдельные ограниченные права.

Что хотят услышать: MFA, не работать под root-учёткой, минимальные права, бюджет и алерты, аудит-логи, метки.

Красный флаг: Работать из-под владельца аккаунта с полным доступом.

13. [middle] Что такое vendor lock-in и как его снижать?

Ответ

Lock-in - когда переезд к другому провайдеру дорог из-за привязки к его уникальным сервисам и API. Снижаю риск так: описываю инфраструктуру кодом (Terraform), использую переносимые технологии (Kubernetes, PostgreSQL, S3-совместимое хранилище), держу данные в открытых форматах и проверяю, что умею сделать экспорт. Полностью независимым быть дорого, поэтому взвешиваю: иногда managed-сервис с привязкой выгоднее. Важно знать цену выхода заранее.

Что хотят услышать: причины и цена, IaC, открытые стандарты, экспорт данных, баланс с удобством managed-сервисов.

Красный флаг: «Lock-in это всегда плохо, поэтому всё строю сам».

Проверено на версиях

Не прогонялось (нет доступа к облаку по условиям работы над курсом): все команды yc, консоль Yandex Cloud, тарифы и ход интерфейса взяты из документации Yandex Cloud. Версия yc не закреплена, проверь актуальную по yc version.
Проверено запуском на Mac: расчёт из задания 3 (Bash, вывод 2200 и 5700); демонстрация утечки ключа из «Сломай и почини» (Git, вывод git log совпадает); JSON-политика из задания 4 (python3 -m json.tool, ответ без ошибок).
Ubuntu: 24.04 LTS и 26.04 LTS, Git из пакетов дистрибутива.
Проект «Заметки»: 0.4.1 (не менялся).

Итог урока: ты умеешь

объяснить, что такое облако и чем ВМ в облаке отличается от ВМ на ноутбуке
объяснить IaaS, PaaS, SaaS и границу ответственности на примере «Заметок»
отличить регион от зоны доступности и назвать, что даёт отказоустойчивость
настроить бюджет-алерт и объяснить, чего он не делает
назвать, что платит при остановленной ВМ
сопоставить сервисы Yandex Cloud и AWS (ВМ, сеть, S3, БД, Kubernetes, IAM)
прочитать JSON-политику AWS и выбрать роль Yandex с минимальными правами
создать сервисный аккаунт, выдать роль на каталог и хранить ключ вне репозитория
найти забытые платные ресурсы и отозвать утёкший ключ в правильном порядке

Дальше: Урок 6.2: ВМ, сеть и диски в облаке

Проверь себя

Короткий тест по уроку: 5 вопросов из банка в 30. Засчитывается только полностью правильный ответ, порог 60%. Каждая новая попытка даёт другие вопросы, пока банк не закончится. Ответы видны после проверки.

Тест работает с включённым JavaScript.

Зачем это нужно

Что нужно знать

Картина целиком

Теория

Что такое облако и почему оно так работает

Консоль, CLI и API: три способа сказать облаку одно и то же

Модели: IaaS, PaaS, SaaS, FaaS и общая ответственность

Регионы, зоны доступности, квоты и точка отказа

Деньги: биллинг, грант, бюджет-алерт, метки

Иерархия ресурсов и IAM: кто что может

Ключи, токены и секреты: как программа доказывает, кто она

Соответствие AWS

Цена и привязка: TCO и vendor lock-in

Практика

Задание 1. Аккаунт, MFA и бюджет-алерт

Задание 2. Установка yc CLI

Задание 3. Стоимость стека «Заметок»

Задание 4. Читаем IAM-политику AWS и роли Yandex

Задание 5. Шаг проекта: сервисный аккаунт и ключ

Сломай и почини

Симптом

Гипотезы

Проверки

Исправление

ИИ в помощь

Словарик урока

Вопросы с собеседований

1. [junior] [часто] Чем IaaS отличается от PaaS и SaaS? Приведи пример на своём проекте

2. [junior] [часто] Что такое регион и зона доступности? Что случится с сервисом на одной ВМ при отказе зоны?

3. [junior] Пришёл счёт в 5 раз больше ожидаемого. Что делаешь?

4. [junior] [на скорость] Что такое сервисный аккаунт и зачем он нужен?

5. [middle] Ключ от облака утёк в публичный репозиторий. Порядок действий

6. [middle] Как ты выдашь CI право деплоя в облако?

7. [middle] Остановил ВМ, а списания продолжаются. Почему?

8. [middle] Мигрируем из AWS в Yandex Cloud. Как сопоставишь сервисы и где будут подводные камни?

9. [junior] [на скорость] Публичный и приватный IP в облаке: в чём разница и что платное?

10. [middle] Прочитай политику: Allow, Action s3:, Resource “”. Что не так и как исправишь?

11. [junior] Что такое модель разделения ответственности (shared responsibility) в облаке?

12. [junior] Что сделаешь в первые дни после создания облачного аккаунта?

13. [middle] Что такое vendor lock-in и как его снижать?

Проверено на версиях

Итог урока: ты умеешь

Проверь себя

Задание 2. Установка `yc` CLI