Рекомендации по Azure Front Door

В этой статье представлены лучшие практики по настройке и использованию Azure Front Door.

Общие рекомендации

Общие сведения о том, когда следует объединить диспетчер трафика и Azure Front Door

Для большинства решений используйте либо Azure Front Door, либоДиспетчер трафика Azure, но не оба. Диспетчер трафика — это подсистема балансировки нагрузки на основе DNS. Он отправляет трафик непосредственно на конечные точки вашего источника. В отличие от этого, Azure Front Door завершает подключения в точках присутствия (PoP) рядом с клиентом и устанавливает отдельные долгосрочные подключения к источникам. Продукты работают по-разному и предназначены для разных сценариев использования.

Если вам требуется кэширование содержимого и доставка, завершение TLS, расширенные возможности маршрутизации или брандмауэр веб-приложения (WAF), рассмотрите возможность использования Azure Front Door. Для простой глобальной балансировки нагрузки с прямыми подключениями от клиента к конечным точкам рассмотрите возможность использования диспетчера трафика. Дополнительные сведения о выборе параметра балансировки нагрузки см. в разделе Параметры балансировки нагрузки.

В рамках сложной архитектуры, требующей высокой доступности, вы можете поместить диспетчер трафика перед Azure Front Door. В маловероятном случае недоступности Azure Front Door диспетчер трафика может перенаправить трафик в альтернативное место назначения, например шлюз приложений Azure или сеть доставки содержимого партнера (CDN).

Это важно

Не размещайте Traffic Manager за сервисом Azure Front Door. Диспетчер трафика всегда должен находиться перед Azure Front Door.

Ограничьте трафик на свои серверы-источники

Функции Azure Front Door лучше всего работают, если трафик проходит только через Azure Front Door. Необходимо настроить источник для блокировки трафика, который не отправляется через Azure Front Door. Дополнительные сведения см. в разделе Безопасный трафик к источникам Azure Front Door.

Используйте последнюю версию API и версию SDK

Когда вы работаете с Azure Front Door, используя API, шаблоны Azure Resource Manager, Bicep или Azure SDKs, используйте последнюю доступную версию API или SDK. Обновления API и пакета SDK происходят, когда доступны новые функциональные возможности, и они содержат важные исправления безопасности и исправления ошибок.

Настройка журналов

Azure Front Door отслеживает обширные данные о производительности для каждого запроса. При включении кэширования серверы-источники могут не получать каждый запрос. Используйте логи Azure Front Door, чтобы понять, как работает ваше решение и как реагирует на клиентов. Дополнительные сведения о метриках и журналах, которые записывает Azure Front Door, см. в Мониторинг метрик и журналов в Azure Front Door и логах WAF.

Сведения о настройке ведения журнала для собственного приложения см. в статье "Настройка журналов Azure Front Door".

Рекомендации по TLS

Используйте сквозное шифрование TLS

Azure Front Door завершает подключения TCP и TLS от клиентов. Затем он устанавливает новые соединения от каждой точки присутствия (PoP) до источника. Обеспечьте безопасность каждого из этих соединений с помощью TLS, даже для источников, размещённых в Azure. Этот подход обеспечивает шифрование данных во время передачи.

Дополнительные сведения см. в статье Комплексный протокол TLS с Azure Front Door.

Используйте перенаправление HTTP-to-HTTPS

Клиенты должны использовать HTTPS для подключения к вашему сервису. Однако иногда необходимо принимать HTTP-запросы, чтобы поддерживать старых клиентов или клиентов, которые могут не следовать лучшим практикам.

Azure Front Door можно настроить для автоматического перенаправления HTTP-запросов на использование протокола HTTPS. Включите перенаправление всего трафика на HTTPS на вашем маршруте.

Используйте управляемые сертификаты TLS

Когда Azure Front Door управляет сертификатами TLS, это снижает эксплуатационные затраты и помогает избежать дорогостоящих сбоев, вызванных забыв продлить сертификат. Azure Front Door автоматически выдает и вращает управляемые TLS-сертификаты для большинства пользовательских доменов.

Для доменов apex автоматическая ротация сертификата требует повторной проверки владения доменом. Когда домен входит в состояние ожидающей перепроверки , воссоздайте токен DNS TXT и обновите запись TXT. Для получения дополнительной информации см. ротация управляемых сертификатов TLS в Azure Front Door. Чтобы узнать о настройке HTTPS, смотрите раздел «Configure HTTPS» на пользовательском домене Azure Front Door.

Использование последней версии для сертификатов, управляемых клиентом

Если вы решите использовать собственные сертификаты TLS, попробуйте задать версию сертификата Azure Key Vault в последней версии. Используя последнюю версию, вы не можете перенастроить Azure Front Door, чтобы использовать новые версии сертификата и ожидать развертывания сертификата в средах Azure Front Door.

Дополнительные сведения см. в статье Выбор сертификата для развертывания Azure Front Door.

Передовые методы в области домена

Внедрение личных доменов

Применяйте пользовательские домены для конечных точек Azure Front Door, чтобы обеспечить лучшую доступность и гибкость при управлении доменами и трафиком. Не закодируйте домены, предоставляемые Azure Front Door (например *.azurefd.z01.net), в клиентах, базах кода или брандмауэре. Для таких сценариев используйте личные домены.

Используйте то же доменное имя в Azure Front Door и источнике.

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

Однако при переписывании Host заголовка запросы cookie и перенаправления URL могут нарушиться. В частности, при использовании таких платформ, как служба приложений Azure, такие функции, как сходство сеансов , проверка подлинности и авторизация , могут работать неправильно.

Перед перезаписи Host заголовка запросов тщательно рассмотрите, будет ли приложение работать правильно. Дополнительные сведения см. в статье Сохранение исходного имени узла HTTP между обратным прокси-сервером и его серверным веб-приложением.

Лучшие практики WAF

Для приложений, выходящих в интернет, включите Azure Front Door WAF. В Azure Front Door Premium настройте WAF так, чтобы использовать правила Microsoft для защиты вашего приложения от широкого спектра атак. Для доступности функций WAF по конкретным уровням см. раздел «Сравните уровни Azure Front Door». Дополнительные сведения см. в статье Брандмауэр веб-приложения (WAF) в Azure Front Door.

WAF для Azure Front Door имеет собственный набор рекомендаций по настройке и использованию. Дополнительные сведения см. в рекомендациях по брандмауэру веб-приложений в Azure Front Door.

Рекомендации по пробам работоспособности

Отключите пробы работоспособности при наличии только одного источника в группе источников

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

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

Для получения дополнительной информации см. Зонды работоспособности.

Выбор хороших конечных точек

Рассмотрим расположение, в котором требуется проба работоспособности Azure Front Door для мониторинга. Как правило, рекомендуется отслеживать веб-страницу или место, которые вы специально разрабатываете для мониторинга состояния здоровья. Логика приложения может рассмотреть состояние всех критически важных компонентов, необходимых для обслуживания рабочего трафика, включая серверы приложений, базы данных и кэши. Таким образом, если какой-либо компонент выходит из строя, Azure Front Door может направлять трафик в другой экземпляр службы.

См. дополнительные сведения о шаблоне мониторинга состояния конечных точек.

Используйте пробы работоспособности HEAD

Проверки работоспособности могут использовать метод HTTP GET или HEAD. Рекомендуется использовать HEAD метод для проб работоспособности, так как это снижает нагрузку на трафик в источниках.

Дополнительные сведения см. в разделе Поддерживаемые методы HTTP для проб работоспособности.

Следующий шаг