Microsoft AZ-900: Облачные концепции — Руководство по подготовке

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

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

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

Ключевые характеристики облака: масштабируемость, эластичность, гибкость и отказоустойчивость

Масштабируемость — это способность рабочей нагрузки справляться с возросшим спросом путем добавления ресурсов. В Azure это проявляется в двух формах: вертикальное масштабирование (scale up) путем выбора ВМ большего размера или более высоких планов App Service, и горизонтальное масштабирование (scale out) путем добавления экземпляров через Virtual Machine Scale Sets (VMSS), пулы узлов Azure Kubernetes Service (AKS) или автомасштабирование App Service. Масштабирование в обратном направлении уменьшает мощность и затраты при падении спроса. Проектирование уровней без сохранения состояния (stateless) и вынесение состояния вовне (например, в Azure Cache for Redis или Azure SQL Database) делает горизонтальное масштабирование предсказуемым и быстрым. Эластичность — это автоматизированное, управляемое политиками масштабирование, которое постоянно приводит мощность в соответствие с нагрузкой. Правила автомасштабирования Azure Monitor, кластерный автомасштабировщик AKS и бессерверные опции, такие как Azure Functions или планы Consumption/Elastic Premium, расширяют и сокращают ресурсы практически в реальном времени. Эластичные архитектуры минимизируют простаивающие мощности и хорошо подходят для нагрузок с резкими пиками или сезонными колебаниями, точно сопоставляя расходы с использованием. Гибкость — это скорость, с которой команды поставляют изменения. Развертывание ресурсов Azure с помощью шаблонов Bicep или ARM, конвейеров GitHub Actions или Azure DevOps, а также абстракции ресурсов, такие как App Service или AKS, позволяют выполнять частые релизы с низким риском. Самостоятельное предоставление ресурсов через RBAC и защитные механизмы политик (policy guardrails) сокращает время ожидания, сохраняя при этом управляемость. Гибкость является продуктом как платформы, так и организационных практик; чем больше платформа абстрагирует рутинную низкоуровневую работу, тем быстрее могут двигаться команды. Отказоустойчивость и аварийное восстановление решают проблемы сбоев разного масштаба. Отказоустойчивость смягчает последствия сбоев компонентов и центров обработки данных в пределах одного региона с помощью групп доступности (Availability Sets, распределяющих ВМ по доменам сбоя/обновления), зон доступности (Availability Zones, физически разделенных ЦОД в пределах региона), балансировщиков нагрузки и избыточных путей передачи данных. Аварийное восстановление готовит к сбоям на уровне региона с помощью межрегиональной репликации (хранилище GRS/RA-GRS, активная георепликация Azure SQL, многорегиональные записи в Cosmos DB) и инструментов восстановления, таких как Azure Site Recovery. Определите четкие целевые показатели RTO/RPO и тестируйте переключение при сбое, чтобы убедиться, что архитектура соответствует целям непрерывности бизнеса.

Модели обслуживания и разделение ответственности

Модели облачного обслуживания определяют, чем управляете вы, а чем — Azure. Инфраструктура как услуга (IaaS) предоставляет базовые строительные блоки: вычислительные ресурсы, хранилища и сети. Вы контролируете гостевую ОС, среду выполнения и приложения — это идеальный вариант, когда вам нужны пользовательские образы, специализированное промежуточное ПО или полный контроль. Платформа как услуга (PaaS) абстрагирует ОС и большую часть промежуточного ПО, предоставляя управляемые среды выполнения, базы данных и интеграционные сервисы, чтобы команды могли сосредоточиться на коде и данных. Программное обеспечение как услуга (SaaS) предоставляет готовые приложения, используемые через браузер или API, с минимальной настройкой и без обязательств по хостингу приложений. Модель разделения ответственности проясняет операционные границы. В IaaS Azure управляет физическим ЦОД, хостами и гипервизором; вы отвечаете за установку исправлений для ОС, ее защиту, обновление приложений, управление удостоверениями и доступом, а также управление данными. В PaaS Azure также управляет ОС и промежуточным ПО платформы; вы управляете кодом приложения, его конфигурацией и данными. В SaaS Azure (или поставщик SaaS) управляет всем стеком; вы управляете пользователями, доступом, классификацией данных и конфигурацией использования. Во всех моделях клиенты сохраняют ответственность за удостоверения, разрешения, безопасность конечных точек и политики защиты данных. Выбор правильной модели влияет на целевые показатели доступности и стоимость. Развертывание виртуальных машин Azure — это задача IaaS; веб-API в Azure App Service или контейнеры в AKS относятся к PaaS; Microsoft 365 и Dynamics 365 — это SaaS. По возможности отдавайте предпочтение PaaS и SaaS, чтобы ускорить поставку и снизить операционную нагрузку, оставляя IaaS для рабочих нагрузок, требующих контроля на уровне ОС или имеющих унаследованные зависимости.

• IaaS
  • Типичные службы Azure: Azure Virtual Machines, VM Scale Sets, Azure Disks, Virtual Network
  • Чем управляете вы: Гостевая ОС, патчи, среда выполнения, приложения, данные, резервные копии, антивирус/EDR
  • Когда выбирать: Полный контроль над ОС, кастомное промежуточное ПО, миграция lift-and-shift
• PaaS
  • Типичные службы Azure: Azure App Service, Azure SQL Database/Managed Instance, AKS, Azure Functions, Azure Integration Services
  • Чем управляете вы: Код/конфигурация, схема, данные, удостоверения и доступ
  • Когда выбирать: Ускорение разработки, встроенное масштабирование/высокая доступность, снижение операционных затрат
• SaaS
  • Типичные службы Azure: Microsoft 365, Dynamics 365, Power BI, Azure DevOps Services
  • Чем управляете вы: Пользователи, роли, использование/конфигурация данных
  • Когда выбирать: Готовые приложения с минимальным управлением

Модели развертывания и масштабирование

Публичное облако развертывает рабочие нагрузки в центрах обработки данных, принадлежащих Microsoft, которые используются совместно несколькими клиентами (tenants) с логической изоляцией. Оно предлагает самый широкий каталог услуг, глобальный охват, быстрое выделение ресурсов и чистую модель оплаты по мере использования (pay-as-you-go). Частное облако выделяет инфраструктуру для одной организации, часто по нормативным причинам или из соображений суверенитета данных, и может работать на проверенных Azure стеках, таких как Azure Stack Hub или Azure Stack HCI. Гибридное облако соединяет локальную инфраструктуру (on-premises) и Azure с помощью единых удостоверений, политик и сетей, обеспечивая поэтапную миграцию и локальность данных, при этом позволяя использовать эластичность облака там, где это целесообразно. Глобальное и локальное масштабирование касаются области повышения доступности и производительности. Локальное масштабирование удерживает трафик внутри одного региона, используя зоны доступности (Availability Zones), масштабируемые наборы виртуальных машин (VM Scale Sets), Application Gateway и Azure Load Balancer для добавления экземпляров и изоляции сбоев на уровне ЦОД. Глобальное масштабирование распределяет трафик между регионами с помощью Azure Front Door (современный глобальный балансировщик нагрузки 7-го уровня с WAF и технологией anycast), Azure Traffic Manager (балансировка нагрузки на основе DNS) и сервисов с георепликацией данных, таких как георепликация Azure SQL или многорегиональное распределение Cosmos DB. Многорегиональные архитектуры в режиме active/active улучшают задержку и отказоустойчивость, но требуют тщательного планирования согласованности данных и затрат. Выбор модели развертывания часто начинается с ограничений, связанных с соответствием требованиям (compliance) и сетевым подключением, и развивается вместе с жизненным циклом приложения. Новые веб-приложения, создаваемые с нуля (greenfield), часто развертываются в PaaS публичного облака для скорости и масштабируемости. Сложные бизнес-системы (line-of-business) с зависимостями могут начинать свой путь в гибридной модели — сохраняя определенные сервисы локально (on-premises), в то время как фронтенды и уровни без состояния (stateless tiers) переносятся в Azure — и завершать переход по мере модернизации зависимостей.

• Публичное (Public)
  • Владение/Расположение: Регионы, принадлежащие Microsoft
  • Типичный доступ: Интернет/VPN/ExpressRoute
  • Сценарии использования: Эластичное масштабирование, глобальный охват, быстрые инновации
  • Примеры в Azure: Большинство сервисов Azure, Azure Front Door, Azure App Service
• Частное (Private)
  • Владение/Расположение: Выделенная инфраструктура клиента (локальная или размещенная у хостера)
  • Типичный доступ: Частные сети
  • Сценарии использования: Суверенитет данных, изолированные рабочие нагрузки, строгие требования соответствия
  • Примеры в Azure: Azure Stack Hub, Azure Stack HCI, AKS on HCI
• Гибридное (Hybrid)
  • Владение/Расположение: Смесь локальной инфраструктуры и Azure
  • Типичный доступ: Site-to-site VPN или ExpressRoute
  • Сценарии использования: Поэтапная миграция, локальность данных, интеграция с унаследованными системами
  • Примеры в Azure: Azure VPN Gateway, ExpressRoute, Azure Arc

Модели затрат: CapEx и OpEx, оплата по потреблению, оплата по мере использования и зарезервированные мощности

Закупка оборудования для локальной инфраструктуры (on-premises) обычно представляет собой капитальные затраты (CapEx): крупные первоначальные вложения в серверы, хранилища и сетевое оборудование, которые амортизируются в течение нескольких лет. Azure переворачивает эту модель в операционные затраты (OpEx): услуги измеряются и оплачиваются на основе фактического потребления — секунды ЦП, ГБ-месяцы, транзакции — перенося расходы на тот момент, когда извлекается ценность. Такая модель ценообразования, основанная на потреблении, сокращает избыточное выделение ресурсов (over-provisioning) и привязывает затраты к характеру использования. Оплата по мере использования (Pay-as-you-go) обеспечивает максимальную гибкость: запускайте и останавливайте ресурсы по желанию без долгосрочных обязательств. Для стабильных рабочих нагрузок Azure предлагает скидки на основе резервирования, такие как зарезервированные экземпляры виртуальных машин (Reserved Virtual Machine Instances), зарезервированные мощности Azure SQL Database, резервирование ЕЗ/с (RU/s) в Cosmos DB и зарезервированная емкость хранилища (Storage reserved capacity). Обязательства на один или три года могут дать значительную экономию, при этом опционально предоставляя гибкость в выборе размера экземпляра и возможность совместного использования в рамках нескольких подписок. Дополнительные опции включают планы экономии Azure для вычислений (Azure Savings Plans for Compute), которые применяют скидки к соответствующим вычислительным службам, и точечные виртуальные машины (Spot VMs) для прерываемых пакетных рабочих нагрузок с очень большими скидками. Эффективное управление затратами сочетает правильную коммерческую модель с инженерными средствами контроля. Автомасштабирование (Autoscale) сокращает время простоя мощностей; бессерверные (serverless) уровни устраняют затраты на инфраструктуру во время простоя; Azure Hybrid Benefit позволяет использовать существующие лицензии Windows Server и SQL Server; тарифы для разработки и тестирования (Dev/Test) снижают расходы на непроизводственные среды. Сервис Azure Cost Management + Billing предоставляет инструменты для создания бюджетов, обнаружения аномалий и распределения затрат для их постоянной оптимизации.

• Оплата по мере использования (Pay-as-you-go)
  • Обязательства: Нет
  • Типичная скидка по сравнению с PAYG: 0%
  • Гибкость: Максимальная; запуск/остановка в любое время
  • Лучше всего подходит для: Непредсказуемых или кратковременных рабочих нагрузок
• Зарезервированные экземпляры ВМ / Зарезервированные мощности (Reserved capacity)
  • Обязательства: 1 год или 3 года
  • Типичная скидка по сравнению с PAYG: До ~72% (с Azure Hybrid Benefit)
  • Гибкость: Область действия может быть общей; разрешен обмен; плата за досрочную отмену
  • Лучше всего подходит для: Стабильных круглосуточных вычислений, баз данных, Cosmos DB
• План экономии для вычислений (Savings Plan for Compute)
  • Обязательства: Обязательство по расходам на 1 или 3 года
  • Типичная скидка по сравнению с PAYG: До ~65%
  • Гибкость: Применяется к ВМ, AKS, Functions Premium, App Service
  • Лучше всего подходит для: Смешанных вычислительных нагрузок с меняющимися типами экземпляров
• Точечные ВМ (Spot VMs)
  • Обязательства: Нет (зависит от наличия свободных мощностей)
  • Типичная скидка по сравнению с PAYG: До ~90%
  • Гибкость: Могут быть вытеснены; нет SLA
  • Лучше всего подходит для: Пакетных, нехранящих состояние (stateless) нагрузок, CI, задач рендеринга

Практическая задача: PeakGear Retail: сезонное масштабирование с контролем затрат и отказоустойчивостью

Сценарий: У компании PeakGear Retail есть сайт электронной коммерции с предсказуемыми всплесками трафика в конце месяца и в праздничные дни. Компания хочет перейти с локальных виртуальных машин на Azure, сократить капитальные затраты, поддерживать целевой показатель доступности веб-уровня в 99,99% и внедрить план аварийного восстановления с RTO в четыре часа и RPO в 15 минут. Управление удостоверениями должно интегрироваться с существующими пользователями через Microsoft Entra ID.

Задача: Разработать архитектуру и модель затрат в Azure, которые обеспечат эластичное масштабирование для всплесков трафика, отказоустойчивость на уровне зон, межрегиональное аварийное восстановление и простоту эксплуатации при минимизации затрат в периоды низкой нагрузки.

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

1. Развернуть веб-API и витрину в Azure App Service (PaaS), используя планы Premium v3, чтобы получить встроенное автомасштабирование, управляемое обновление платформы и опции избыточности в зонах.
2. Разместить два или более экземпляров App Service за Azure Front Door Standard/Premium для получения глобальной точки входа anycast, терминирования SSL, WAF и маршрутизации на основе путей; включить пробы работоспособности и привязку сеансов по мере необходимости.
3. Использовать Azure SQL Database уровня Business Critical с избыточностью в зонах в основном регионе; настроить активную георепликацию в парный вторичный регион для достижения RPO в 15 минут.
4. Хранить статический контент в Azure Storage с опцией RA-GRS; использовать перед ним Azure CDN от Microsoft, чтобы снизить нагрузку на канал и уменьшить задержку.
5. Внедрить правила автомасштабирования на основе загрузки CPU, количества запросов и глубины очереди для горизонтального масштабирования (scale out) во время всплесков и сжатия (scale in) в периоды затишья; для фоновых заданий использовать планы Azure Functions Consumption или Elastic Premium.
6. Достичь доступности веб-уровня 99,99%, включив избыточность в зонах (multi-zone) для плана App Service или распределив экземпляры по Зонам доступности, где это поддерживается.
7. Для гибкости на начальном этапе использовать модель оплаты по мере использования (pay-as-you-go); для стабильной базовой мощности, определенной через 30 дней, приобрести 1-летние Reserved Instance для планов App Service (через Savings Plan for Compute, покрывающий App Service) и зарезервированную емкость для SQL Database, чтобы снизить текущие эксплуатационные расходы.
8. Интегрировать Microsoft Entra ID для доступа пользователей и администраторов; применять принцип наименьших привилегий с помощью встроенных ролей и условного доступа; защитить секреты в Azure Key Vault, на который ссылаются App Service и конвейеры развертывания.
9. Определить и протестировать сценарии аварийного восстановления (runbooks): выполнить отработку отказа SQL на вторичный регион, обновить приоритеты источников в Front Door для активации вторичного региона и проверить работоспособность приложения в рамках четырехчасового RTO.
10. Внедрить Azure Monitor и Log Analytics для централизованного сбора метрик, трассировок и журналов; настроить оповещения и панели мониторинга; установить бюджеты и оповещения об аномалиях в Azure Cost Management для постоянной оптимизации расходов.

Обоснование выбора Azure: Сервисы PaaS (App Service и Azure SQL Database) максимизируют гибкость и снимают задачи по обслуживанию ОС и платформы в рамках модели общей ответственности, обеспечивая эластичность за счет автомасштабирования. Развертывание с избыточностью в зонах и межрегиональная репликация обеспечивают отказоустойчивость в пределах региона и аварийное восстановление между регионами, что соответствует заявленным RPO/RTO. Front Door предоставляет глобальный входящий трафик, маршрутизацию на основе состояния работоспособности и защиту WAF. Начало работы с моделью оплаты по мере использования сохраняет гибкость во время миграции; покупка зарезервированной емкости или Savings Plan для измеренной базовой нагрузки снижает стоимость при постоянном использовании, в то время как автомасштабирование сокращает расходы в периоды низкой нагрузки. Microsoft Entra ID централизует управление удостоверениями и доступом, а Azure Monitor вместе с Cost Management обеспечивает операционную и финансовую прозрачность.

Все домены · Архитектура и глобальная инфраструктура Azure →

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

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