Группы управления и подписки

Azure организует ресурсы в иерархию из четырёх уровней. На верхнем уровне находятся группы управления — контейнеры, объединяющие подписки для централизованного применения политик и управления доступом. Ниже расположены подписки — единицы оплаты и границы ресурсов. Внутри подписок находятся группы ресурсов — логические контейнеры для связанных ресурсов. На нижнем уровне находятся ресурсы — отдельные службы, такие как VM, базы данных и учётные записи хранилища. Политики и разрешения, применённые на более высоких уровнях, распространяются на нижние уровни.

Подписка Azure одновременно является единицей оплаты и логической границей ресурсов. Использование всех ресурсов в подписке отражается в одном счёте. Подписки устанавливают ограничения (квоты) на количество ресурсов каждого типа, которые можно развернуть. Организации часто создают отдельные подписки для разных сред (Production, Development, Testing), бизнес-подразделений или географических регионов — каждая подписка имеет собственные отчёты о расходах и правила управления доступом.

Крупные предприятия используют несколько подписок по нескольким причинам. Изоляция — рабочие ресурсы полностью отделены от ресурсов разработки и тестирования; неправильная настройка в среде разработки не может повлиять на рабочую среду. Детализация оплаты — подписка каждого отдела формирует отдельный счёт, что упрощает распределение расходов. Ограничения подписок — Azure устанавливает квоты для каждой подписки (например, 250 VM на регион); для крупных рабочих нагрузок может потребоваться несколько подписок, чтобы не выходить за эти ограничения.

Management Group — это контейнер, расположенный выше подписок в иерархии Azure. Вы можете объединять подписки в группы управления и применять определения политик Azure и назначения ролей RBAC на уровне группы управления. Эти настройки распространяются на каждую подписку и ресурс внутри группы. Благодаря этому не нужно дублировать одну и ту же политику или назначение роли в десятках отдельных подписок.

Группы управления можно вкладывать друг в друга на глубину до шести уровней. В каждом каталоге Azure на вершине находится одна Root Management Group, под которой располагаются все остальные группы управления и подписки. Типичная иерархия предприятия может выглядеть так: Root → Company → Platform → Production → Landing Zones → отдельные подписки рабочих нагрузок. Политики, применённые на уровне Root, влияют на каждую подписку во всём каталоге.

Назначения контроля доступа на любом уровне иерархии наследуются нижестоящими уровнями. Если назначить пользователю роль Reader в группе управления, он автоматически получит доступ Reader ко всем подпискам и группам ресурсов внутри этой группы управления. Это наследование является аддитивным: отозвать унаследованное разрешение на нижнем уровне нельзя — можно только добавить дополнительные разрешения. Исключение составляют назначения запрета: они блокируют действия, даже если назначение роли разрешало бы их.

Аналогично, назначения Azure Policy на уровне группы управления применяются ко всем подпискам, группам ресурсов и ресурсам внутри этой группы. Распространённый подход — назначить корпоративную базовую политику на уровне Root или группы управления Company, чтобы обеспечить соблюдение таких стандартов, как разрешённые регионы, обязательные теги или необходимые параметры диагностики, во всей организации. При этом владельцы отдельных подписок могут добавлять более конкретные политики на нижних уровнях, не изменяя корпоративную базовую политику.

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

Крупные организации получают доступ к Azure через соглашения о выставлении счетов, которые влияют на структуру подписок. Enterprise Agreement (EA) предоставляет подписки в рамках регистрации с централизованным платёжным аккаунтом для крупных согласованных расходов. Microsoft Customer Agreement (MCA) — современный преемник этого соглашения, предлагающий более широкие возможности самостоятельного управления подписками. В обоих случаях платёжные профили и разделы счёта позволяют группировать расходы по подпискам для разных отделов.

У каждой подписки Azure есть квоты служб — мягкие ограничения на количество ресурсов каждого типа, которые могут существовать в регионе. Примеры значений по умолчанию: 20 000 vCPUs на регион, 980 групп ресурсов на подписку и 800 управляемых дисков на подписку. Когда рабочая нагрузка приближается к квоте, вы можете отправить запрос на увеличение квоты на портале Azure (Поддержка и устранение неполадок > Новый запрос в службу поддержки). Для масштабного горизонтального масштабирования Microsoft рекомендует распределять рабочие нагрузки между несколькими подписками.

Microsoft рекомендует несколько передовых методов проектирования групп управления. Не используйте более трёх-четырёх уровней вложенности — слишком большое количество уровней усложняет поиск причин проблем с политиками. Создайте отдельную группу управления Platform для общих служб (удостоверение, подключение и управление), отделив её от рабочих нагрузок в landing zone. Разделите Production и непроизводственные среды на разные группы управления, чтобы политики, предназначенные только для Production (например, отключение доступа к общедоступному Интернету), случайно не применялись к средам разработки.

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900), рассмотренных в этом уроке.

В этом уроке вы узнали, что иерархия ресурсов Azure простирается от групп управления к подпискам, группам ресурсов и ресурсам, политики и назначения RBAC на уровне группы управления наследуются всеми дочерними подписками, а несколько подписок обеспечивают изоляцию выставления счетов, разделение сред и обход ограничений квот для отдельных подписок. Далее мы подробно рассмотрим Azure Policy.