Utiliser Azure Front Door dans une solution mutualisée

Azure Front Door est un réseau de distribution de contenu cloud moderne (CDN) qui fournit un accès rapide et fiable entre les utilisateurs et le contenu web statique et dynamique des applications dans le monde entier. Cet article décrit certaines des fonctionnalités d’Azure Front Door qui sont utiles lorsque vous travaillez dans des systèmes multilocataire. Il fournit également d’autres conseils et exemples connexes.

Lorsque vous utilisez Azure Front Door dans le cadre d’une solution mutualisée, vous devez prendre certaines décisions en fonction de la conception et des exigences de votre solution. Tenez compte des facteurs suivants :

• Considérez le nombre de locataires que vous avez actuellement et le nombre de locataires que vous prévoyez d’avoir à l’avenir.

• Déterminez si vous partagez votre couche Application entre plusieurs locataires, déployez de nombreuses instances d’application à locataire unique ou déployez des tampons de déploiement distincts que partagent plusieurs locataires.

• Identifiez si vos locataires souhaitent apporter leurs propres noms de domaine.

• Déterminez si vous souhaitez utiliser des domaines génériques.

• Déterminez si vous devez utiliser vos propres certificats TLS (Transport Layer Security) ou si Microsoft gérera vos certificats TLS.

• Prenez en compte les quotas et les limites qui s’appliquent à Azure Front Door. Identifiez les limites que vous pouvez aborder à mesure que votre solution est mise à l’échelle. Si vous prévoyez près de ces limites, envisagez d’utiliser plusieurs profils Azure Front Door ou d’ajuster la façon dont vous utilisez Azure Front Door pour rester dans des contraintes acceptables. La référence SKU Premium a des limites plus élevées que la référence SKU Standard.

• Déterminez si vous ou vos locataires avez des exigences pour le filtrage d’adresses IP, le géoblocage ou la personnalisation des règles de pare-feu d’applications web.

• Vérifiez si tous les serveurs d’applications de vos locataires sont accessibles sur Internet.

Fonctionnalités d’Azure Front Door qui prennent en charge l’architecture mutualisée

Cette section décrit plusieurs fonctionnalités clés d’Azure Front Door qui sont utiles pour les solutions mutualisées. Il décrit comment Azure Front Door peut vous aider à configurer des domaines personnalisés, notamment des informations sur les domaines génériques et les certificats TLS. Il résume également la façon dont vous pouvez utiliser les fonctionnalités de routage Azure Front Door pour soutenir la multitenance.

Domaines personnalisés

Azure Front Door fournit un nom d’hôte par défaut pour chaque point de terminaison que vous créez, tel que contoso.z01.azurefd.net. Toutefois, pour la plupart des solutions, vous associez votre propre nom de domaine au point de terminaison Azure Front Door. Les noms de domaine personnalisés vous permettent d’utiliser votre propre personnalisation et de configurer le routage en fonction du nom d’hôte inclus dans la demande d’un client.

Dans une solution mutualisée, vous pouvez utiliser des noms de domaine ou des sous-domaines spécifiques au locataire et configurer Azure Front Door pour router le trafic du locataire vers le groupe d’origine approprié pour la charge de travail de ce locataire. Par exemple, vous pouvez configurer un nom de domaine personnalisé comme tenant1.app.contoso.com. Vous pouvez configurer plusieurs domaines personnalisés sur un seul profil Azure Front Door.

Pour plus d’informations, consultez Ajouter un domaine personnalisé à Azure Front Door.

Domaines génériques

Les domaines génériques simplifient la configuration des enregistrements DNS (Domain Name System) et du routage du trafic Azure Front Door lorsque vous utilisez un domaine stem partagé et des sous-domaines spécifiques au locataire. Par exemple, supposons que vos locataires accèdent à leurs applications en utilisant des sous-domaines tels que tenant1.app.contoso.com et tenant2.app.contoso.com. Vous pouvez configurer un domaine générique, *.app.contoso.comau lieu de configurer chaque domaine spécifique au locataire individuellement.

Azure Front Door prend en charge la création de domaines personnalisés qui utilisent des caractères génériques. Vous pouvez ensuite configurer un itinéraire pour les requêtes qui arrivent sur le domaine générique. Lorsque vous intégrez un nouveau locataire, vous n’avez pas besoin de reconfigurer vos serveurs DNS, d’émettre de nouveaux certificats TLS ou de mettre à jour la configuration de votre profil Azure Front Door.

Les domaines génériques fonctionnent bien si vous envoyez tout votre trafic à un seul groupe d’origines. Toutefois, si vous avez des empreintes distinctes de votre solution, un domaine générique à un seul niveau n’est pas suffisant. Vous devez utiliser des domaines souches de plusieurs niveaux ou fournir une configuration supplémentaire. Par exemple, vous pouvez remplacer les itinéraires du sous-domaine de chaque locataire. Pour plus d’informations, consultez Considérations relatives à l’utilisation de noms de domaine dans une solution mutualisée.

Azure Front Door n’émet pas de certificats TLS managés pour les domaines génériques. Vous devez donc acheter et fournir votre propre certificat.

Certificats TLS managés

L’acquisition et l’installation de certificats TLS peuvent être un processus complexe et sujet aux erreurs. Les certificats TLS expirent après une période, généralement un an et doivent être réédités et réinstallés pour éviter toute interruption du trafic des applications. Lorsque vous utilisez des certificats TLS gérés par Azure Front Door, Microsoft est responsable de l’émission, de l’installation et du renouvellement de certificats pour votre domaine personnalisé.

Votre application d’origine peut être hébergée sur un autre service Azure qui fournit également des certificats TLS managés, comme Azure App Service. Azure Front Door fonctionne de manière transparente avec l’autre service pour synchroniser vos certificats TLS.

Si vos locataires peuvent fournir leurs propres domaines personnalisés et que vous souhaitez qu’Azure Front Door émette des certificats pour ces noms de domaine, vos locataires ne doivent pas configurer les enregistrements d’autorisation d’autorité de certification (CAA) sur leurs serveurs DNS. Ces enregistrements peuvent empêcher Azure Front Door d’émettre des certificats au nom de vos locataires. Pour plus d’informations sur l’architecture mutualisée, consultez les certificats TLS et SSL dans les solutions mutualisées. Pour plus d’informations sur Azure Front Door, consultez chiffrement TLS avec Azure Front Door.

Routage

Une application multilocataire peut avoir un ou plusieurs tampons d’application qui servent les locataires. Les tampons sont fréquemment utilisés pour activer des déploiements multirégions et prendre en charge la mise à l’échelle d’une solution vers un grand nombre de locataires.

Azure Front Door dispose d’un ensemble puissant de fonctionnalités de routage qui peuvent prendre en charge de nombreuses architectures mutualisées. Vous pouvez utiliser le routage pour distribuer le trafic entre les origines d’un tampon ou pour envoyer le trafic vers le tampon approprié pour un locataire spécifique. Vous pouvez configurer le routage en fonction des noms de domaine individuels, des noms de domaine génériques et des chemins d’URL. Vous pouvez également utiliser le moteur de règles pour personnaliser davantage le comportement de routage.

Pour plus d’informations, consultez Vue d’ensemble de l’architecture de routage.

Moteur de règles

Vous pouvez utiliser le moteur de règles Azure Front Door pour personnaliser la façon dont Azure Front Door traite les demandes à la périphérie du réseau. Le moteur de règles vous permet d’exécuter de petits blocs de logique dans le pipeline de traitement des demandes Azure Front Door. Vous pouvez utiliser le moteur de règles pour différentes tâches qui incluent, mais qui ne sont pas limités à, les éléments de liste suivants :

• Récupérez des informations sur la requête HTTP, y compris les segments de l’URL et le chemin d’accès, puis propagez les informations à une autre partie de la requête.

• Modifiez les éléments de la requête HTTP avant son envoi à l’origine.

• Modifiez les éléments de la réponse HTTP avant qu’elle ne soit retournée au client.

• Remplacez la configuration de routage d’une requête, par exemple en modifiant le groupe d’origine auquel une demande doit être envoyée.

Les exemples d’approches suivants utilisent le moteur de règles Azure Front Door dans une solution mutualisée :

• Supposons que vous déployez un niveau d’application mutualisé dans lequel vous utilisez également des sous-domaines génériques spécifiques au locataire, comme décrit dans les exemples de scénarios suivants. Vous pouvez utiliser le moteur de règles pour extraire l’identificateur de locataire du sous-domaine de requête et l’ajouter à un en-tête de requête. Cette règle peut aider la couche application à déterminer de quel locataire provient la demande.

• Supposons que vous déployiez un niveau d’application mutualisé et utilisiez le routage basé sur le chemin, tels que https://application.contoso.com/tenant1/welcome et https://application.contoso.com/tenant2/welcome, par exemple pour les locataires 1 et 2, respectivement. Vous pouvez utiliser le moteur de règles pour extraire le segment d’identificateur du locataire à partir du segment de chemin d’URL et réécrire l’URL pour inclure l’identificateur de locataire dans un paramètre de chaîne de requête ou un en-tête de requête pour que l’application consomme.

Pour plus d’informations, consultez le moteur de règles Azure Front Door.

Exemples de scénarios

Les exemples de scénarios suivants illustrent la façon dont vous pouvez configurer différentes architectures mutualisées dans Azure Front Door et comment les décisions que vous prenez peuvent affecter votre configuration DNS et TLS.

De nombreuses solutions mutualisées implémentent le Modèle Empreintes de déploiement. Lorsque vous utilisez cette approche de déploiement, vous déployez généralement un profil Azure Front Door partagé unique et utilisez Azure Front Door pour acheminer le trafic entrant vers le tampon approprié. Ce modèle de déploiement est le plus courant et les scénarios 1 à 4 de cet article montrent comment vous pouvez l’utiliser pour répondre à une plage de conditions requises.

Toutefois, dans certains cas, vous pouvez déployer un profil Azure Front Door dans chaque instance de votre solution. Le scénario 5 décrit ce modèle de déploiement.

Scénario 1 : Domaine générique géré par le fournisseur, empreinte unique

Contoso est en train de créer une petite solution multilocataire. L’entreprise déploie un tampon unique dans une seule région, et ce tampon sert tous ses locataires. Toutes les requêtes sont acheminées vers le même serveur d’applications. Contoso a décidé d’utiliser des domaines génériques pour tous les locataires, comme tenant1.contoso.com et tenant2.contoso.com.

Contoso déploie Azure Front Door à l’aide de la configuration suivante.

L’image montre une configuration Azure Front Door. Il inclut un CNAME et un point de terminaison Azure Front Door. Deux locataires pointent vers le même domaine personnalisé générique. Une flèche pointe du domaine personnalisé vers le certificat TLS générique partagé, qui réside dans Key Vault. Une autre flèche pointe du domaine personnalisé vers l’itinéraire. Une flèche pointe de l’itinéraire vers le groupe d’origine, puis du groupe d’origine vers le serveur d’origine, également étiqueté comme empreinte d’application.

Configuration de DNS

Configuration ponctuelle : Contoso configure deux entrées DNS.

• Un enregistrement TXT joker pour *.contoso.com est défini sur la valeur spécifiée par Azure Front Door pendant le processus d’intégration de domaine personnalisé.

• Un enregistrement CNAME générique, *.contoso.com, est un alias pour le point de terminaison Azure Front Door de Contoso contoso.z01.azurefd.net.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration TLS

Configuration ponctuelle : Contoso achète un certificat TLS générique, l’ajoute à un coffre de clés et accorde à Azure Front Door l’accès au coffre.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration d’Azure Front Door

Configuration ponctuelle : Contoso crée un profil Azure Front Door et un point de terminaison unique.

• Ils ajoutent un domaine personnalisé avec le nom *.contoso.com et associent leur certificat TLS générique à la ressource de domaine personnalisé.

• Ils configurent un groupe d’origine unique qui contient une origine unique pour leur serveur d’applications.

• Ils configurent un itinéraire pour connecter le domaine personnalisé au groupe d’origine.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Avantages

• Ce scénario est relativement facile à configurer et fournit aux clients des URL de marque Contoso.

• Cette approche prend en charge un grand nombre de locataires.

• Lorsqu’un nouveau locataire est intégré, Contoso n’a pas besoin d’apporter de modifications aux certificats Azure Front Door, DNS ou TLS.

Inconvénients

• Cette approche n’est pas facilement mise à l’échelle au-delà d’un tampon d’application ou d’une seule région.

• Contoso doit acheter un certificat TLS générique et renouveler et installer le certificat à son expiration.

Scénario 2 : domaine générique géré par le fournisseur, plusieurs empreintes

Proseware crée une solution multilocataire sur plusieurs empreintes déployées en Australie et en Europe. Toutes les demandes au sein d’une même région sont traitées par l’empreinte dans cette région. Comme Contoso, Proseware a décidé d’utiliser des domaines génériques pour tous les locataires, comme tenant1.proseware.com et tenant2.proseware.com.

Proseware déploie Azure Front Door à l’aide de la configuration suivante :

L’image montre une configuration Azure Front Door. Il inclut un CNAME et un point de terminaison Azure Front Door. Il y a deux flux. Chaque locataire pointe vers un domaine personnalisé unique, puis de ce domaine personnalisé à un certificat TLS générique partagé qui réside dans Key Vault. Une flèche pointe du domaine personnalisé vers une route, de l’itinéraire à un groupe d’origines et d’un groupe d’origines vers un serveur d’origine, qui est également étiqueté tampon d’application.

Configuration de DNS

Configuration ponctuelle : Proseware configure deux entrées DNS.

• Un enregistrement TXT joker pour *.proseware.com est défini sur la valeur spécifiée par Azure Front Door pendant le processus d’intégration de domaine personnalisé.

• Un enregistrement CNAME générique, *.proseware.com, est un alias pour le point de terminaison Azure Front Door de Proseware proseware.z01.azurefd.net.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration TLS

Configuration ponctuelle : Proseware achète un certificat TLS générique, l’ajoute à un coffre de clés et accorde à Azure Front Door l’accès au coffre.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration d’Azure Front Door

Configuration ponctuelle : Proseware crée un profil Azure Front Door et un point de terminaison unique. L’entreprise configure plusieurs groupes d’origines, un pour chaque tampon d’application ou serveur dans chaque région.

Lorsqu’un nouveau locataire est intégré : Proseware ajoute une ressource de domaine personnalisée à Azure Front Door.

• Ils utilisent le nom *.proseware.com et associent leur certificat TLS générique à la ressource de domaine personnalisée.

• Ils créent un itinéraire pour spécifier le groupe source ou l'identifiant auquel les demandes du locataire doivent être dirigées. Dans le diagramme précédent, tenant1.proseware.com les itinéraires vers le groupe d’origines de la région Australie et tenant2.proseware.com les itinéraires vers le groupe d’origine dans la région Europe.

Avantages

• Lorsque de nouveaux locataires sont intégrés, aucune modification de configuration DNS ou TLS n’est requise.

• Proseware gère une seule instance d'Azure Front Door pour acheminer le trafic vers plusieurs centres de données à travers différentes régions.

Inconvénients

• Proseware doit reconfigurer Azure Front Door chaque fois qu’un nouveau locataire est intégré.

• Proseware doit prêter attention aux quotas et limites d’Azure Front Door, en particulier sur le nombre d’itinéraires et de domaines personnalisés, ainsi que sur la limite de routage composite.

• Proseware doit acheter un certificat TLS générique.

• Proseware est responsable du renouvellement et de l’installation du certificat à son expiration.

Scénario 3 : sous-domaines génériques gérés par un fournisseur et basés sur des empreintes

Fabrikam crée une solution multilocataire. La société déploie des timbres en Australie et aux États-Unis. Toutes les demandes au sein d’une même région sont traitées par l’empreinte dans cette région. Fabrikam utilise des domaines souches basés sur des timbres comme tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comet tenant3.us.fabrikam.com.

L’entreprise déploie Azure Front Door à l’aide de la configuration suivante.

L’image montre une configuration Azure Front Door. Il inclut deux CNAME et un point de terminaison Azure Front Door. Il existe deux flux qui se terminent par des serveurs d’origine différents. Dans chaque flux, deux locataires pointent vers un domaine personnalisé à l’aide d’une entrée DNS générique. Chaque domaine personnalisé utilise un certificat TLS générique qui réside dans Key Vault. Une flèche pointe de chaque domaine personnalisé vers une route, de l’itinéraire à un groupe d’origines et d’un groupe d’origines vers un serveur d’origine, qui est également étiqueté tampon d’application.

Configuration de DNS

Configuration ponctuelle : Fabrikam configure les deux entrées DNS génériques suivantes pour chaque tampon.

• Pour chaque timbre, les enregistrements TXT génériques *.australia.fabrikam.com et *.us.fabrikam.com sont définis sur les valeurs spécifiées par Azure Front Door lors du processus d'intégration de domaine personnalisé.

• Pour chaque timbre, les enregistrements génériques CNAME *.australia.fabrikam.com et *.us.fabrikam.com sont tous les deux des alias de l'endpoint fabrikam.z01.azurefd.net Azure Front Door.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration TLS

Configuration ponctuelle : Fabrikam achète un certificat TLS générique pour chaque tampon, les ajoute à un coffre de clés et accorde à Azure Front Door l’accès au coffre.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration d’Azure Front Door

Configuration ponctuelle : Fabrikam crée un profil Azure Front Door et un point de terminaison unique.

• Ils configurent un groupe d’origine pour chaque empreinte.

• Ils créent des domaines personnalisés à l’aide d’un caractère générique pour chaque sous-domaine basé sur un tampon : *.australia.fabrikam.com et *.us.fabrikam.com.

• Ils créent un itinéraire pour le domaine personnalisé de chaque tampon afin d’envoyer le trafic au groupe d’origine approprié.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Avantages

• Cette approche permet à Fabrikam de mettre à l’échelle un grand nombre de locataires sur plusieurs empreintes.

• Lorsque de nouveaux locataires sont intégrés, aucune modification de configuration DNS ou TLS n’est requise.

• Fabrikam gère une seule instance d’Azure Front Door pour acheminer le trafic vers plusieurs empreintes dans plusieurs régions.

Inconvénients

• Étant donné que les URL utilisent une structure de domaine souche à plusieurs parties, les URL peuvent être plus complexes pour que les utilisateurs puissent travailler avec.

• Fabrikam doit acheter plusieurs certificats TLS génériques.

• Fabrikam est responsable du renouvellement et de l’installation des certificats TLS lorsqu’ils expirent.

Scénario 4 : Domaines de vanité

Adventure Works Cycles crée une solution multilocataire. La société déploie des timbres dans plusieurs régions, comme l’Australie et les États-Unis. Toutes les demandes au sein d’une même région sont traitées par l’empreinte dans cette région. Adventure Works permet à ses locataires d’apporter leurs propres noms de domaine. Par exemple, le locataire 1 peut configurer un nom de domaine personnalisé comme tenant1app.tenant1.com.

L’entreprise déploie Azure Front Door à l’aide de la configuration suivante.

L’image montre une configuration Azure Front Door. Il comprend quatre enregistrements CNAME et un point de terminaison d'Azure Front Door. Quatre locataires pointent vers quatre domaines personnalisés distincts. Les locataires 1 et 2 sont en Australie. Leurs domaines personnalisés pointent vers la même route, de l’itinéraire à un groupe d’origines et du groupe d’origine vers un serveur d’origine en Australie, qui est également étiqueté tampon d’application. Les locataires 3 et 4 sont aux États-Unis. Ils ont un flux séparé depuis un itinéraire vers un groupe source, puis vers un serveur source aux États-Unis. Les locataires 1 à 3 utilisent un certificat TLS managé dans le domaine personnalisé. Le locataire 4 n’utilise pas de certificat TLS managé et pointe plutôt vers un certificat TLS personnalisé qui réside dans Key Vault.

Configuration de DNS

Configuration ponctuelle : Aucun.

Lorsqu’un nouveau locataire est intégré : Le locataire doit créer deux enregistrements sur son propre serveur DNS.

• Un enregistrement TXT est destiné à la validation du domaine. Par exemple, le locataire 1 doit configurer un enregistrement TXT nommé tenant1app.tenant1.com et le définir sur la valeur spécifiée par Azure Front Door pendant le processus d’intégration de domaine personnalisé.

• Un enregistrement CNAME est un alias pour l'endpoint Azure Front Door d'Adventure Works. Par exemple, le locataire 1 doit configurer un enregistrement CNAME nommé tenant1app.tenant1.com et le mapper à adventureworks.z01.azurefd.net.

Configuration TLS

Adventure Works et ses locataires doivent décider qui émet des certificats TLS :

• L’option la plus simple consiste à utiliser Azure Front Door pour émettre et gérer les certificats. Toutefois, les locataires ne doivent pas configurer les enregistrements CAA sur leurs serveurs DNS. Si c’est le cas, les enregistrements peuvent empêcher l’autorité de certification Azure Front Door d’émettre des certificats.

• Les locataires peuvent également fournir leurs propres certificats. Ils doivent travailler avec Adventure Works pour charger le certificat dans un coffre de clés et fournir l’accès à Azure Front Door.

Configuration d’Azure Front Door

Configuration ponctuelle : Adventure Works crée un profil Azure Front Door et un point de terminaison unique. Ils configurent un groupe d’origine pour chaque empreinte. Ils ne créent pas de ressources de domaine ou d’itinéraires personnalisés.

Lorsqu’un nouveau locataire est intégré : Adventure Works ajoute une ressource de domaine personnalisée à Azure Front Door.

• Ils utilisent le nom de domaine fourni par le locataire et associent le certificat TLS approprié à la ressource de domaine personnalisé.

• Ils créent ensuite un itinéraire pour spécifier le groupe d’origine ou l’horodatage vers lequel les demandes du locataire doivent être adressées. Dans le diagramme précédent, tenant1app.tenant1.com est routé vers le groupe d’origine dans la région Australie et tenant2app.tenant3.com est acheminé vers le groupe d’origines dans la région AMÉRICAINE.

Avantages

• Les clients peuvent fournir leurs propres noms de domaine. Azure Front Door achemine de manière transparente les demandes vers la solution mutualisée.

• Adventure Works gère une instance unique d’Azure Front Door pour acheminer le trafic vers plusieurs sites à travers plusieurs régions.

Inconvénients

• Adventure Works doit reconfigurer Azure Front Door chaque fois qu’un nouveau locataire est intégré.

• Les locataires doivent être impliqués dans le processus d’intégration. Ils doivent apporter des modifications DNS et émettre éventuellement des certificats TLS.

• Les locataires contrôlent leurs enregistrements DNS. Les modifications apportées aux enregistrements DNS peuvent affecter leur capacité à accéder à la solution Adventure Works.

• Adventure Works doit prêter attention aux quotas et limites d’Azure Front Door, en particulier sur le nombre d’itinéraires et de domaines personnalisés, ainsi que sur la limite de routage composite.

Scénario 5 : Profil Azure Front Door pour chaque tampon

Vous pouvez déployer un profil Azure Front Door pour chaque tampon. Si vous avez 10 tampons, vous déployez 10 instances d’Azure Front Door. Cette approche peut être utile si vous devez restreindre l’accès à la gestion de la configuration Azure Front Door de chaque empreinte. Il peut également être utile si vous devez utiliser plusieurs profils Azure Front Door pour éviter de dépasser les quotas de ressources ou les limites.

Conseil / Astuce

Azure Front Door est une ressource globale. Même si vous déployez des tampons à étendue régionale, chaque profil Azure Front Door est distribué globalement. Vous devez déterminer si vous avez vraiment besoin de déployer plusieurs profils Azure Front Door et d’évaluer les avantages spécifiques qu’il fournit.

Si vous avez un tampon qui sert plusieurs locataires, vous devez réfléchir à la façon dont vous acheminez le trafic vers chaque locataire. Passez en revue les approches décrites dans les scénarios précédents. Envisagez de combiner des approches pour répondre à vos besoins.

Avantages

• Si vous étendez votre configuration sur plusieurs profils, vous êtes moins susceptible d’atteindre les limites de ressources Azure Front Door. Par exemple, si vous devez prendre en charge un grand nombre de domaines personnalisés, vous pouvez diviser les domaines entre plusieurs profils Azure Front Door et rester dans les limites de chaque profil.

• Cette approche vous permet d’étendre vos autorisations de gestion des ressources Azure Front Door. Vous pouvez utiliser le contrôle d'accès basé sur les rôles d'Azure pour accorder aux administrateurs l'accès au profil d'un "stamp" unique.

Inconvénients

• Cette approche entraîne généralement un coût élevé, car vous déployez davantage de profils. Pour plus d’informations, consultez Comprendre la facturation d’Azure Front Door.

• Il existe une limite au nombre de profils Azure Front Door que vous pouvez déployer dans un seul abonnement Azure. Pour plus d’informations, consultez les quotas et limites d’Azure Front Door.

• Vous devez configurer séparément le profil Azure Front Door de chaque tampon, et vous devez gérer la configuration DNS, les certificats TLS et la configuration TLS pour chaque tampon.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• John Downs | Ingénieur logiciel principal
• Raj Nemani | Directeur, Stratège de la technologie partenaire

Autres contributeurs :

• Mick Alberts | Rédacteur technique

• Fernando Antivero | Fullstack Developer &Cloud Platform Engineer

• Duong Au | Développeur de contenu senior, C+E Skilling Content R&D

• Harikrishnan M B (Hari) | Product Manager 2, Mise en réseau Azure

• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Formation : Présentation d’Azure Front Door
• Présentation d’Azure Front Door
• Qu’est-ce qu’Azure Front Door ?

Ressources associées

• Définir l’architecture de solutions multilocataires sur Azure
• Liste de vérification pour la conception et la construction de solutions multilocataires sur Azure
• Modèles de location à prendre en compte pour une solution multilocataire