Справочник

Переход от крупных первоначальных затрат на аппаратное обеспечение к модели оплаты по мере использования.

→Используйте облачную модель на основе потребления.

Почему: Это превращает капитальные затраты (CapEx) в предсказуемые операционные расходы (OpEx), устраняя необходимость в приобретении и управлении центрами обработки данных.

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

→Поставщик отвечает за безопасность *облака*; клиент отвечает за безопасность *в* облаке. Клиент всегда владеет своими данными, идентификаторами и конечными точками.

Почему: В IaaS клиент управляет ОС и выше. В PaaS поставщик управляет ОС, а клиент управляет приложением и данными. В SaaS поставщик управляет всем, кроме данных и конфигурации доступа.

Источник↗

Выберите модель развертывания на основе требований к контролю, владению и расположению.

→Используйте публичное (общая инфраструктура), частное (выделенная инфраструктура, локально или размещенная) или гибридное (смесь публичного и частного) облако.

Почему: Гибридное облако является ключевым для сохранения локальных систем в целях регулирования/задержки, при этом используя публичное облако для масштабируемости и современных сервисов. Частное облако предлагает максимальный контроль.

Выберите подходящую модель облачного сервиса на основе желаемого уровня контроля управления.

→IaaS (например, Azure VMs) для максимального контроля над ОС. PaaS (например, Azure App Service, Azure SQL) для сосредоточения на коде, а не на инфраструктуре. SaaS (например, Microsoft 365) для готового к использованию программного обеспечения.

Почему: Компромисс между контролем и удобством. При переходе от IaaS к SaaS поставщик управляет большей частью стека, снижая операционную нагрузку на клиента.

Обработка динамических, непредсказуемых всплесков трафика против запланированного, устойчивого роста.

→Используйте Elasticity для автоматического масштабирования (увеличение/уменьшение) в соответствии с текущим спросом. Используйте Scalability для запланированного увеличения мощности (горизонтальное/вертикальное) для обработки прогнозируемого роста.

Почему: Elasticity автоматизирована и реактивна, идеальна для пиковых нагрузок для оптимизации затрат. Scalability — это более широкое понятие добавления мощности, которое может быть ручным или автоматизированным.

Защита от сбоя компонента в пределах региона против катастрофического сбоя региона.

→Внедрите высокую доступность (HA) с использованием Availability Zones для переживания сбоев центра обработки данных. Внедрите аварийное восстановление (DR) с использованием межрегиональной репликации (например, GRS) для переживания региональной катастрофы.

Почему: HA — это поддержание сервиса с минимальными перебоями. DR — это восстановление сервиса после крупного сбоя. HA обычно автоматизирована с быстрым переключением на резерв; DR часто включает формальный процесс восстановления.

Развертывание ресурсов для государственного учреждения, требующего соблюдения конкретных нормативов и расположения данных.

→Используйте суверенное облако, такое как Azure Government.

Почему: Это физически изолированные экземпляры Azure, управляемые проверенным персоналом и разработанные для соответствия строгим государственным стандартам (например, FedRAMP, DoD).

Разработайте отказоустойчивое приложение, способное выдержать сбой центра обработки данных.

→Разверните ресурсы в нескольких Availability Zones в пределах одного региона Azure.

Почему: Availability Zones — это физически отдельные центры обработки данных с независимым электропитанием, охлаждением и сетевым оборудованием. Это обеспечивает высокую доступность в пределах региона без задержек межрегиональных развертываний.

Источник↗

Группировка связанных ресурсов Azure для унифицированного управления, контроля доступа и выставления счетов.

→Разместите все ресурсы для приложения в одной группе ресурсов Azure.

Почему: Группы ресурсов — это контейнеры для метаданных. Удаление группы ресурсов удаляет все ресурсы внутри нее, что делает ее критически важной границей управления жизненным циклом.

Выберите подходящий вычислительный сервис для рабочей нагрузки.

→VMs (IaaS) для полного контроля. App Service (PaaS) для веб-приложений/API. Azure Functions для бессерверного кода, управляемого событиями. AKS для оркестрации контейнеров. ACI для простых экземпляров контейнеров.

Почему: Выбор зависит от компромисса между контролем, накладными расходами на управление и архитектурным шаблоном (например, монолит, микросервисы, управляемые событиями).

Запустите сложное, контейнеризированное приложение микросервисов, требующее автомасштабирования, обнаружения сервисов и скользящих обновлений.

→Используйте Azure Kubernetes Service (AKS).

Почему: AKS — это управляемое предложение Kubernetes для полномасштабной оркестрации контейнеров. Используйте его вместо ACI, когда вам требуется управление кластером и сложные взаимодействия сервисов.

Запустите один простой контейнер для кратковременной задачи (например, пакетного задания) без управления инфраструктурой.

→Используйте Azure Container Instances (ACI).

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

Установите выделенное, частное, высокоскоростное соединение из локального центра обработки данных в Azure.

→Используйте Azure ExpressRoute.

Почему: ExpressRoute НЕ проходит через общедоступный интернет, предлагая большую надежность, безопасность и меньшую задержку, чем VPN Gateway, который туннелирует через интернет.

Источник↗

Распределение трафика на серверные VM на основе правил сетевого уровня против правил уровня приложения.

→Используйте Azure Load Balancer для распределения на уровне 4 (TCP/UDP). Используйте Azure Application Gateway для функций уровня 7 (HTTP/HTTPS), таких как разгрузка SSL и маршрутизация на основе URL.

Почему: Выбирайте Application Gateway, когда вам нужно принимать решения о маршрутизации на основе заголовков HTTP, путей или имен хостов. Load Balancer проще и быстрее для трафика, отличного от HTTP.

Маршрутизация глобального веб-трафика на оптимальный бэкэнд, предоставление CDN-кеширования и защита с помощью WAF.

→Используйте Azure Front Door.

Почему: Front Door — это глобальная точка входа, которая работает на уровне 7 и объединяет глобальную балансировку нагрузки, CDN, WAF и защиту от DDoS в одном сервисе.

Храните огромные объемы неструктурированных данных, таких как изображения, видео, резервные копии и файлы журналов.

→Используйте Azure Blob Storage.

Почему: Blob Storage высоко масштабируем и экономичен для объектных данных. Он отличается от Azure Files (для общих файловых ресурсов SMB) и Azure Disk Storage (для дисков VM).

Минимизируйте затраты на хранение данных в зависимости от частоты доступа.

→Используйте уровни доступа Blob Storage: Hot (частый доступ), Cool/Cold (нечастый доступ) и Archive (редкий доступ, долгосрочное хранение).

Почему: Уровень Archive имеет самую низкую стоимость хранения, но самую высокую стоимость доступа и задержку (часы на восстановление). Используйте политики управления жизненным циклом для автоматизации изменения уровней.

Выберите стратегию репликации данных для защиты от сбоев оборудования, центра обработки данных или региона.

→LRS (один центр обработки данных), ZRS (поперек Availability Zones в одном регионе), GRS (во вторичный регион), GZRS (ZRS в основном + LRS во вторичном).

Почему: ZRS защищает от сбоя центра обработки данных. GRS/GZRS защищает от региональной катастрофы. Компромисс — более высокая стоимость за большую отказоустойчивость.

Разрешите виртуальной машине в VNet доступ к PaaS-сервису (например, Azure SQL или Storage) без выхода трафика за пределы сети Microsoft.

→Создайте Private Endpoint для PaaS-сервиса в VNet виртуальной машины.

Почему: Private Endpoint предоставляет PaaS-сервису частный IP-адрес из вашей VNet, обеспечивая прохождение всего трафика через частную магистраль Microsoft, а не через общедоступный интернет.

Мигрируйте локальный файловый сервер Windows в управляемый облачный сервис, доступный по протоколу SMB.

→Используйте Azure Files.

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

Применяйте управление (политики, RBAC) и управляйте доступом к многочисленным подпискам Azure.

→Организуйте подписки в иерархию Management Group.

Почему: Management Groups — это область выше подписок. Политики и назначения ролей, применяемые на уровне Management Group, наследуются всеми подписками внутри нее.

Источник↗

Применяйте организационные стандарты, такие как ограничение развертываний определенными регионами или требование тегов для всех ресурсов.

→Используйте Azure Policy.

Почему: Policy применяет правила к конфигурациям ресурсов. Это для управления, тогда как RBAC контролирует разрешения пользователей (действия).

Разграничьте управление действиями пользователей и управление свойствами ресурсов.

→Используйте Role-Based Access Control (RBAC) для определения того, какие действия пользователь может выполнять (например, "Contributor" может создавать VM). Используйте Azure Policy для определения того, какие конфигурации разрешены (например, "VM могут быть только размера D-серии").

Почему: RBAC — это о том, "кто что может делать". Policy — это о том, "что разрешено". Они работают вместе для всестороннего управления.

Защитите критически важный производственный ресурс от случайного удаления, даже администраторами.

→Примените Resource Lock типа `CanNotDelete` к ресурсу или его группе ресурсов.

Почему: Resource Locks переопределяют разрешения RBAC. Владелец не может удалить заблокированный ресурс, пока блокировка не будет явно снята. Блокировка `ReadOnly` предотвращает любые изменения.

Логически организуйте ресурсы для отслеживания затрат, автоматизации или идентификации владельца.

→Примените Теги (пары ключ-значение) к ресурсам.

Почему: Теги — это метаданные, используемые для фильтрации и группировки ресурсов по группам ресурсов, что обеспечивает мощный анализ затрат и управление.

Тег, примененный к группе ресурсов, не отображается на ресурсах внутри нее.

→Теги не наследуются автоматически от групп ресурсов. Каждый ресурс должен быть помечен явно.

Почему: Для принудительного наследования тегов используйте Azure Policy с эффектом "Modify" или "DeployIfNotExists" для добавления тегов из родительской группы ресурсов.

Оценить будущие затраты Azure против расчета экономии от миграции из локальной среды.

→Используйте Pricing Calculator для оценки стоимости конкретных сервисов Azure. Используйте Total Cost of Ownership (TCO) Calculator для сравнения локальных затрат с затратами Azure.

Почему: Pricing Calculator предназначен для новых развертываний или добавления новых сервисов. TCO Calculator предназначен для обоснования целесообразности миграции.

Отслеживайте текущие расходы Azure, устанавливайте оповещения о расходах и находите возможности для экономии.

→Используйте Azure Cost Management. Создавайте Бюджеты для запуска оповещений при достижении пороговых значений расходов.

Почему: Бюджеты обеспечивают проактивное уведомление о расходах, помогая предотвратить перерасход средств. Анализ Cost Management помогает выявлять аномалии и тенденции в расходах.

Сократите расходы на предсказуемые, постоянно работающие рабочие нагрузки, такие как VM или базы данных.

→Приобретайте Azure Reserved Instances или Savings Plans на срок 1 или 3 года.

Почему: Резервации предлагают значительные скидки (до 72%) по сравнению с ценами pay-as-you-go в обмен на долгосрочное обязательство. Идеально подходят для стабильных рабочих нагрузок.

Развертывайте инфраструктуру Azure многократно, последовательно и под контролем версий.

→Используйте декларативную инфраструктуру как код (IaC) с ARM Templates (JSON) или Bicep.

Почему: Bicep — это более простой, лаконичный предметно-ориентированный язык (DSL), который транспилируется в ARM JSON, обеспечивая улучшенный опыт разработки и читаемость.

Управляйте серверами, работающими локально или в других облаках, с помощью инструментов Azure.

→Подключите не-Azure серверы к Azure Arc.

Почему: Azure Arc проецирует внешние ресурсы в Azure Resource Manager, позволяя использовать Azure Policy, RBAC и мониторинг для гибридных и мультиоблачных активов из единой плоскости управления.

Источник↗

Предоставьте единое облачное решение для управления идентификацией и доступом для всех приложений.

→Используйте Microsoft Entra ID (ранее Azure AD).

Почему: Entra ID — это плоскость управления идентификацией, предоставляющая единый вход (SSO), многофакторную аутентификацию (MFA) и условный доступ для облачных и локальных приложений.

Требовать MFA для пользователей, входящих в систему из ненадежной сети, но не из корпоративного офиса.

→Настройте политику условного доступа Microsoft Entra.

Почему: Conditional Access действует как механизм политики "если-то". Если условие пользователя/местоположения/устройства выполняется, то применяется контроль доступа (например, требование MFA).

Разрешите ресурсу Azure (например, VM или App Service) аутентифицироваться в другом сервисе Azure (например, Key Vault) без хранения секретов в коде.

→Назначьте Managed Identity ресурсу и предоставьте ему разрешения RBAC на целевой сервис.

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

Надежно храните и управляйте секретами, ключами и сертификатами приложений.

→Используйте Azure Key Vault.

Почему: Key Vault предоставляет централизованное, аппаратно-защищенное и аудируемое хранилище для секретов, предотвращая их жесткое кодирование в приложениях.

Постоянно оценивайте состояние безопасности облачных рабочих нагрузок, получайте Secure Score и защиту от угроз.

→Используйте Microsoft Defender for Cloud.

Почему: Defender for Cloud предоставляет управление состоянием безопасности облака (CSPM) и защиту облачных рабочих нагрузок (CWP) в средах Azure, гибридных и мультиоблачных.

Фильтрация сетевого трафика на уровне подсети/сетевой карты против централизованной фильтрации для всей VNet.

→Используйте Network Security Groups (NSG) для базовой фильтрации пакетов на уровнях 3/4. Используйте Azure Firewall для централизованного, полностью stateful файрвола как сервиса с фильтрацией на уровне 7 и анализом угроз.

Почему: NSG просты и распределены. Azure Firewall предоставляет расширенные возможности и централизованное управление политиками, часто используется в топологии hub-spoke.

Сократите поверхность атаки виртуальных машин, по умолчанию закрывая порты управления (RDP/SSH).

→Включите Just-In-Time (JIT) доступ к виртуальным машинам в Microsoft Defender for Cloud.

Почему: JIT предоставляет временный доступ к портам управления по запросу на ограниченное время, автоматически закрывая их после. Это безопаснее, чем оставлять порты постоянно открытыми.

Мониторинг состояния инфраструктуры Azure против производительности кода приложения.

→Используйте Azure Monitor для метрик и журналов платформы. Используйте Application Insights (функция Azure Monitor) для управления производительностью приложений (APM).

Почему: Azure Monitor собирает данные инфраструктуры (ЦП, память). Application Insights предоставляет глубокую диагностику на уровне кода (время отклика, зависимости, исключения).

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

→Используйте Azure Service Health.

Почему: Service Health персонализирована для ваших подписок, регионов и сервисов, в отличие от общедоступной страницы статуса Azure. Она предназначена для проблем платформы Azure, а не для работоспособности ваших собственных ресурсов.

Получайте персонализированные, действенные рекомендации по оптимизации ресурсов Azure.

→Просмотрите рекомендации Azure Advisor.

Почему: Advisor анализирует вашу конфигурацию и телеметрию использования и предоставляет рекомендации по пяти столпам: надежности, безопасности, производительности, стоимости и операционному совершенству.

Создайте стандартизированную, управляемую и масштабируемую основу для всех рабочих нагрузок Azure на предприятии.

→Внедрите архитектуру Azure Landing Zone.

Почему: Landing Zones предоставляют предписывающую структуру из Cloud Adoption Framework, включая структуру групп управления, сеть, идентификацию и политики управления, для безопасного ускорения внедрения облачных технологий.