Стратегии мультиоблачной среды с Azure

Мультиоблачный подход означает работу с рабочими нагрузками в нескольких облачных средах — например, использование Azure для большинства служб, AWS для определённой платформы машинного обучения или Google Cloud для аналитики BigQuery. Организации выбирают мультиоблачный подход, чтобы избежать зависимости от поставщика, использовать лучшие в своём классе службы каждого поставщика, выполнять договорные или нормативные требования и не зависеть от одного поставщика либо потому, что в результате слияний и поглощений объединились компании, стандартизировавшие работу в разных облаках. Сегодня мультиоблачный подход является нормой для крупных предприятий.

Мультиоблачный подход создаёт значительные операционные сложности: Разрастание набора навыков — командам требуется опыт работы с несколькими облачными платформами. Несогласованное управление — в каждом облаке используются разные средства IAM, управления политиками и обеспечения соответствия требованиям. Сложность обеспечения безопасности — разные модели угроз, службы безопасности и журналы аудита. Управление затратами — отдельные порталы выставления счетов, разные единицы тарификации и отсутствие единого представления о затратах по всем поставщикам. Сложность сети — межоблачный трафик приводит к расходам на исходящий трафик и задержкам. Microsoft решает многие из этих проблем с помощью Azure Arc и поддержки нескольких облаков в Defender for Cloud.

Тот же агент подключённой машины Azure Arc, который используется для подключения локальных серверов, работает и на виртуальных машинах в AWS EC2, Google Cloud Compute Engine и любом другом облаке. После регистрации в Arc эти виртуальные машины отображаются рядом с собственными ресурсами Azure на портале ARM. Вы можете применять Azure Policy, использовать Azure Monitor с теми же запросами KQL и просматривать рекомендации по безопасности Defender for Cloud для виртуальных машин AWS и GCP — не покидая портала Azure и не изучая специальные инструменты AWS.

Microsoft Defender for Cloud поддерживает встроенные соединители для AWS и Google Cloud Platform. Подключив учётную запись AWS или проект GCP, Defender for Cloud может оценивать состояние безопасности экземпляров EC2, контейнеров S3, баз данных RDS и ресурсов GCP с помощью той же системы Secure Score, которая используется для Azure. Система сопоставляет результаты с такими стандартами, как CIS AWS Foundations Benchmark, и обнаруживает неправильные настройки (например, общедоступные контейнеры S3 и чрезмерно разрешающие роли IAM), отображая их вместе с рекомендациями для Azure на одной панели.

Azure Cost Management + Billing может получать данные о затратах AWS, если подключить AWS Cost and Usage Report (CUR) к Azure Connector. Это позволяет просматривать расходы AWS вместе с расходами Azure в едином представлении анализа затрат, сравнивать затраты между облаками и распределять их. Вы можете создавать бюджеты и оповещения, охватывающие обоих поставщиков, а также применять единую стратегию тегирования для распределения затрат и отчётности о них. Такая видимость затрат в нескольких облаках особенно ценна для команд FinOps, которые управляют расходами нескольких поставщиков из единого интерфейса.

Во многих стратегиях работы с несколькими облаками Kubernetes используется как уровень абстракции, одинаково работающий в любом облаке. AKS в Azure, EKS в AWS и GKE в GCP работают на основе стандартного Kubernetes. Kubernetes с поддержкой Azure Arc позволяет управлять всеми этими средами из Azure, единообразно применяя развёртывания на основе GitOps и Azure Policy (OPA Gatekeeper). Образы контейнеров, хранящиеся в Azure Container Registry, можно извлекать из кластера Kubernetes любого облака, поэтому Azure ACR естественным образом становится центральным реестром образов для нескольких облаков.

Целевая зона Azure — это предварительно настроенная среда, в которой реализованы лучшие практики управления, удостоверений, безопасности и сетевого взаимодействия. При переходе к мультиоблачной архитектуре организации расширяют концепцию целевой зоны, определяя стандарты, применимые ко всем поставщикам. Microsoft Cloud Adoption Framework (CAF) содержит рекомендации для нескольких облаков по построению иерархий групп управления, соглашений об именовании и стратегий тегирования, которые работают одинаково независимо от того, находится ли ресурс в Azure, AWS или локальной среде.

Для подключения рабочих нагрузок Azure и AWS (или GCP) требуется межоблачная сеть. Распространённые схемы: туннели VPN между Azure VPN Gateway и AWS Virtual Private Gateway или GCP VPN — простой вариант, но с ограниченной пропускной способностью и непредсказуемыми задержками. Сторонний SD-WAN (например, Megaport или Equinix Fabric) — создаёт частные межоблачные каналы, аналогичные ExpressRoute. Интеграция на уровне приложений — службы взаимодействуют по HTTPS через общедоступные конечные точки (самый простой вариант, использующий Интернет). В AWS и GCP передача больших объёмов данных между облаками обходится дорого из-за платы за исходящий трафик.

Microsoft Entra ID может выступать поставщиком удостоверений (IdP) для доступа к нескольким облакам. Для AWS можно настроить Entra ID как поставщика удостоверений SAML 2.0 для AWS IAM Identity Center, чтобы пользователи входили в консоль AWS с учётными данными Entra ID и MFA, без создания отдельных пользователей AWS IAM. Для GCP также возможна аналогичная федерация. Это централизует управление удостоверениями: добавление, перевод и удаление пользователей выполняются в Entra ID, а доступ автоматически распространяется на всех облачных поставщиков.

Практики FinOps (управления финансами в облаке) становятся сложнее при работе с несколькими облаками, поскольку у каждого поставщика свои модели ценообразования, механизмы скидок и детализация счетов. Рекомендуется стандартизировать тегирование у всех поставщиков для распределения затрат; использовать соединитель AWS в Azure Cost Management + Billing для единого представления; создать команду FinOps, разбирающуюся в Reserved Instances (Azure), Savings Plans (AWS/Azure) и Committed Use Discounts (GCP); а также регулярно проводить сравнительный анализ затрат у разных поставщиков для эквивалентных рабочих нагрузок.

Мультиоблачный подход может создавать проблемы без тщательного управления. Распространённые ошибочные шаблоны, которых следует избегать: Случайное использование нескольких облаков — работа с несколькими облаками без стратегии приводит к неконтролируемому разрастанию инфраструктуры и росту затрат. Чрезмерная нагрузка на специалистов — требование от всех инженеров быть экспертами во всех облаках; вместо этого назначайте ответственных за каждую облачную платформу. Несогласованная безопасность — применение разных базовых требований безопасности в каждом облаке; используйте Azure Arc и Defender for Cloud для обеспечения единообразия. Игнорирование затрат на исходящий трафик — передача данных между облаками оплачивается по тарифам поставщиков на исходящий трафик и может стать неожиданностью для команд FinOps.

В этом уроке Вы узнали, что Azure Arc расширяет управление Azure на виртуальные машины AWS и GCP с помощью того же агента подключённой машины, соединители Microsoft Defender for Cloud для нескольких облаков объединяют результаты проверки безопасности разных поставщиков в единой системе Secure Score, а федерация Microsoft Entra ID обеспечивает единый вход в консоли AWS и GCP с использованием одного корпоративного удостоверения. На этом завершается курс по Azure Hybrid и нескольким облакам. Далее Вы познакомитесь с Well-Architected Framework, который помогает оценивать и улучшать архитектуры Azure.