Microsoft AZ-900: Архитектура и глобальная инфраструктура Azure — Руководство по подготовке

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Часть Microsoft Azure AZ-900 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Глобальная архитектура Azure спроектирована для предоставления устойчивых, производительных и соответствующих требованиям облачных сервисов в любом масштабе. Понимание физической структуры географий, регионов и зон доступности, а также логической иерархии групп управления, подписок, групп ресурсов и ресурсов, лежит в основе надежного проектирования и управления. Плоскость управления, предоставляемая Azure Resource Manager, в сочетании с декларативными шаблонами обеспечивает согласованные, повторяемые развертывания, соответствующие политикам организации и требованиям безопасности. Проектные решения в этой области напрямую влияют на целевые показатели доступности, обязательства по размещению данных и пользовательский опыт по всему миру. Выбор правильной модели избыточности, расчет совокупных SLA и выбор глобальных сервисов маршрутизации, таких как Azure Front Door, Traffic Manager и Azure CDN, являются ключевыми для достижения целей непрерывности бизнеса, соответствия требованиям и производительности.

Географии, регионы, зоны доступности и парные регионы

Географии Azure — это определенные наборы регионов, которые сохраняют границы резидентности данных и соответствия требованиям. Примеры включают United States, Europe, United Kingdom, Australia и Canada, а также суверенные облака с особыми моделями соответствия и подключения. Рабочие нагрузки, которые должны оставаться в пределах определенной юрисдикции, следует развертывать в регионах, принадлежащих к целевой географии, чтобы обеспечить соответствие нормативным требованиям и резидентность данных. Регион — это набор дата-центров, развернутых в пределах периметра с определенной задержкой и соединенных выделенной сетью с низкой задержкой. Не все сервисы или функции доступны в каждом регионе, поэтому наличие мощностей и функций следует проверять на ранних этапах планирования. Регионы, поддерживающие зоны доступности (Availability Zones), предоставляют три или более физически разделенных зоны дата-центров с независимым электропитанием, охлаждением и сетевой инфраструктурой. Зонально-избыточные сервисы (ZRS) и архитектура, распределенная по зонам, защищают от сбоев на уровне дата-центра, сохраняя при этом доступ с низкой задержкой в пределах региона. Каждый регион Azure объединен в пару с другим регионом в той же географии, образуя парный регион (например, North Europe с West Europe, East US с West US). Парные регионы обеспечивают приоритетное восстановление во время масштабных сбоев, поэтапные обновления платформы и репликацию данных для определенных сервисов. Геоизбыточные опции Azure Storage (GRS/GZRS) асинхронно реплицируют данные в парный регион; когда требуется доступ на чтение к вторичной реплике, используйте RA-GRS или RA-GZRS, чтобы разрешить чтение из вторичной конечной точки во время сбоя или плановой отработки отказа. Для критически важных рабочих нагрузок, требующих как высокой доступности в пределах региона, так и межрегионального аварийного восстановления, сочетайте зональную избыточность с репликацией в парный регион. Балансирование между задержкой, отказоустойчивостью и соответствием требованиям приводит к общему шаблону: развертывание активных рабочих нагрузок по зонам в основном регионе и защита от региональных сбоев путем репликации данных и предоставления путей отработки отказа в парный регион. Регулярно проверяйте планы отработки отказа (runbooks) и поведение DNS или маршрутизации внешнего интерфейса, чтобы убедиться в достижении целевых показателей восстановления.

• География (Geography)
  • Область: Граница из нескольких регионов
  • Ключевое преимущество: Резидентность данных и соответствие требованиям
  • Типичное использование: Соответствие нормативным требованиям (например, для данных в ЕС)
• Регион (Region)
  • Область: Одна городская агломерация
  • Ключевое преимущество: Доступ к сервисам с низкой задержкой
  • Типичное использование: Основное место развертывания
• Зона доступности (Availability Zone)
  • Область: Отдельные дата-центры в пределах региона
  • Ключевое преимущество: Изоляция сбоев на уровне дата-центра
  • Типичное использование: Высокая доступность в пределах региона
• Парный регион (Region Pair)
  • Область: Два региона в одной географии
  • Ключевое преимущество: Скоординированное восстановление и обновления
  • Типичное использование: Межрегиональное аварийное восстановление

Организация и управление ресурсами: группы управления, подписки, группы ресурсов и ресурсы

Иерархия управления Azure позволяет масштабируемо контролировать политики, доступ и затраты. Группы управления находятся над подписками и позволяют централизованно применять Azure Policy и управление доступом на основе ролей (RBAC), при этом наследование распространяется на дочерние группы управления и подписки. Это подходящая структура для сегментации по подразделениям компании, уровням сред (рабочая, нерабочая) или по нормативным границам, сохраняя при этом единые защитные механизмы. Подписки являются границей для администрирования, выставления счетов и квот. Они хорошо подходят для изоляции затрат и доступа для бизнес-подразделений, сред или приложений. Используйте последовательную схему организации подписок для разделения рабочих и нерабочих сред, а также для применения лимитов и бюджетов. Для организаций с несколькими подразделениями и децентрализованным администрированием выделите каждому подразделению одну или несколько подписок и поместите их в специфичные для подразделения группы управления для чистого наследования политик и RBAC. Группы ресурсов — это логические контейнеры для ресурсов с общим жизненным циклом. Они обеспечивают атомарное развертывание, последовательное применение тегов и операции жизненного цикла, такие как удаление или блокировка. Группируйте ресурсы, которые развертываются, обновляются и выводятся из эксплуатации вместе, например, веб-уровень и его компоненты мониторинга. Используйте теги для реализации механизмов chargeback/showback, отслеживания владения, среды и атрибутов соответствия для ресурсов и групп. Блокировки (ReadOnly, CanNotDelete) добавляют защиту от случайного удаления на уровне ресурса или группы. Ресурсы — это развернутые экземпляры служб (виртуальные машины, планы App Service, учетные записи хранения). Области действия RBAC (группа управления, подписка, группа ресурсов, ресурс) позволяют предоставлять доступ с минимальными привилегиями именно там, где это необходимо. Для развертываний с несколькими подразделениями используйте один тенант Microsoft Entra ID, если только нет строгих требований к соответствию или автономии, требующих нескольких тенантов; подписки и группы управления обычно обеспечивают достаточное разделение с гораздо меньшими административными накладными расходами.

• Группа управления
  • Основное назначение: Управление в масштабе организации
  • Применяемые средства контроля: RBAC, Policy, Blueprints (через Policy + шаблоны)
  • Типичные сценарии: Сегментация по подразделениям/нормативным требованиям
• Подписка
  • Основное назначение: Граница для биллинга и квот
  • Применяемые средства контроля: Бюджеты, RBAC, Policy
  • Типичные сценарии: Изоляция по бизнес-подразделениям или средам
• Группа ресурсов
  • Основное назначение: Граница жизненного цикла
  • Применяемые средства контроля: Блокировки, теги, RBAC
  • Типичные сценарии: Для каждого приложения или рабочей нагрузки
• Ресурс
  • Основное назначение: Экземпляр службы
  • Применяемые средства контроля: RBAC на уровне экземпляра, теги
  • Типичные сценарии: Отдельные компоненты службы

Azure Resource Manager и шаблоны

Azure Resource Manager (ARM) — это уровень управления (control plane) для развертывания, обновления и удаления ресурсов Azure через единый API и модель на основе ролей. ARM обеспечивает идемпотентные операции, управление зависимостями, применение тегов и принудительное применение политик во время развертывания, что позволяет встраивать управление платформой в каждое изменение. Декларативные шаблоны ARM описывают желаемое состояние вашей среды в формате JSON и поддерживают параметры, переменные, условия и модульные связанные шаблоны. Они обеспечивают повторяемые, контролируемые версиями развертывания в различных средах и подписках. Для упрощения разработки Bicep предлагает лаконичный синтаксис, который транслируется в шаблоны ARM, сохраняя при этом тот же механизм развертывания и преимущества. Храните шаблоны в системе контроля версий, упаковывайте их как спецификации шаблонов (template specs) для совместного использования и интегрируйте в конвейеры CI/CD, чтобы обеспечить проверяемые изменения инфраструктуры без дрифта. Конфиденциальные значения, такие как пароли администратора или строки подключения, никогда не должны встраиваться в шаблоны. Используйте параметры типа secureString/secureObject со ссылками на Key Vault, чтобы ARM извлекал секреты во время развертывания, не раскрывая их в логах. Сочетайте шаблоны с управляемыми удостоверениями (managed identities), чтобы исключить жестко закодированные учетные данные из автоматизации. Этот подход снижает риски, сохраняя при этом полную автоматизацию для крупномасштабных развертываний в нескольких подписках.

• Идемпотентные развертывания
  • Поддержка ARM/шаблонов: Да
  • Результат: Безопасные, повторяемые изменения
• Принудительное применение политик при развертывании
  • Поддержка ARM/шаблонов: Да
  • Результат: Защитные механизмы встроены в конвейеры
• Модульная композиция
  • Поддержка ARM/шаблонов: Связанные модули / модули Bicep
  • Результат: Повторное использование и стандартизация
• Обработка секретов
  • Поддержка ARM/шаблонов: Ссылки на Key Vault
  • Результат: Отсутствие секретов в коде или логах

Доступность, SLA, совокупные SLA и жизненный цикл служб

Azure публикует соглашения об уровне обслуживания (SLA) с финансовыми гарантиями для общедоступных (GA) служб. Для виртуальных машин доступность зависит от топологии развертывания: одна ВМ с хранилищем Premium SSD имеет SLA 99,9%; две или более ВМ в группе доступности — SLA 99,95%; а две или более ВМ, развернутые в разных зонах доступности, достигают SLA 99,99%. Платформенные службы (например, Azure SQL Database или App Service) имеют собственные SLA, которые могут различаться в зависимости от уровня служб или варианта избыточности. Приводите архитектуру в соответствие с целевым SLA, выбирая подходящую модель избыточности и уровни служб. Когда решение зависит от нескольких служб, совокупный SLA является произведением индивидуальных SLA, если для работы приложения требуются все компоненты. Например, если веб-приложение (99,95%) зависит от базы данных (99,99%), совокупная доступность составит примерно 0,9995 × 0,9999 = 99,94%. Повышение избыточности на любом уровне — например, развертывание в нескольких зонах, добавление нескольких экземпляров за балансировщиком нагрузки или использование геоизбыточных хранилищ данных — улучшает фактическую доступность. И наоборот, добавление последовательных зависимостей снижает совокупный SLA, и его следует обосновывать явной функциональной ценностью. Статус жизненного цикла службы влияет на гарантии надежности. Функции в статусе Public Preview предлагаются для сбора отзывов и могут быть ограничены определенными регионами или иметь неполный функционал; как правило, на них не распространяется SLA, и их не рекомендуется использовать для критически важных производственных процессов. Функции в статусе GA (общедоступные) готовы к использованию в производственной среде и покрываются SLA. Следует отслеживать планы развития (roadmaps) и графики развертывания по регионам, чтобы избежать непреднамеренного использования предварительных версий функций в производственных архитектурах, особенно в средах с высокими требованиями к соответствию нормам. Целевые показатели аварийного восстановления, такие как RPO и RTO, дополняют SLA и определяют выбор проектных решений, таких как межзонная или межрегиональная репликация, частота резервного копирования и оркестрация отработки отказа. Регулярно проверяйте процедуры отработки отказа, чтобы убедиться, что измеряемая производительность восстановления соответствует бизнес-целям и что зависимости от DNS, сертификатов и удостоверений также восстанавливаются должным образом.

• Одна ВМ (Premium SSD)
  • Ориентировочный SLA: 99,9%
  • Примечания: Для некритичных рабочих нагрузок или отказоустойчивых приложений
• 2+ ВМ в группе доступности
  • Ориентировочный SLA: 99,95%
  • Примечания: Защищает от сбоев на уровне стойки/домена сбоя
• 2+ ВМ в разных зонах доступности
  • Ориентировочный SLA: 99,99%
  • Примечания: Защищает от сбоев на уровне центра обработки данных
• Функция в статусе Public Preview
  • Ориентировочный SLA: Без финансового SLA
  • Примечания: Оценивайте; избегайте использования в критически важных процессах
• Функция в статусе GA (зависит от уровня службы)
  • Ориентировочный SLA: Покрывается SLA
  • Примечания: Проверяйте SLA для конкретного уровня и региона

Глобальная маршрутизация и доставка контента: Azure Front Door, Traffic Manager и Azure CDN

Качество глобального пользовательского опыта зависит от интеллектуальной маршрутизации, близости к контенту и быстрой отработки отказа. Azure Front Door — это глобальный обратный прокси-сервер уровня 7 (Layer 7) с технологией anycast, оснащенный брандмауэром веб-приложений (WAF), терминированием TLS, маршрутизацией на основе URL/пути, привязкой сеансов и пробами работоспособности с периметра сети. Он ускоряет доставку динамического контента с помощью split-TCP и оптимизации протоколов, а также обеспечивает почти мгновенную отработку отказа между серверами-источниками. Front Door идеально подходит для многорегиональных веб-приложений и API в конфигурациях active-active или active-passive, где требуется как производительность, так и централизованная безопасность на периметре сети. Azure Traffic Manager — это служба распределения трафика на основе DNS, которая направляет клиентов на лучший эндпоинт, используя политики, такие как приоритет, весовая, производительность (задержка), географическая, по подсети или многозначная. Поскольку он работает на уровне DNS, он поддерживает эндпоинты, отличные от HTTP (например, службы TCP), и гибридные сценарии, но скорость отработки отказа ограничена значением TTL в DNS и кэшированием на стороне клиента. Traffic Manager не проксирует трафик и не ускоряет доставку контента; он просто отвечает на DNS-запрос, указывая выбранный эндпоинт. Azure CDN кэширует статический контент в пограничных точках присутствия (points of presence), чтобы уменьшить задержку и снизить нагрузку на серверы-источники. Он хорошо подходит для больших статических ресурсов, таких как изображения, видео, скрипты и файлы для скачивания. Хотя CDN сокращает время приема-передачи для кэшируемого контента, он не является глобальным балансировщиком нагрузки с проверкой работоспособности для динамических источников; его следует комбинировать с Front Door или Traffic Manager для отработки отказа между несколькими источниками или для логики динамической маршрутизации. Во многих архитектурах перед одним и тем же приложением размещают CDN для кэширования статических ресурсов и Front Door для обработки динамического трафика и обеспечения безопасности.

• Azure Front Door (Std/Prm)
  • Уровень/Механизм: Anycast-прокси уровня 7
  • Основные сценарии использования: Глобальная балансировка нагрузки, безопасность на периметре, ускорение
  • Методы маршрутизации: Приоритет, весовая; правила на основе пути/хоста
  • Проверка работоспособности: Пробы из пограничных точек присутствия (POP)
  • Скорость отработки отказа: Секунды (почти мгновенно)
  • Ускорение динамического контента: Да
  • Кэширование статического контента: Да (на основе правил)
  • Наличие WAF: Да (встроенный)
  • Типичный шаблон: Front Door перед многорегиональными веб-приложениями/API
• Azure Traffic Manager
  • Уровень/Механизм: Политика на основе DNS
  • Основные сценарии использования: Межрегиональная DNS-маршрутизация; эндпоинты, отличные от HTTP
  • Методы маршрутизации: Приоритет, весовая, производительность, географическая, по подсети, многозначная
  • Проверка работоспособности: Глобальные пробы эндпоинтов
  • Скорость отработки отказа: Ограничена TTL (от десятков секунд до минут)
  • Ускорение динамического контента: Нет
  • Кэширование статического контента: Нет
  • Наличие WAF: Н/Д
  • Типичный шаблон: Управление через DNS для служб HTTP и не-HTTP
• Azure CDN
  • Уровень/Механизм: Сеть пограничного кэширования
  • Основные сценарии использования: Разгрузка статического контента и снижение задержки
  • Методы маршрутизации: Н/Д (правила кэширования)
  • Проверка работоспособности: Н/Д (опциональная отработка отказа для группы источников)
  • Скорость отработки отказа: Н/Д (на основе кэша)
  • Ускорение динамического контента: Нет (кроме кэша)
  • Кэширование статического контента: Да
  • Наличие WAF: Через Front Door Premium или отдельный WAF
  • Типичный шаблон: CDN для ресурсов + Front Door/Traffic Manager для источников

Практическая задача: Проектирование высокодоступной, соответствующей требованиям и глобально производительной веб-платформы для IronPeak Manufacturing

Сценарий: IronPeak Manufacturing работает в Европе и Северной Америке и консолидирует порталы для клиентов и партнеров на платформе Azure. Платформа должна обеспечивать доступность веб-уровня 99,99%, хранить данные клиентов из ЕС в пределах ЕС, обеспечивать быстрое аварийное переключение между регионами и быструю загрузку страниц по всему миру. Команда хочет полностью автоматизировать развертывания без хранения секретов в виде открытого текста в коде или логах.

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

Рекомендуемый подход:

1. Выберите географию Europe и разверните основную рабочую нагрузку в регионе с Availability Zones (например, West Europe), используя два или более экземпляра VM scale set или App Service, распределенных по зонам.
2. Включите межрегиональное аварийное восстановление в парный регион (North Europe), используя встроенную репликацию сервисов: используйте RA-GZRS для Storage и георепликацию для баз данных, где это возможно; настройте автоматизированные сценарии runbooks для аварийного переключения.
3. Используйте Azure Front Door Standard/Premium в качестве фронтенда для приложения, чтобы обеспечить глобальное терминирование HTTPS, WAF, проверки работоспособности на границе сети, отказоустойчивость на основе приоритетов между West Europe (основной) и North Europe (вторичный), а также правила для маршрутизации на основе путей.
4. Кэшируйте статические ресурсы (изображения, скрипты, файлы для скачивания) с помощью Azure CDN, интегрированного с теми же источниками, чтобы уменьшить задержку и снизить нагрузку на трафик; проверьте правила кэширования и TTL.
5. Определите группы управления для подразделений в EU и NA; разместите под ними рабочие и нерабочие подписки, применяя Azure Policy для обеспечения резидентности данных, тегирования и указания разрешенных местоположений.
6. Внедрите шаблоны ARM/Bicep, хранящиеся в системе контроля версий и опубликованные как спецификации шаблонов; параметризуйте регионы, SKU и масштабирование; ссылайтесь на секреты из Azure Key Vault, используя управляемые удостоверения для развертываний.
7. Установите SLA и протестируйте совокупную доступность: два распределенных по зонам экземпляра за Azure Front Door нацелены на 99,99% для уровня приложений; ежеквартально проверяйте сквозные учения по аварийному переключению, DNS, сертификаты и зависимости удостоверений.
8. Инструментируйте платформу с помощью Application Insights и Azure Monitor; настройте проверки работоспособности и оповещения в Azure Front Door; настройте политики автомасштабирования и кэширования на основе данных телеметрии.

Обоснование выбора Azure: Эта архитектура обеспечивает хранение данных ЕС в пределах географии Europe, предоставляя при этом изоляцию от сбоев в пределах региона с помощью Availability Zones и межрегиональное аварийное восстановление в парный регион. Azure Front Door обеспечивает глобальное ускорение и отказоустойчивость с учетом работоспособности для динамического трафика, в то время как Azure CDN снижает нагрузку на статический контент для повышения производительности. Шаблоны ARM/Bicep со ссылками на Key Vault обеспечивают повторяемые и безопасные развертывания в разных подписках и регионах. Выбранные топологии соответствуют опубликованным SLA для достижения целевого показателя 99,99% для веб-уровня, а политики на уровне групп управления и подписок обеспечивают управление с минимальными операционными издержками.

← Облачные концепции · Все домены · Вычислительные ресурсы и службы приложений →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →