Uso de Azure Front Door en una solución multiinquilino

Azure Front Door es una red moderna de entrega de contenido en la nube (CDN) que proporciona acceso rápido y confiable entre los usuarios y el contenido web estático y dinámico de las aplicaciones en todo el mundo. En este artículo se describen algunas de las características de Azure Front Door que son útiles al trabajar en sistemas multiinquilino. También proporciona otras instrucciones y ejemplos relacionados.

Al usar Azure Front Door como parte de una solución multiinquilino, debe tomar algunas decisiones en función del diseño y los requisitos de la solución. Tenga en cuenta los siguientes factores:

• Tenga en cuenta el número de inquilinos que tiene actualmente y el número de inquilinos que espera tener en el futuro.

• Determine si comparte el nivel de aplicación entre varios inquilinos, implementa muchas instancias de aplicación de inquilino único o implementa stamps de implementación independientes compartidas por varios inquilinos.

• Identifique si los inquilinos quieren traer sus propios nombres de dominio.

• Determine si desea usar dominios comodín.

• Evalúe si necesita usar sus propios certificados de seguridad de la capa de transporte (TLS) o si Microsoft administrará los certificados TLS.

• Tenga en cuenta las cuotas y los límites que se aplican a Azure Front Door. Identifique qué límites podría abordar a medida que se escala la solución. Si prevé acercarse a estos límites, considere la posibilidad de usar varios perfiles de Azure Front Door o ajustar cómo usa Azure Front Door para permanecer dentro de restricciones aceptables. La SKU Premium tiene límites más altos que la SKU estándar.

• Determine si usted o sus inquilinos tienen requisitos para el filtrado de direcciones IP, el bloqueo geográfico o la personalización de reglas de Firewall de aplicaciones web.

• Compruebe si todos los servidores de aplicaciones de los inquilinos están accesibles desde Internet.

Características de Azure Front Door que admiten multitenencia

En esta sección se describen varias características clave de Azure Front Door que son útiles para las soluciones multiinquilino. Describe cómo Azure Front Door puede ayudarle a configurar dominios personalizados, incluida información sobre dominios comodín y certificados TLS. También resume cómo puede usar las funcionalidades de enrutamiento de Azure Front Door para admitir multiinquilinato.

Dominios personalizados

Azure Front Door proporciona un nombre de host predeterminado para cada punto de conexión que cree, como contoso.z01.azurefd.net. Pero para la mayoría de las soluciones, asocie su propio nombre de dominio con el punto de conexión de Azure Front Door. Los nombres de dominio personalizados le permiten usar su propia personalización de marca y configurar el enrutamiento en función del nombre de host que se incluye en la solicitud de un cliente.

En una solución multiinquilino, puede usar nombres de dominio o subdominios específicos del inquilino y configurar Azure Front Door para enrutar el tráfico del inquilino al grupo de origen correcto para la carga de trabajo de ese inquilino. Por ejemplo, puede configurar un nombre de dominio personalizado como tenant1.app.contoso.com. Puede configurar varios dominios personalizados en un único perfil de Azure Front Door.

Para más información, consulte Incorporación de un dominio personalizado a Azure Front Door.

Dominios con caracteres comodín

Los dominios comodín simplifican la configuración de registros del Sistema de Nombres de Dominio (DNS) y el enrutamiento del tráfico de Azure Front Door cuando utilizas un dominio principal compartido y subdominios específicos del inquilino. Por ejemplo, supongamos que los inquilinos acceden a sus aplicaciones mediante subdominios como tenant1.app.contoso.com y tenant2.app.contoso.com. Puede configurar un dominio comodín, *.app.contoso.com, en lugar de configurar individualmente cada dominio específico de la entidad.

Azure Front Door admite la creación de dominios personalizados que usan caracteres comodín. A continuación, puede configurar una ruta para las solicitudes que llegan al dominio comodín. Al incorporar un nuevo inquilino, no es necesario volver a configurar los servidores DNS, emitir nuevos certificados TLS ni actualizar la configuración del perfil de Azure Front Door.

Los dominios comodín funcionan bien si envía todo el tráfico a un único grupo de origen. Pero si tiene stamps independientes de la solución, un dominio con caracteres comodín de nivel único no es suficiente. Necesita usar dominios de varios niveles o proporcionar una configuración adicional. Por ejemplo, puede invalidar las rutas para el subdominio de cada inquilino. Para obtener más información, consulte Consideraciones al usar nombres de dominio en una solución multiinquilino.

Azure Front Door no emite certificados TLS administrados para dominios comodín, así que necesita adquirir y proveer su propio certificado.

Certificados TLS administrados

La adquisición e instalación de certificados TLS puede ser un proceso complejo y propenso a errores. Los certificados TLS expiran después de un período de tiempo, normalmente un año, y deben volver a emitirse y volver a instalarse para evitar interrupciones en el tráfico de la aplicación. Cuando se usan certificados TLS administrados por Azure Front Door, Microsoft es responsable de emitir, instalar y renovar certificados para el dominio personalizado.

Es posible que la aplicación de origen se hospede en otro servicio de Azure que también proporcione certificados TLS administrados, como Azure App Service. Azure Front Door funciona de forma transparente con el otro servicio para sincronizar los certificados TLS.

Si los inquilinos pueden proporcionar sus propios dominios personalizados y quiere que Azure Front Door emita certificados para estos nombres de dominio, los inquilinos no deben configurar registros de autorización de entidad de certificación (CAA) en sus servidores DNS. Estos registros podrían impedir que Azure Front Door emita certificados en nombre de los inquilinos. Para obtener más información sobre la multitenencia, consulte Certificados TLS y SSL en soluciones multitenencia. Para más información sobre Azure Front Door, consulte Cifrado TLS con Azure Front Door.

Enrutamiento

Una aplicación multiinquilino puede tener uno o varios stamps de aplicación que atienden a los inquilinos. Los stamp se usan con frecuencia para habilitar implementaciones de varias regiones y para admitir el escalado de una solución a un gran número de inquilinos.

Azure Front Door tiene un conjunto eficaz de funcionalidades de enrutamiento que pueden admitir muchas arquitecturas multiinquilino. Puede usar el enrutamiento para distribuir el tráfico entre orígenes dentro de un sello, o para enviar el tráfico al sello correcto para un cliente específico. Puede configurar el enrutamiento basado en nombres de dominio individuales, nombres de dominio comodín y rutas de URL. Además, puede usar el motor de reglas para personalizar aún más el comportamiento de enrutamiento.

Para más información, vea Introducción a la arquitectura de enrutamiento.

Motor de reglas

Puede usar el motor de reglas de Azure Front Door para personalizar la forma en que Azure Front Door procesa las solicitudes en el perímetro de la red. El motor de reglas le permite ejecutar pequeños bloques de lógica dentro de la canalización de procesamiento de solicitudes de Azure Front Door. Puede usar el motor de reglas para varias tareas que incluyen, pero no se limitan a, los siguientes elementos de lista:

• Recupere información sobre la solicitud HTTP, incluidos los segmentos de la dirección URL y la ruta de acceso, y propague la información a otra parte de la solicitud.

• Modifique los elementos de la solicitud HTTP antes de enviarlos al origen.

• Modifique los elementos de la respuesta HTTP antes de que se devuelva al cliente.

• Invalide la configuración de enrutamiento de una solicitud, por ejemplo, cambiando el grupo de origen al que se debe enviar una solicitud.

En los ejemplos siguientes se usan los motores de reglas de Azure Front Door en una solución multitenencia.

• Supongamos que implementa una capa de aplicación multiinquilino en la que también usa subdominios con caracteres comodín específicos del inquilino, como se describe en los escenarios de ejemplo siguientes. Puede usar el motor de reglas para extraer el identificador de inquilino del subdominio de solicitud y agregarlo a un encabezado de solicitud. Esta regla podría ayudar al nivel de aplicación a determinar de qué inquilino procede la solicitud.

• Supongamos que implementa un nivel de aplicación multiinquilino y usa el enrutamiento basado en rutas de acceso, como https://application.contoso.com/tenant1/welcome y https://application.contoso.com/tenant2/welcome para los inquilinos 1 y 2, respectivamente. Puede usar el motor de reglas para extraer el segmento de identificador de inquilino del segmento de ruta de la URL y volver a escribir la dirección URL para incluir el identificador de inquilino en un parámetro de cadena de consulta o encabezado de solicitud para que la aplicación lo consuma.

Para más información, consulte Motor de reglas de Azure Front Door.

Escenarios de ejemplo

En los siguientes escenarios de ejemplo se muestra cómo puede configurar varias arquitecturas multiinquilino en Azure Front Door y cómo las decisiones que tome pueden afectar a la configuración de DNS y TLS.

Muchas soluciones multiinquilino implementan el patrón de stamps de implementación. Cuando se usa este enfoque de implementación, normalmente se implementa un único perfil compartido de Azure Front Door y se usa Azure Front Door para enrutar el tráfico entrante al stamp adecuado. Este modelo de implementación es el más común y los escenarios del 1 al 4 de este artículo muestran cómo se puede usar para cumplir una serie de requisitos.

Sin embargo, en algunos casos, puede implementar un perfil de Azure Front Door en cada stamp de la solución. En el escenario 5 se describe este modelo de implementación.

Escenario 1: dominio comodín administrado por el proveedor, sello único

Contoso está creando una solución multiinquilino pequeña. La empresa implementa un único sello en una sola región y ese sello atiende a todos sus inquilinos. Todas las solicitudes se enrutan al mismo servidor de aplicaciones. Contoso decidió usar dominios comodín para todos los inquilinos, como tenant1.contoso.com y tenant2.contoso.com.

Contoso implementa Azure Front Door mediante la siguiente configuración.

La imagen muestra una configuración de Azure Front Door. Incluye un CNAME y un endpoint de Azure Front Door. Dos inquilinos apuntan al mismo dominio personalizado con caracteres comodín. Una flecha apunta desde el dominio personalizado al certificado TLS de carácter comodín compartido, que reside en Key Vault. Otra flecha apunta desde el dominio personalizado a la ruta. Una flecha apunta desde la ruta al grupo de origen y desde el grupo de origen al servidor de origen, que también se etiqueta como marca de aplicación.

Configuración de DNS

Configuración única: Contoso configura dos entradas DNS.

• Un registro TXT con caracteres comodín para *.contoso.com se establece en el valor que Azure Front Door especifica durante el proceso de incorporación de dominio personalizado.

• Un registro CNAME con caracteres comodín, *.contoso.com, es un alias para el punto de conexión de Azure Front Door de Contoso contoso.z01.azurefd.net.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de TLS

Configuración única: Contoso compra un certificado TLS comodín, lo incorpora a un almacén de claves y concede a Azure Front Door acceso al almacén.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de Azure Front Door

Configuración única: Contoso crea un perfil de Azure Front Door y un único punto de conexión.

• Agregan un dominio personalizado con el nombre *.contoso.com y asocian su certificado TLS comodín al recurso de dominio personalizado.

• Configuran un único grupo de origen que contiene un único origen para su servidor de aplicaciones.

• Configuran una ruta para conectar el dominio personalizado al grupo de origen.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Ventajas

• Este escenario es relativamente fácil de configurar y proporciona a los clientes direcciones URL con marca Contoso.

• Este enfoque admite un gran número de inquilinos.

• Cuando se incorpora un nuevo inquilino, Contoso no necesita realizar cambios en los certificados Azure Front Door, DNS o TLS.

Inconvenientes

• Este enfoque no se escala fácilmente más allá de un solo stamp de aplicación o región.

• Contoso necesita comprar un certificado TLS de comodín y renovarlo e instalarlo cuando expire.

Escenario 2: dominio con caracteres comodín administrado por el proveedor, varios stamps

Proseware está creando una solución multiinquilino en varios stamps que se implementan en Australia y Europa. Todas las solicitudes dentro de una sola región las atiende el stamp de esa región. Al igual que Contoso, Proseware decidió usar dominios comodín para todos los inquilinos, como tenant1.proseware.com y tenant2.proseware.com.

Proseware implementa Azure Front Door mediante la siguiente configuración:

La imagen muestra una configuración de Azure Front Door. Incluye un CNAME y un endpoint de Azure Front Door. Hay dos flujos. Cada inquilino apunta a un dominio personalizado único y, a continuación, desde ese dominio personalizado a un certificado TLS con caracteres comodín compartido que reside en Key Vault. Una flecha apunta desde el dominio personalizado a una ruta, desde la ruta a un grupo de origen y desde un grupo de origen a un servidor de origen, que también se etiqueta como marca de aplicación.

Configuración de DNS

Configuración única: Proseware configura dos entradas DNS.

• Un registro TXT con caracteres comodín para *.proseware.com se establece en el valor que Azure Front Door especifica durante el proceso de incorporación de dominio personalizado.

• Un registro CNAME con caracteres comodín, *.proseware.com, es un alias para el punto de conexión de Azure Front Door de Proseware proseware.z01.azurefd.net.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de TLS

Configuración única: Proseware compra un certificado TLS con caracteres comodín, lo agrega a un almacén de claves y concede a Azure Front Door acceso al almacén.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de Azure Front Door

Configuración única: Proseware crea un perfil de Azure Front Door y un único punto de conexión. La empresa configura varios grupos de origen, uno para cada marca de aplicación o servidor de cada región.

Cuando se incorpora un nuevo inquilino: Proseware agrega un recurso de dominio personalizado a Azure Front Door.

• Usan el nombre *.proseware.com y asocian su certificado TLS comodín al recurso de dominio personalizado.

• Crean una ruta para especificar a qué grupo de origen o a qué sello se deben dirigir las solicitudes de ese inquilino. En el diagrama anterior, tenant1.proseware.com las rutas al grupo de origen de la región de Australia y tenant2.proseware.com las rutas al grupo de origen de la región de Europa.

Ventajas

• Cuando se incorporan nuevos inquilinos, no se requieren cambios de configuración de DNS o TLS.

• Proseware mantiene una única instancia de Azure Front Door para enrutar el tráfico a varios stamps entre varias regiones.

Inconvenientes

• Proseware debe volver a configurar Azure Front Door cada vez que se incorpore un nuevo inquilino.

• Proseware debe prestar atención a las cuotas y límites de Azure Front Door, especialmente en el número de rutas y dominios personalizados, y el límite de enrutamiento compuesto.

• Proseware debe comprar un certificado comodín TLS.

• Proseware es responsable de renovar e instalar el certificado cuando expire.

Escenario 3: subdominios de caracteres comodín administrados por el proveedor y basados en stamps

Fabrikam está creando una solución multiinquilino. La empresa implementa sellos en Australia y Estados Unidos. Todas las solicitudes dentro de una sola región las atiende el stamp de esa región. Fabrikam usa dominios troncales basados en stamps como tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.com y tenant3.us.fabrikam.com.

La empresa implementa Azure Front Door mediante la siguiente configuración.

La imagen muestra una configuración de Azure Front Door. Incluye dos CNAME y un punto de conexión de Azure Front Door. Hay dos flujos que terminan con servidores de origen diferentes. En cada flujo, dos inquilinos apuntan a un dominio personalizado mediante una entrada DNS con caracteres comodín. Cada dominio personalizado usa un certificado TLS con caracteres comodín que reside en Key Vault. Una flecha apunta de cada dominio personalizado a una ruta, desde la ruta a un grupo de origen y desde un grupo de origen a un servidor de origen, que también se etiqueta como marca de aplicación.

Configuración de DNS

Configuración única: Fabrikam configura las dos entradas DNS de caracteres comodín siguientes para cada sello.

• Para cada stamp, los registros TXT con caracteres comodín *.australia.fabrikam.com y *.us.fabrikam.com se establecen en los valores que Azure Front Door especifica durante el proceso de incorporación de dominio personalizado.

• Para cada stamp, los registros CNAME con caracteres comodín *.australia.fabrikam.com y *.us.fabrikam.com son alias para el punto de conexión de Azure Front Door fabrikam.z01.azurefd.net.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de TLS

Configuración única: Fabrikam compra un certificado TLS con caracteres comodín para cada stamp, los agrega a un almacén de claves y concede a Azure Front Door acceso al almacén.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de Azure Front Door

Configuración única: Fabrikam crea un perfil de Azure Front Door y un único punto de conexión.

• Configuran un grupo de origen para cada sello.

• Crean dominios personalizados, mediante un carácter comodín, para cada subdominio basado en stamps: *.australia.fabrikam.com y *.us.fabrikam.com.

• Crean una ruta para el dominio personalizado de cada sello para enviar tráfico al grupo de origen adecuado.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Ventajas

• Este enfoque permite que Fabrikam se escale a un gran número de inquilinos en varios stamps.

• Cuando se incorporan nuevos inquilinos, no se requieren cambios de configuración de DNS o TLS.

• Fabrikam mantiene una única instancia de Azure Front Door para enrutar el tráfico a varios stamps entre varias regiones.

Inconvenientes

• Dado que las direcciones URL usan una estructura de dominio raíz de varias partes, las direcciones URL pueden ser más complejas para que los usuarios trabajen con ellas.

• Fabrikam debe comprar varios certificados TLS con caracteres comodín.

• Fabrikam es responsable de renovar e instalar los certificados TLS cuando expiren.

Escenario 4: dominios personales

Adventure Works Cycles está creando una solución multiinquilino. La empresa implementa sellos en varias regiones, como Australia y Estados Unidos. Todas las solicitudes dentro de una sola región las atiende el stamp de esa región. Adventure Works permite que sus inquilinos traigan sus propios nombres de dominio. Por ejemplo, el inquilino 1 podría configurar un nombre de dominio personalizado como tenant1app.tenant1.com.

La empresa implementa Azure Front Door mediante la siguiente configuración.

La imagen muestra una configuración de Azure Front Door. Incluye cuatro CNAME y un punto de conexión de Azure Front Door. Cuatro inquilinos apuntan a cuatro dominios personalizados independientes. Los inquilinos 1 y 2 están en Australia. Sus dominios personalizados apuntan a la misma ruta, desde la ruta a un grupo de origen y desde el grupo de origen a un servidor de origen en Australia, que también se denomina como stamp de aplicación. Los inquilinos 3 y 4 están en Estados Unidos. Tienen un flujo independiente de una ruta a un grupo de origen y, a continuación, a un servidor de origen en Estados Unidos. Los inquilinos de 1 a 3 usan un certificado TLS administrado en el dominio personalizado. El inquilino 4 no usa un certificado TLS administrado y, en su lugar, apunta a un certificado TLS personalizado que reside en Key Vault.

Configuración de DNS

Configuración única: Ninguno.

Cuando se incorpora un nuevo inquilino: El inquilino debe crear dos registros en su propio servidor DNS.

• Un registro TXT es para la validación de dominio. Por ejemplo, el inquilino 1 debe configurar un registro TXT denominado tenant1app.tenant1.com y establecerlo en el valor que Azure Front Door especifica durante el proceso de incorporación de dominio personalizado.

• Un registro CNAME es un alias del punto de conexión de Azure Front Door de Adventure Works. Por ejemplo, el inquilino 1 debe configurar un registro CNAME denominado tenant1app.tenant1.com y asignarlo a adventureworks.z01.azurefd.net.

Configuración de TLS

Adventure Works y sus inquilinos deben decidir quién emite certificados TLS:

• La opción más sencilla es usar Azure Front Door para emitir y administrar los certificados. Sin embargo, los inquilinos no deben configurar registros de CAA en sus servidores DNS. Si lo hacen, los registros podrían impedir que la entidad de certificación de Azure Front Door emita certificados.

• Como alternativa, los inquilinos pueden proporcionar sus propios certificados. Deben trabajar con Adventure Works para cargar el certificado en un almacén de claves y proporcionar acceso a Azure Front Door.

Configuración de Azure Front Door

Configuración única: Adventure Works crea un perfil de Azure Front Door y un único punto de conexión. Configuran un grupo de origen para cada sello. No crean recursos ni rutas de dominio personalizados.

Cuando se incorpora un nuevo inquilino: Adventure Works agrega un recurso de dominio personalizado a Azure Front Door.

• Usan el nombre de dominio proporcionado por el inquilino y asocian el certificado TLS adecuado al recurso de dominio personalizado.

• Después, crean una ruta para especificar a qué grupo de origen o a qué marca se deben dirigir las solicitudes del inquilino. En el diagrama anterior, tenant1app.tenant1.com se enruta al grupo de origen de la región de Australia y tenant2app.tenant3.com se enruta al grupo de origen de la región de EE. UU.

Ventajas

• Los clientes pueden proporcionar sus propios nombres de dominio. Azure Front Door enruta de forma transparente las solicitudes a la solución multiinquilino.

• Adventure Works mantiene una única instancia de Azure Front Door para enrutar el tráfico a varios stamps entre varias regiones.

Inconvenientes

• Adventure Works debe volver a configurar Azure Front Door cada vez que se incorpore un nuevo inquilino.

• Los inquilinos deben participar en el proceso de incorporación. Deben realizar cambios en DNS y, posiblemente, emitir certificados TLS.

• Los inquilinos controlan sus registros DNS. Los cambios en los registros DNS pueden afectar a su capacidad de acceder a la solución Adventure Works.

• Adventure Works debe prestar atención a las cuotas y límites de Azure Front Door, especialmente en el número de rutas y dominios personalizados, y el límite de enrutamiento compuesto.

Escenario 5: Perfil de Azure Front Door para cada sello

Puede implementar un perfil de Azure Front Door para cada sello. Si tiene 10 stamps, implementará 10 instancias de Azure Front Door. Este enfoque puede ser útil si necesita restringir el acceso de administración de la configuración de Azure Front Door de cada stamp. También puede ser útil si necesita usar varios perfiles de Azure Front Door para evitar superar las cuotas o límites de recursos.

Sugerencia

Azure Front Door es un recurso global. Incluso si implementa stamps de ámbito regional, cada perfil de Azure Front Door se distribuye globalmente. Debe tener en cuenta si realmente necesita implementar varios perfiles de Azure Front Door y evaluar las ventajas específicas que proporciona.

Si tiene un stamp que sirve a varios inquilinos, debe tener en cuenta cómo enruta el tráfico a cada inquilino. Revise los enfoques descritos en los escenarios anteriores. Considere la posibilidad de combinar enfoques para adaptarse a sus requisitos.

Ventajas

• Si amplía la configuración en varios perfiles, es menos probable que alcance los límites de recursos de Azure Front Door. Por ejemplo, si necesita admitir un gran número de dominios personalizados, puede dividir los dominios entre varios perfiles de Azure Front Door y permanecer dentro de los límites de cada perfil.

• Este enfoque le permite definir el ámbito de los permisos de administración de recursos de Azure Front Door. Puede usar el control de acceso basado en roles de Azure para conceder a los administradores acceso al perfil de un determinado sello.

Inconvenientes

• Este enfoque suele suponer un alto costo porque se implementan más perfiles. Para más información, consulte Descripción de la facturación de Azure Front Door.

• Hay un límite en el número de perfiles de Azure Front Door que puede implementar en una sola suscripción de Azure. Para más información, consulte Cuotas y límites de Azure Front Door.

• Debe configurar el perfil de Azure Front Door de cada stamp por separado y debe administrar la configuración de DNS, los certificados TLS y la configuración de TLS para cada stamp.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

• John Downs | Ingeniero principal de software
• Raj Nemani | Director, Estratega de Tecnología para Socios

Otros colaboradores:

• Mick Alberts | Escritor técnico

• Fernando Antivero | Ingeniero de plataforma en la nube y desarrollador de Fullstack

• Duong Au | Desarrollador de contenido sénior, I+D de contenido de aptitudes de C+E

• Harikrishnan M B (Hari) | Product Manager 2, Redes de Azure

• Arsen Vladimirskiy | Ingeniero Principal de Clientes, FastTrack para Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Aprendizaje: Introducción a Azure Front Door
• Introducción a Azure Front Door
• ¿Qué es Azure Front Door?

Recursos relacionados

• Arquitectar soluciones multicliente en Azure
• Lista de comprobación para diseñar y crear soluciones multiinquilino en Azure
• Modelos de inquilinato que se deben tener en cuenta para una solución multiinquilino