Yandex Cloud — это облачная платформа Яндекса: виртуальные машины, базы данных, хранилища, сеть и десятки управляемых сервисов. Как и в любом большом облаке, на старте это стена из новых слов. Но почти всё стоит на четырёх опорах: разберитесь с ними — и остальное будет встраиваться в понятную картину.

Эти четыре опоры: иерархия ресурсов (где всё лежит и кто за это платит), IAM (кто и что имеет право делать), регионы и зоны доступности (где физически живут ресурсы и как пережить сбой) и облачная сеть (как устроена ваша приватная сеть). Дальше — по порядку, простыми словами. Если вы знакомы с AWS, по ходу будут пометки, что чему соответствует.

Иерархия: организация, облако, каталог

В Yandex Cloud ресурсы разложены по трёхуровневой матрёшке.

  • Организация — верхний уровень, привязанный к вашей компании. Здесь живут пользователи, настройки входа (в том числе federation с корпоративным SSO) и общие политики.
  • Облако (cloud) — крупная единица внутри организации; к облаку привязан платёжный аккаунт (billing account). Обычно одно облако на компанию или направление.
  • Каталог (folder) — то, внутри чего создаются сами ресурсы: виртуальные машины, базы, сети. Каталог — это граница изоляции и удобная точка, на которую выдают права.

Практика та же, что и в других облаках: под разные среды заводят разные каталоги — отдельный каталог под боевую систему (production), отдельный под тестовую (staging), отдельный «песочницу» для экспериментов. Зачем так: если кто-то случайно удалит ресурсы или утечёт доступ, беда не выйдет за пределы одного каталога, а в счёте сразу видно, какой каталог сколько потратил. (В терминах AWS каталог примерно соответствует отдельному аккаунту, а облако с организацией — роли AWS Organizations.)

Главный практический вывод: фраза «у нас есть Yandex Cloud» всегда тянет вопрос «а в каком каталоге?».

IAM: кто и что может делать

Cloud IAM (Identity and Access Management) отвечает на один вопрос: кто имеет право делать что и с каким ресурсом. Здесь три ключевых понятия.

Роль (role) — набор разрешений. Есть примитивные роли на весь каталог — viewer (только смотреть), editor (создавать и менять), admin (плюс раздавать права), — и множество узких сервисных ролей вида storage.editor или compute.viewer, которые дают доступ только к конкретному сервису.

Привязка роли (role binding) — это назначение «кому — какую роль — на каком ресурсе». Роль можно выдать на облако, на каталог или на отдельный ресурс. Права наследуются вниз: роль на каталог действует на все ресурсы внутри него.

Субъект (subject) — тот, кому выдают роль. Это либо человек (аккаунт в организации), либо сервисный аккаунт (service account) — учётная запись для программ и виртуальных машин.

Два правила, которые экономят нервы и деньги.

Первое: ваш код не должен носить с собой долгоживущие ключи. Когда программа работает на виртуальной машине Yandex Cloud, к машине привязывают сервисный аккаунт, и приложение получает временный IAM-токен прямо из сервиса метаданнх машины — без единого секрета в коде. Токен живёт около 12 часов и обновляется автоматически. Это тот же принцип, что instance profile в AWS: платформа сама выдаёт временные учётные данные. Ключи, прописанные в конфиге или закоммиченные в git, — классический путь к утечке.

Второе: минимум прав (least privilege). Давайте роли ровно то, что нужно: сервису — доступ к своему бакету и своей базе, а не editor на весь каталог, чтобы «просто заработало». Узкие права — это лишние десять минут; разгребать последствия широких — это инцидент. Подробный разбор ролей и сервисных аккаунтов — в статье про IAM в Yandex Cloud.

Регионы и зоны доступности

Регион — это крупная географическая площадка. Основной регион Yandex Cloud — ru-central1 (Центральная Россия). Ресурсы привязаны к региону, и данные сами собой между регионами не путешествуют — копию в другом месте нужно настраивать отдельно.

Зона доступности (availability zone) — изолированный дата-центр внутри региона: своё питание, охлаждение и сеть, чтобы авария в одной зоне не задела соседнюю. В ru-central1 три зоны — ru-central1-a, ru-central1-b и ru-central1-d. Зоны связаны быстрыми каналами: задержка между ними — единицы миллисекунд.

Зачем это знать новичку:

  • Отказоустойчивость строят на нескольких зонах одного региона. Основная база в одной зоне, реплика — в другой; копии приложения разбросаны по зонам; сверху — балансировщик нагрузки. Упадёт одна зона — сервис продолжит работать на оставшихся.
  • Трафик между зонами стоит денег. Если сервисы в разных зонах болтают друг с другом без меры, это видно в счёте.

Как строить высокую доступность на нескольких зонах — подробнее в статье про масштабирование и доступность.

Облачная сеть: ваша приватная сеть

Облачная сеть (VPC) — ваша личная изолированная сеть внутри Yandex Cloud, что-то вроде огороженного двора, где живут серверы и базы. Минимальный набор понятий на старте:

Подсети (subnets) в Yandex Cloud привязаны к зоне доступности: одна подсеть — одна зона. Ресурс в подсети получает внутренний IP-адрес. Чтобы виртуальная машина стала доступна из интернета, ей выдают публичный IP; без него машина видит только внутреннюю сеть. Для исходящего доступа в интернет из приватных ресурсов (например, скачать обновление) используют NAT-шлюз — он выпускает трафик наружу, но не пускает входящий извне.

Правило простое: серверы и базы данных держат без публичного IP, а снаружи доступны только балансировщики и точки входа.

Группа безопасности (security group) — это файрвол (сетевой фильтр) на уровне ресурса: кто и на какой порт может подключиться. Хороший приём — писать правила не через IP-адреса, а через ссылку на другую группу: «к базе может подключаться только группа app», и неважно, какие у приложения адреса.

Типичная ошибка новичка — выдать базе данных публичный IP «чтобы удобно подключаться с ноутбука». Удобство решается иначе (через bastion-хост), а публичная база — приглашение для сканеров и переборщиков паролей. Глубже про сетевую модель — в статье про сеть в Yandex Cloud.

Где это применяется

Эти четыре опоры всплывают в любой работе с Yandex Cloud. Создаёте машину — выбираете каталог, зону и подсеть. Запускаете приложение — привязываете сервисный аккаунт вместо ключей. Поднимаете базу — держите её без публичного IP и закрываете группой безопасности. Любой следующий сервис (вычисления, бессерверные функции, управляемые базы данных) стоит на этом фундаменте.

Где спотыкаются начинающие:

  • Хранят ключи сервисного аккаунта в коде или в git. Самая частая и дорогая ошибка. На виртуальных машинах используйте привязанный сервисный аккаунт, а ключи — только там, где без них никак.
  • Раздают роль editor или admin на весь каталог, чтобы поскорее заработало, и потом забывают сузить.
  • Выдают базе публичный IP ради удобства — и получают сканирование извне.
  • Путают регион и зону или не понимают, почему ресурс «не виден»: часто он создан в другой зоне или другом каталоге.
  • Игнорируют трафик между зонами — а он тихо капает в счёт.

Что учить дальше. Логичный следующий шаг — глубже разобрать сеть и IAM, затем посмотреть, где запускать сервис. Когда дойдёт до автоматизации, не создавайте всё руками в консоли — описывайте инфраструктуру кодом: начните с основ infrastructure as code, а инструментом в Yandex Cloud выступает Terraform.