Limitações do Gateway de Aplicativo do Azure - certificado SSL curinga

Question

Temos ~ 60 aplicativos clientes, cada um com seu próprio URL de subdomínio em um domínio comum, ou seja, client1.domainname.com, client2.domainname.com ... - todos abrangidos por um único certificado SSL curinga * .domainname.com . Atualmente hospedados on-prem com um par de LBs e 2 nós IIS backend usando cabeçalhos de host para URLs de subdomínio e afinidade de sessão de cookie.

Precisamos migrar esse ambiente para o Azure e utilizar o Application Gateway. Infelizmente, o AG tem algumas limitações drásticas link , a saber:

1) HTTP Listeners   20
2) Number of sites  20  1 per HTTP Listeners
3) URL Maps per listener    1

Perguntas:

A) em relação a # 2, pode curinga *. domainname.com ser tratado como 1 site / usado na propriedade Hostname da definição de Listener?

• se não, isso significa que preciso criar 1 ouvinte por cliente, por exemplo, HTTPSListener1- > client1.domainname.com, HTTPSListener2- > client2.domainname.com e assim por diante?
• • se a resposta for 'sim', posso usar o mesmo certificado curinga * .domainname.com na propriedade SslCertificate de vários ouvintes, enquanto apenas o campo Hostname será alterado para ser cliente (subdomínio) específico?
• • • Se for verdade, isso significa que, com uma limitação de 20 Listeners por AG, precisarei criar três conjuntos separados de AGs para ajustar meus 60 subdomínios, o que significa que incorreria em custos desnecessários executando pares de AG adicionais

B) há apenas dois nós de back-end no local e preferimos o mesmo no Azure para economia de custos; No meu entender, vários conjuntos de AG não podem apontar para as mesmas VMs de back-end. Pode uma solução alternativa para isso estar tendo vários vNICs por VM e apontando para diferentes conjuntos AG, ou seja, AG1 set- > vNIC0 primário, AG2 set- > vNIC1 secundário, AG3 set- > vNIC2 secundário?

Desculpe pela pergunta carregada, mas espero que os outros considerem este post muito útil, pois informações detalhadas sobre este tópico não aparecem facilmente.

Exemplo de ouvinte:

"httpListeners": [
    {
        "name": "appGatewayHttpsListener1",
        "properties": {
            "FrontendIPConfiguration": {
                "Id": "/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGateway1/frontendIPConfigurations/DefaultFrontendPublicIP"
            },
            "FrontendPort": {
                "Id": "/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGateway1/frontendPorts/appGatewayFrontendPort443'"
            },
            "Protocol": "Https",
            "SslCertificate": {
                "Id": "/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGateway1/sslCertificates/appGatewaySslCert1'"
            },
            "HostName": "domainname.com" ,
            "RequireServerNameIndication": "true"
        }
    },

    

Answer 1

Se eu entendi sua pergunta corretamente, você não é NECESSÁRIO para colocar um nome de caminho para o ouvinte. Você pode, em vez disso, ter um único ouvinte global para cobrir todo o seu * .domínio.com. Isso ajuda?