Корпоративное развертывание с высоким уровнем доступности, использующее среду службы приложений

Microsoft Entra ID

Шлюз приложений Azure

Брандмауэр Azure

Виртуальная сеть Azure

Служба приложений Azure

Замечание

Среда службы приложений версии 3 является основным компонентом этой архитектуры. Версии 1 и 2 были прекращены 31 августа 2024 года.

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

Службы Azure, поддерживающие зоны доступности, могут быть зональными, избыточными по зонам или обоими. Вы можете развертывать зональные службы в определенной зоне и автоматически развертывать службы, избыточные между зонами. Дополнительные сведения см. в разделе "Поддержка зоны доступности". Среда службы приложений поддерживает развертывания, избыточные между зонами.

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

Architecture

На схеме представлен структурированный макет сетевой архитектуры Microsoft Azure, заключенной в синюю границу, помеченную виртуальной сетью. Значок, представляющий Интернет, находится за пределами виртуальной сети. Он подключается к шлюзу приложений, который находится в собственной подсети. Этот шлюз указывает на центральную подсеть, содержащую внутреннюю подсистему балансировки нагрузки, избыточной между зонами. В этой подсети три компонента с накоплением помечены веб-приложением, частным API и функцией. Среда веб-приложения указывает на три подсети. Одна подсеть содержит управляемый Azure Redis. Другая подсеть содержит брандмауэр со стрелкой, направленной наружу, и подписью "исходящий трафик". Третья подсеть включает несколько частных конечных точек, подключенных к значкам, представляющим Azure Управляемый Redis, Azure Service Bus, Azure Cosmos DB, Azure SQL Database и Azure Key Vault, находящихся за пределами виртуальной сети. Зоны частной системы доменных имен (DNS) за пределами подсети подключаются к частным конечным точкам. Виртуальная машина находится в собственной подсети, подключенной через дефишированные линии как к центральной подсети, так и к значку, помеченному GitHub Actions, который расположен в нижней части схемы за пределами виртуальной сети. В правом углу значок, помеченный идентификатором Microsoft Entra, стоит отдельно.

Скачайте файл Visio для этой архитектуры.

Эталонная реализация этой архитектуры доступна на сайте GitHub.

Ресурсы в подсетях среды службы приложений в этой эталонной реализации соответствуют ресурсам в стандартной архитектуре развертывания среды службы приложений. Эта эталонная реализация использует возможности зональной избыточности Среды приложений версии 3 и Управляемый Redis в Azure для обеспечения более высокой доступности. Область этой эталонной архитектуры ограничена одним регионом.

Components

• Среда службы приложений версии 3 — это изолированное, высокопроизводительное решение для размещения, поддерживающее зональную избыточность. В регионах, поддерживающих избыточность зоны, можно настроить избыточность зоны в любой момент во время жизненного цикла среды службы приложений. Каждый план службы приложений в среде службы приложений, избыточной между зонами, должен включать по крайней мере два экземпляра, чтобы обеспечить развертывание в двух или более зонах. Вы можете объединить избыточные между зонами планы и неизбыточные между зонами в одной среде службы приложений. Чтобы настроить план, имеющий только один экземпляр, сначала отключите избыточность зоны для этого плана. Избыточность зоны не взимает дополнительные расходы. Вы оплачиваете только используемые изолированные экземпляры версии 2. Дополнительные сведения см. в разделе "Цены на среду службы приложений " и "Надежность" в среде службы приложений. В этой архитектуре среда службы приложений версии 3 предоставляет изолированную, высокопроизводительную платформу размещения для веб-приложений, API и функций.

• Виртуальная сеть Azure — это сеть на основе IP-адресов уровня 3, которая охватывает все зоны доступности в одном регионе. Подсети в виртуальной сети также расширяются между зонами доступности. Дополнительные сведения см. в разделе "Требования к сети" для среды службы приложений и надежности в виртуальной сети. В этой архитектуре виртуальная сеть обеспечивает безопасную изолированную сеть для всех ресурсов.

• Шлюз приложений Azure версии 2 — это подсистема балансировки нагрузки веб-трафика на основе облака, которая поддерживает избыточность зоны. В этой архитектуре она охватывает несколько зон доступности в каждом регионе. В результате один шлюз приложений обеспечивает высокий уровень доступности, как показано в эталонной архитектуре. Эталонная архитектура использует SKU брандмауэра веб-приложений шлюза приложений, который обеспечивает повышенную защиту от распространенных угроз и уязвимостей. Эта защита основана на реализации основного набора правил (CRS) проекта Open Web Application Security (OWASP). Дополнительные сведения см. в разделе "Надежность" в шлюзе приложений версии 2. Шлюз приложений версии 2 служит зонально-избыточным балансировщиком веб-трафика.

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

  При развертывании брандмауэра можно также настроить определенную зону доступности. Дополнительные сведения см. в разделе "Поддержка зоны доступности брандмауэра Azure". Эталонная архитектура не использует эту конфигурацию.

• Идентификатор Microsoft Entra — это высокодоступная, высокоизбыточная глобальная служба, которая охватывает зоны доступности и регионы. Дополнительные сведения см. в разделе "Предварительная доступность идентификатора Microsoft Entra". В этой архитектуре Microsoft Entra ID предоставляет высокодоступные и избыточные службы управления удостоверением и доступом для проверки подлинности и авторизации во всех компонентах.

• GitHub Actions — это платформа автоматизации, которая поддерживает возможности непрерывной интеграции и непрерывного развертывания (CI/CD). В этой архитектуре GitHub Actions создает приложения за пределами виртуальной сети и развертывает их в планах службы приложений, размещенных в среде службы приложений.

Среда службы приложений находится в виртуальной сети, поэтому виртуальная машина служит полем перехода в виртуальной сети для упрощения развертывания. Для повышения безопасности и подключения через протокол удаленного рабочего стола (RDP) и Secure Shell (SSH) рекомендуется использовать Бастион Azure для прыжкового сервера.

• Управляемый Redis Azure — это служба, избыточная по зонам. Кэш, избыточный между зонами, выполняется на виртуальных машинах, развернутых в нескольких зонах доступности. В этой архитектуре Управляемый Redis Azure обеспечивает более высокую устойчивость и доступность.

Соображения

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. вWell-Architected Framework.

Reliability

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Для получения дополнительной информации см. Контрольный список проверки конструкции на надежность.

Инсталляционные сервера

Эта эталонная реализация использует тот же конвейер CI/CD уровня рабочей среды, что и стандартное развертывание, с одной виртуальной машиной прыжка. Но вы можете использовать один ящик прыжка для каждой из трех зон. Эта архитектура использует только один jump-сервер, так как jump-сервер не влияет на доступность приложения. Окно перехода поддерживает развертывание и тестирование.

Среда службы приложений

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

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

• Зоны доступности можно настроить при создании среды службы приложений или в любой момент жизненного цикла среды.

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

• Только подмножество регионов поддерживает зоны доступности.

Дополнительные сведения см. в разделе "Надежность" в службе приложений.

Resiliency

Приложения, которые выполняются в среде службы приложений, формируют внутренний пул для шлюза приложений. Когда запрос к приложению поступает из общедоступного Интернета, шлюз перенаправит запрос в приложение, которое выполняется в среде службы приложений. Эта эталонная архитектура реализует проверки работоспособности в главном веб-интерфейсе, известном как votingApp. Эта проба работоспособности проверяет состояние работоспособности веб-API и кэша Redis.

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Если какие-либо компоненты, включая веб-интерфейс, API или кэш, завершится сбой пробы работоспособности, шлюз приложений направляет запрос другому приложению в серверном пуле. Эта конфигурация гарантирует, что запрос всегда направляется в приложение в полностью доступную подсеть среды службы приложений.

Стандартная эталонная реализация также использует пробу работоспособности. В этой реализации шлюз возвращает ошибку, если проба работоспособности завершается ошибкой. Но высокодоступная реализация повышает устойчивость приложения и качество взаимодействия с пользователем.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

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

Следующие различия могут повлиять на стоимость:

• Поддержка зоны доступности не взимает дополнительные расходы. Вы оплачиваете только те экземпляры, которые вы используете. Дополнительные сведения см. в Среда службы приложений ценах.

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

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

Развертывание этого сценария

Сведения о развертывании эталонной реализации для этой архитектуры см. в GitHub readme. Используйте сценарий для развертывания с высоким уровнем доступности.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Deep Bhattacharya | Архитектор облачных решений
• Сухас Рао | Архитектор облачных решений

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

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

• Дополнительные сведения о горизонтальном масштабировании см. в разделе "Геораспределяемый масштаб с помощью среды службы приложений".
• Для глобального и высокодоступного решения маршрутизации рекомендуется использовать Azure Front Door.

Замечание

Среда службы приложений версии 3 является основным компонентом этой архитектуры. Версии 1 и 2 были прекращены 31 августа 2024 года.

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

Службы Azure, поддерживающие зоны доступности, могут быть зональными, избыточными по зонам или обоими. Вы можете развертывать зональные службы в определенной зоне и автоматически развертывать службы, избыточные между зонами. Дополнительные сведения см. в разделе "Поддержка зоны доступности". Среда службы приложений поддерживает развертывания, избыточные между зонами.

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

Architecture

На схеме представлен структурированный макет сетевой архитектуры Microsoft Azure, заключенной в синюю границу, помеченную виртуальной сетью. Значок, представляющий Интернет, находится за пределами виртуальной сети. Он подключается к шлюзу приложений, который находится в собственной подсети. Этот шлюз указывает на центральную подсеть, содержащую внутреннюю подсистему балансировки нагрузки, избыточной между зонами. В этой подсети три компонента с накоплением помечены веб-приложением, частным API и функцией. Среда веб-приложения указывает на три подсети. Одна подсеть содержит управляемый Azure Redis. Другая подсеть содержит брандмауэр со стрелкой, направленной наружу, и подписью "исходящий трафик". Третья подсеть включает несколько частных конечных точек, подключенных к значкам, представляющим Azure Управляемый Redis, Azure Service Bus, Azure Cosmos DB, Azure SQL Database и Azure Key Vault, находящихся за пределами виртуальной сети. Зоны частной системы доменных имен (DNS) за пределами подсети подключаются к частным конечным точкам. Виртуальная машина находится в собственной подсети, подключенной через дефишированные линии как к центральной подсети, так и к значку, помеченному GitHub Actions, который расположен в нижней части схемы за пределами виртуальной сети. В правом углу значок, помеченный идентификатором Microsoft Entra, стоит отдельно.

Скачайте файл Visio для этой архитектуры.

Эталонная реализация этой архитектуры доступна на сайте GitHub.

Ресурсы в подсетях среды службы приложений в этой эталонной реализации соответствуют ресурсам в стандартной архитектуре развертывания среды службы приложений. Эта эталонная реализация использует возможности зональной избыточности Среды приложений версии 3 и Управляемый Redis в Azure для обеспечения более высокой доступности. Область этой эталонной архитектуры ограничена одним регионом.

Components

• Среда службы приложений версии 3 — это изолированное, высокопроизводительное решение для размещения, поддерживающее зональную избыточность. В регионах, поддерживающих избыточность зоны, можно настроить избыточность зоны в любой момент во время жизненного цикла среды службы приложений. Каждый план службы приложений в среде службы приложений, избыточной между зонами, должен включать по крайней мере два экземпляра, чтобы обеспечить развертывание в двух или более зонах. Вы можете объединить избыточные между зонами планы и неизбыточные между зонами в одной среде службы приложений. Чтобы настроить план, имеющий только один экземпляр, сначала отключите избыточность зоны для этого плана. Избыточность зоны не взимает дополнительные расходы. Вы оплачиваете только используемые изолированные экземпляры версии 2. Дополнительные сведения см. в разделе "Цены на среду службы приложений " и "Надежность" в среде службы приложений. В этой архитектуре среда службы приложений версии 3 предоставляет изолированную, высокопроизводительную платформу размещения для веб-приложений, API и функций.

• Виртуальная сеть Azure — это сеть на основе IP-адресов уровня 3, которая охватывает все зоны доступности в одном регионе. Подсети в виртуальной сети также расширяются между зонами доступности. Дополнительные сведения см. в разделе "Требования к сети" для среды службы приложений и надежности в виртуальной сети. В этой архитектуре виртуальная сеть обеспечивает безопасную изолированную сеть для всех ресурсов.

• Шлюз приложений Azure версии 2 — это подсистема балансировки нагрузки веб-трафика на основе облака, которая поддерживает избыточность зоны. В этой архитектуре она охватывает несколько зон доступности в каждом регионе. В результате один шлюз приложений обеспечивает высокий уровень доступности, как показано в эталонной архитектуре. Эталонная архитектура использует SKU брандмауэра веб-приложений шлюза приложений, который обеспечивает повышенную защиту от распространенных угроз и уязвимостей. Эта защита основана на реализации основного набора правил (CRS) проекта Open Web Application Security (OWASP). Дополнительные сведения см. в разделе "Надежность" в шлюзе приложений версии 2. Шлюз приложений версии 2 служит зонально-избыточным балансировщиком веб-трафика.

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

  При развертывании брандмауэра можно также настроить определенную зону доступности. Дополнительные сведения см. в разделе "Поддержка зоны доступности брандмауэра Azure". Эталонная архитектура не использует эту конфигурацию.

• Идентификатор Microsoft Entra — это высокодоступная, высокоизбыточная глобальная служба, которая охватывает зоны доступности и регионы. Дополнительные сведения см. в разделе "Предварительная доступность идентификатора Microsoft Entra". В этой архитектуре Microsoft Entra ID предоставляет высокодоступные и избыточные службы управления удостоверением и доступом для проверки подлинности и авторизации во всех компонентах.

• GitHub Actions — это платформа автоматизации, которая поддерживает возможности непрерывной интеграции и непрерывного развертывания (CI/CD). В этой архитектуре GitHub Actions создает приложения за пределами виртуальной сети и развертывает их в планах службы приложений, размещенных в среде службы приложений.

Среда службы приложений находится в виртуальной сети, поэтому виртуальная машина служит полем перехода в виртуальной сети для упрощения развертывания. Для повышения безопасности и подключения через протокол удаленного рабочего стола (RDP) и Secure Shell (SSH) рекомендуется использовать Бастион Azure для прыжкового сервера.

• Управляемый Redis Azure — это служба, избыточная по зонам. Кэш, избыточный между зонами, выполняется на виртуальных машинах, развернутых в нескольких зонах доступности. В этой архитектуре Управляемый Redis Azure обеспечивает более высокую устойчивость и доступность.

Соображения

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. вWell-Architected Framework.

Reliability

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Для получения дополнительной информации см. Контрольный список проверки конструкции на надежность.

Инсталляционные сервера

Эта эталонная реализация использует тот же конвейер CI/CD уровня рабочей среды, что и стандартное развертывание, с одной виртуальной машиной прыжка. Но вы можете использовать один ящик прыжка для каждой из трех зон. Эта архитектура использует только один jump-сервер, так как jump-сервер не влияет на доступность приложения. Окно перехода поддерживает развертывание и тестирование.

Среда службы приложений

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

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

• Зоны доступности можно настроить при создании среды службы приложений или в любой момент жизненного цикла среды.

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

• Только подмножество регионов поддерживает зоны доступности.

Дополнительные сведения см. в разделе "Надежность" в службе приложений.

Resiliency

Приложения, которые выполняются в среде службы приложений, формируют внутренний пул для шлюза приложений. Когда запрос к приложению поступает из общедоступного Интернета, шлюз перенаправит запрос в приложение, которое выполняется в среде службы приложений. Эта эталонная архитектура реализует проверки работоспособности в главном веб-интерфейсе, известном как votingApp. Эта проба работоспособности проверяет состояние работоспособности веб-API и кэша Redis.

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Если какие-либо компоненты, включая веб-интерфейс, API или кэш, завершится сбой пробы работоспособности, шлюз приложений направляет запрос другому приложению в серверном пуле. Эта конфигурация гарантирует, что запрос всегда направляется в приложение в полностью доступную подсеть среды службы приложений.

Стандартная эталонная реализация также использует пробу работоспособности. В этой реализации шлюз возвращает ошибку, если проба работоспособности завершается ошибкой. Но высокодоступная реализация повышает устойчивость приложения и качество взаимодействия с пользователем.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

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

Следующие различия могут повлиять на стоимость:

• Поддержка зоны доступности не взимает дополнительные расходы. Вы оплачиваете только те экземпляры, которые вы используете. Дополнительные сведения см. в Среда службы приложений ценах.

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

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

Развертывание этого сценария

Сведения о развертывании эталонной реализации для этой архитектуры см. в GitHub readme. Используйте сценарий для развертывания с высоким уровнем доступности.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Deep Bhattacharya | Архитектор облачных решений
• Сухас Рао | Архитектор облачных решений

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

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

• Дополнительные сведения о горизонтальном масштабировании см. в разделе "Геораспределяемый масштаб с помощью среды службы приложений".
• Для глобального и высокодоступного решения маршрутизации рекомендуется использовать Azure Front Door.