Microsoft Azure — это большой набор облачных сервисов: серверы, базы данных, хранилища, сеть и ещё пара сотен вещей. На первый взгляд это стена из названий, и легко растеряться. Но почти всё стоит на четырёх опорах. Разберитесь с ними — и остальное встроится в понятную картину.

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

Иерархия: подписка и группа ресурсов

В Azure ресурсы разложены по нескольким уровням.

  • Клиент (tenant) — верхний уровень, ваш каталог удостоверений в Microsoft Entra ID (бывший Azure AD). Здесь живут пользователи и настройки входа.
  • Подписка (subscription) — единица биллинга и изоляции: к подписке привязан счёт, у неё свои лимиты. Обычно заводят отдельные подписки под production и под dev/test.
  • Группа ресурсов (resource group) — контейнер, внутри которого создаются сами ресурсы: виртуальные машины, базы, сети. Это граница управления: всю группу можно удалить целиком, права удобно выдавать на неё.

Крупные организации добавляют сверху группы управления (management groups), чтобы применять политики сразу к нескольким подпискам. Практика та же, что в других облаках: под разные среды — разные подписки или хотя бы разные группы ресурсов, чтобы ошибка в одной не задела боевую систему, а в счёте было видно, кто сколько потратил. (В терминах AWS подписка примерно соответствует аккаунту, а группа ресурсов — удобной границе внутри него.)

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

Entra ID и RBAC: кто и что может делать

В Azure доступ делится на две связанные системы.

Microsoft Entra ID отвечает на вопрос «кто ты» — это каталог удостоверений: пользователи, группы, приложения. Через него входят люди (в том числе по корпоративному SSO) и регистрируются приложения.

Azure RBAC (role-based access control) отвечает на вопрос «что тебе можно» с ресурсами. Здесь два ключевых понятия:

  • Роль — набор разрешений. Есть широкие встроенные роли — Owner (всё, включая раздачу прав), Contributor (создавать и менять, но не раздавать права), Reader (только смотреть) — и множество узких сервисных ролей вроде «Storage Blob Data Contributor».
  • Назначение роли (role assignment) — «кому — какую роль — на каком уровне». Роль выдают на подписку, группу ресурсов или отдельный ресурс, и права наследуются вниз.

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

Первое: ваш код не должен носить с собой ключи. Когда приложение работает в Azure, ему дают управляемое удостоверение (managed identity) — платформа сама выдаёт временные токены, а библиотека Azure (SDK) находит их автоматически. Это тот же принцип, что instance profile в AWS. Ключи в конфиге или в git — классический путь к утечке. Подробнее — в статье про Entra ID и RBAC.

Второе: минимум прав (least privilege). Давайте роли ровно то, что нужно: сервису — доступ к своему хранилищу и своей базе, а не Contributor на всю группу ресурсов. Узкие права — лишние десять минут; широкие — потенциальный инцидент.

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

Регион — географическая площадка Azure: например, West Europe, North Europe. Ресурсы привязаны к региону, и данные сами между регионами не путешествуют — копию в другом регионе настраивают отдельно.

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

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

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

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

Виртуальная сеть

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

  • Подсети (subnets) разрезают адресное пространство VNet. Ресурсы получают внутренний IP; чтобы стать доступным из интернета, ресурсу нужен публичный IP (или он прячется за балансировщиком).
  • Network Security Group (NSG) — файрвол (сетевой фильтр) с разрешающими и запрещающими правилами; вешается на подсеть или сетевой интерфейс. Хороший приём — писать правила не через IP-адреса, а через теги и ссылки.
  • Для исходящего доступа из внутренних ресурсов используют NAT Gateway, а до сервисов Azure по приватной сети дотягиваются через Private Link / приватные эндпоинты, не выходя в интернет.

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

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

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

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

  • Хранят ключи в коде или git вместо managed identity — самая частая и дорогая ошибка.
  • Раздают Contributor/Owner широко «чтобы заработало» и забывают сузить.
  • Дают базе публичный IP ради удобства — и получают сканирование извне.
  • Путают регион и зону или не понимают, почему ресурс «не виден» — часто он в другой подписке или регионе.

Что учить дальше: глубже сеть и Entra ID с RBAC, затем — где запускать сервис. Когда дойдёт до автоматизации, описывайте инфраструктуру кодом: Bicep, ARM и Terraform. Аналогичный разбор для Amazon — основы AWS.