Itens a considerar antes de usar o ExpressRoute com o Microsoft Power Platform
A complexidade da configuração do ExpressRoute costuma ser subestimada. Em particular, as seguintes ações e implicações são frequentemente esquecidas, seja no planejamento ou na execução:
Configurando sua rede para rotear o tráfego para a sub-rede conectada ao ExpressRoute
Evitando o roteamento assimétrico, onde o tráfego vai diretamente para o Microsoft Power Platform pela Internet, mas é retornado pelo ExpressRoute para a rede corporativa, desencadeando a rejeição do tráfego pelo firewall
Os custos gerais de provisionamento do ExpressRoute, incluindo serviços do Microsoft Azure, provisionamento de provedor de conectividade e configuração de roteamento de rede interna de TI e serviço contínuo
Determinar se vários circuitos ExpressRoute devem ser estabelecidos para implantações distribuídas
Problemas de desempenho de conectividade
Conectividade de LAN
Alguns dos problemas comuns que um usuário pode enfrentar são:
A conectividade dentro da rede local já está saturada antes de adicionar um aplicativo de navegador avançado à combinação.
O Microsoft Power Platform está substituindo um aplicativo cliente pesado em que apenas os dados foram transmitidos pela rede, em vez de dados e informações de apresentação.
É importante entender que um aplicativo de navegador, embora exija menos em termos de administração de implantação do lado do cliente, exigirá maior largura de banda do que um aplicativo cliente pesado e, portanto, uma rede local já saturada sofrerá ainda mais com a adição de novos serviços.
Conectividade WAN ruim
Com base na análise da conectividade da rede com o serviço online, um padrão comum é que, em algum ponto, o tráfego da rede atravessa uma rota de rede interna que adiciona latência significativa. Isso pode ser devido a condições como:
Saturação do link da WAN.
Processamento de proxy, gerando mais latência e sobrecarga.
Roteamento interno ineficiente (por exemplo, roteamento dentro da rede corporativa, em vez de roteamento para a Internet anteriormente).
Se o tráfego do Microsoft Power Platform sofre com esses desafios, o desempenho no cliente também pode ser prejudicado.
Conectividade com a Internet ruim
Adicionar serviços em nuvem pode gerar consumo e carga extras na conexão corporativa com a Internet. Isso pode acontecer se:
A conexão com a Internet não for suficiente para suportar a carga adicional.
Dentro da rede do provedor de serviços de Internet (ISP), o roteamento desse tráfego para a rede é controlado pelo ISP; a eficiência desse roteamento pode variar. Microsoft
A conexão sofre com uma mistura de tráfego, o que afeta a qualidade da conexão (por exemplo, várias sessões de treinamento baseadas na Internet, Microsoft Stream, ou vídeos do YouTube com tráfego para um aplicativo crítico de negócios competindo pela largura de banda disponível). Isso pode ser suficiente em geral para o volume de tráfego, mas pode afetar potencialmente o desempenho por meio de picos de demanda que ocorrerão com atividades como streaming de vídeo.
Isso pode ser resolvido obtendo-se largura de banda adicional ou conexões separadas por meio do ISP. Em particular, ter uma conexão separada dedicada ao tráfego prioritário pode ajudar tanto no desempenho quanto na previsibilidade do tráfego.
Além disso, certifique-se de configurar a Qualidade de Serviço (QoS) corretamente. Se estiver usando o Microsoft Teams e o Microsoft Stream, consulte os requisitos de QoS no ExpressRoute.
Controle de segurança
A próxima configuração que você precisa considerar é o controle de segurança. O ExpressRoute em si não criptografa ou filtra o tráfego nativamente (com exceção do ExpressRoute Direct com MACsec habilitado); ele simplesmente estabelece uma conexão privada, em vez de compartilhada, diretamente entre os Microsoft datacenters e os do cliente por meio de seu provedor de conectividade.
Qualquer solicitação de qualquer Microsoft serviço online ou serviço do Azure para a sub-rede anunciada por meio de um circuito ExpressRoute será roteada por meio desse circuito, independentemente do serviço ou cliente. Como a solicitação é roteada na camada de rede, não há controle no nível do aplicativo para determinar se esse é um solicitante apropriado para esse serviço de destino.
Para tráfego para serviços, como são serviços públicos compartilhados, eles podem ser acessados diretamente pela internet pública. Microsoft O controle de acesso a esses serviços é feito por meio de serviços de autenticação e autorização em nível do aplicativo. Eles estão ainda mais protegidos em nível de infraestrutura contra intrusões e ameaças, como ataques de negação de serviço.
Para tráfego de Microsoft serviços para serviços hospedados em local, o cliente é responsável por fornecer proteção semelhante aos seus próprios serviços quando o tráfego é recebido por meio de uma conexão ExpressRoute.
Capacidade de restringir o uso do ExpressRoute apenas a determinados serviços Microsoft
Um dos desafios que você pode enfrentar é querer usar o ExpressRoute para um serviço de nuvem específico, mas não para outros. Microsoft Embora as diferentes opções de emparelhamento forneçam algum nível de controle aqui, o emparelhamento em si não fornece controle granular em serviços do mesmo tipo de emparelhamento (por exemplo, para habilitar o roteamento apenas para máquinas virtuais do Azure, mas não para o Microsoft 365). É possível, no entanto, usar comunidades do Border Gateway Protocol (BGP) para configurar o tráfego apenas para serviços específicos.
Isso é relevante para os serviços da Microsoft Power Platform com presença do Microsoft 365, em que o roteamento via ExpressRoute pode ser desejável para um serviço, mas não para ambos, ou apenas para determinados serviços individuais do Microsoft 365, como o Microsoft Teams.
O ExpressRoute em si não oferece atualmente a capacidade de configurar serviços diretamente a serem roteados por meio de um circuito do ExpressRoute específico neste nível de granularidade de serviço, mas as comunidades BGP podem ser usadas para controlar isso.
Microsoft anuncia rotas nos Microsoft caminhos de peering com rotas marcadas usando valores de comunidade BGP apropriados para localizações geográficas e tipos de serviço. Elas podem então ser configurados nos roteadores do cliente para rotear o tráfego para esses serviços por meio do circuito do ExpressRoute.
É possível usar diferentes tags para serviços do Microsoft 365 para rotear o tráfego apenas para esses serviços por meio do circuito do ExpressRoute e rotear o restante em um circuito do ExpressRoute diferente ou na Internet pública.
Os valores da comunidade do BGP específicos do Microsoft Power Platform não estão disponíveis como estão para os serviços do Microsoft 365. Em vez disso, as comunidades BGP regionais são usadas com as regiões do Microsoft Azure correspondentes que são usadas para cada ambiente da Microsoft Power Platform. Como os ambientes da Microsoft Power Platform usam dois conjuntos de datacenters, certifique-se de consultar a visão geral das Regiões para verificar quais dois datacenters são usados. Mais informações: comunidades BGP para GCC
Microsoft 365
Como Microsoft Power Platform serviços e Microsoft 365 serviços são oferecidos por meio de Microsoft peering, a configuração do Microsoft peering anunciaria por padrão todos os Microsoft Power Platform serviços e Microsoft 365 serviços no circuito do ExpressRoute.
O resultado disso é que ativar as comunidades BGP para encaminharem o tráfego para um serviço faria com que ambas fossem roteadas pelo ExpressRoute. Isso pode ou não ser desejável, mas pode ter resultados desfavoráveis. Por exemplo, se você determinou a largura de banda de rede necessária para a Microsoft Power Platform e dimensionou a conexão do ExpressRoute de forma apropriada, mas inadvertidamente também roteou todo o tráfego do Microsoft 365 por meio do ExpressRoute, isso pode saturar sua rede e causar desafios de desempenho.
Embora a ativação do ExpressRoute para Microsoft peering roteie todo Microsoft Power Platform e Microsoft 365 tráfego pela conexão ExpressRoute, é possível usar tags de comunidade BGP para controlar o roteamento de modo que apenas serviços específicos — como Microsoft Power Platform serviços, mas não outros Microsoft 365 serviços — usem a conexão ExpressRoute. Em particular, nem todos os serviços do Microsoft 365 são projetados para funcionar com o ExpressRoute. Atualmente, os serviços da Microsoft Power Platform não têm uma comunidade do BGP designada como alguns serviços do Microsoft 365 têm. Em vez disso, você deve usar comunidades regionais de BPG para combinar com a região onde o ambiente da Microsoft Power Platform foi criado.
Para obter mais informações sobre o roteamento do Microsoft 365, acesse a documentação em roteamento seletivo com o Microsoft 365.
Como os serviços da Microsoft Power Platform funcionam parcialmente como parte do serviço do Microsoft 365, também são necessários muitos serviços cruzados, como o portal de administração e a autenticação. Não é possível proteger todos esses serviços usando o ExpressRoute; o centro de administração do Microsoft 365 (por exemplo, não é publicado no ExpressRoute).
Suporte para nuvens soberanas
Os clientes que precisam atender às regulamentações governamentais ou específicas do país/região podem optar por usar uma nuvem soberana. As nuvens soberanas estão fisicamente localizadas em uma região para atender aos requisitos específicos daquele governo ou país/região em particular. Por exemplo, o Power Apps para Government Community Cloud (GCC) está localizado nos Estados Unidos, onde atende regulamentações e certificações específicas do governo dos EUA, e satisfaz os protocolos para atender a esses requisitos.
Assista a este vídeo que descreve como o Microsoft Power Platform está disponível com nuvens soberanas: Vídeo: Nuvens Soberanas com Marty Carreras.
Ao considerar o uso de um ambiente de nuvem soberana, você deve considerar quais limitações existem, porque nem todos os recursos estão disponíveis quando comparados com os ambientes de nuvem pública. A disponibilidade de cada ambiente para o Microsoft Power Platform está listado na tabela a seguir. Para outras diferenças na disponibilidade, leia a documentação sobre regiões de datacenter.
| Região | Suporte ExpressRoute |
|---|---|
| Nuvem Governamental de Comunidade (GCC) dos EUA | Com suporte 1 |
| Nuvem comunitária do governo dos EUA alta (GCC High) | Com suporte 1 |
| China | Com suporte 2 |
1 Os clientes devem usar o Azure Government ExpressRoute ao usar o GCC dos EUA ou GCC High regiões e não podem usar o ExpressRoute da nuvem comercial do Azure. 2 Os clientes devem usar o ExpressRoute da China do Azure ao usar as regiões da China não podem usar o ExpressRoute da nuvem do Azure commercial.
Custos do Azure ExpressRoute
Ao estimar os custos do ExpressRoute, você precisa considerar vários elementos:
Custos do Azure
Custos do provedor de conectividade
Custos de esforço de configuração interna
Para determinar o caso de negócios com precisão, é importante considerar todos esses custos ao avaliar o ExpressRoute para o Microsoft Power Platform. Cada um é discutido nas seções a seguir.
Custos do Azure
O Azure ExpressRoute pode ser adquirido em modelos diferentes.
Tipo de Cobrança
Medido: um custo de assinatura básico por mês com tráfego de entrada ilimitado, mas uma cobrança por GB para tráfego de saída
Ilimitado: um custo de assinatura básico por mês com tráfego de entrada e saída ilimitado
SKI/Plano
Standard
Conexão básica usando ExpressRoute
Oferecendo acesso a serviços em uma única região geográfica
Se o circuito do ExpressRoute estiver na mesma região que o ambiente do Microsoft Power Platform ao qual os usuários estão se conectando, apenas o padrão do ExpressRoute é necessário para esse circuito
Premium
Oferece acesso a serviços geográficos em todo o mundo, de onde quer que a conexão seja feita
Se um usuário se conectar por meio de um circuito do ExpressRoute de uma região diferente do serviço final, ele exigirá o ExpressRoute Premium para esse circuito do ExpressRoute.
Mais informações: Preços do Azure ExpressRoute
Custos do provedor de conectividade
Em alguns casos, os custos de estabelecer a conexão com o provedor de conectividade podem ser significativos. Eles são separados dos custos do Azure para ExpressRoute.
Esforço do cliente interno para configurar o roteamento da rede
Para habilitar o ExpressRoute, o roteamento da rede deve ser configurado internamente.
Para muitos clientes, isso exigirá uma cobrança cruzada interna para a equipe de rede ou um custo externo para um provedor de terceirização de TI, ou pelo menos um custo de oportunidade para os esforços da equipe interna se concentrarem na configuração.
Impactos nos serviços existentes da Microsoft Power Platform, Microsoft 365 e Azure em uso
Quando o peering estiver habilitado, isso configurará o tráfego para serviços, e Azure para ser roteado via ExpressRoute. Microsoft Microsoft Power Platform Microsoft 365
Se você já estiver usando Microsoft Power Platform, aplicativos do Dynamics 365 ou Microsoft 365 sem o ExpressRoute, é importante estar atento ao impacto nesses serviços existentes ao habilitar Microsoft o peering pelo ExpressRoute (que é o comportamento padrão). Pode ser necessário configurar o roteamento usando comunidades BGP para separar o tráfego para serviços diferentes.
Reutilização do ExpressRoute em vários serviços online
Uma única conexão do ExpressRoute pode ser usada para acessar vários serviços online; por exemplo, Microsoft Power Platform, Dynamics 365, Microsoft 365 e Azure.
Diagrama mostrando uma conexão ExpressRoute compartilhada com Microsoft serviços públicos e Azure. Microsoft O peering para Microsoft 365, Microsoft Power Platform, Dynamics 365 e serviços públicos do Azure estão compartilhando a mesma conexão ExpressRoute com o peering privado do Azure para redes virtuais.
O ExpressRoute em si não separa diferentes tipos de serviços de uma sub-rede específica. Microsoft É possível usar tags de comunidade BGP para controlar o roteamento de tráfego para serviços específicos no ExpressRoute. Microsoft não roteia o tráfego de volta pelo ExpressRoute seletivamente com base nas tags da comunidade BGP. Se o tráfego precisar ser retornado de forma diferente com base no tipo de serviço, certifique-se de que o tráfego venha de diferentes endereços IP públicos. Como qualquer tráfego que retorna a uma sub-rede será tratado no nível da rede, seria perigoso configurar apenas algum tráfego de uma sub-rede para usar o ExpressRoute, porque isso pode levar ao roteamento assimétrico.