Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O Serviço de Agente do Microsoft Foundry oferece suporte a várias opções de rede, desde uma configuração totalmente pública para prototipagem rápida até o isolamento completo da rede dentro da sua própria rede virtual. Este artigo compara as opções, mapeia cada uma para metas comuns e aponta para o modelo de implantação e o guia de configuração para a opção escolhida.
Depois de escolher uma opção, siga as instruções vinculadas para implantá-la e valide a implantação. Se você tiver problemas, use as diretrizes de solução de problemas vinculadas.
Comportamento de rede padrão
Ao criar um recurso do Foundry sem qualquer configuração de rede, você obtém uma linha de base totalmente pública:
- Entrada: o ponto de extremidade do Foundry é acessível pela internet pública. Qualquer chamador com uma credencial válida e a URL do endpoint pode acessá-lo.
- Saída: os agentes acessam seus dados e recursos do Azure por meio da rede pública e podem acessar apenas terminais acessíveis pela Internet.
- Armazenamento: o estado do agente usa o armazenamento gerenciado por Microsoft por padrão. Se você trouxer seu próprio armazenamento e outros recursos Azure, configure o acesso à rede para esses recursos como parte da configuração de rede.
Nada é privado até você escolher uma das opções na próxima seção. Cada opção altera o lado de entrada, o lado de saída ou ambos.
Opções de rede
Uma configuração de rede combina duas decisões relacionadas:
- Acesso de saída (saída): como seus agentes alcançam seus dados e outros recursos de Azure. Essa decisão determina o isolamento principal: manter a saída pública ou confiná-la a uma rede virtual para que o tráfego permaneça em sua rede privada. A rede virtual pode ser aquela que você traz e gerencia (rede virtual BYO) ou uma Microsoft gerencia para você.
- Acesso de entrada: quais redes podem acessar seu endpoint do Foundry. Público (opcionalmente restrito a endereços IP selecionados) ou privado por meio de um ponto de extremidade privado.
As duas decisões estão conectadas. Quando você isola o tráfego de saída em uma rede virtual, o acesso de entrada ao endpoint do Foundry também ocorre por meio de um endpoint privado, porque os recursos dessa rede virtual acessam o endpoint pela rede privada. Comece com o modelo de saída, pois essa opção determina o isolamento e as opções de entrada disponíveis para você. A tabela a seguir mostra os três modelos de saída e as opções de entrada disponíveis com cada um.
| Modelo de saída | Opções de entrada | Mais adequado para |
|---|---|---|
| Saída pública | Público (com endereços IP selecionados opcionalmente) ou endpoint privado em sua rede virtual | Sem isolamento de saída. Use acesso de entrada público para prototipagem e testes ou um ponto de extremidade privado para restringir quem pode chamar, enquanto o tráfego de saída permanece público. |
| Rede virtual BYO | Ponto de extremidade privado em sua rede virtual | Isolamento total em que você controla intervalos de IP, emparelhamento e roteiros. Os agentes são injetados em uma sub-rede que você delega e gerencia. |
| Rede virtual gerenciada | Ponto de extremidade privado em sua rede virtual | Isolamento completo sem gerenciar faixas de IP ou quando há sobreposição no seu espaço de IP. Os agentes são executados em uma rede virtual gerenciada por Microsoft. |
Com saída público, adicionar um ponto de extremidade privado protege apenas o caminho de entrada: os clientes acessam o ponto de extremidade do Foundry de forma privada, mas a saída do agente não é isolada.
Com a rede virtual BYO, você pode trazer seus próprios recursos de dados ou usar recursos de dados gerenciados pela plataforma. Para obter mais informações, consulte Requisitos para rede virtual própria.
Note
O isolamento de rede se aplica no nível da conta e do projeto do Foundry. Ele abrange agentes hospedados, agentes de prompt e os outros recursos do Foundry na conta. Os dois tipos de agente consomem recursos de rede de forma diferente dentro de uma configuração isolada. Para obter detalhes, consulte Análise aprofundada da rede do Foundry Agent Service.
Opções de rede por cenário
A tabela a seguir mapeia metas comuns para uma opção recomendada e um modelo de implantação. Os modelos de infraestrutura como código estão no repositório de configuração de infraestrutura de exemplos do Foundry (Bicep, com um mirror do Terraform).
| Sua meta | Opção recomendada | Implantar com o |
|---|---|---|
| O caminho mais rápido para um agente funcional, sem isolamento | Armazenamento público, gerenciado pela Microsoft | Implantar seu primeiro início rápido do agente hospedado (CLI do desenvolvedor Azure ou VS Code) |
| Mantenha os dados do agente nos seus próprios recursos do Azure, sem isolamento | Público, armazenamento próprio (padrão) | 41-standard-agent-setup |
| Restringir quem pode chamar o ponto de extremidade, a saída pública é aceitável | Saída pública com ponto de extremidade privado | 10-private-network-basic |
| Isolamento total sem saída pública, você controla a rede e deseja trazer seus próprios recursos de dados | Rede virtual BYO com recursos de dados fornecidos pelo cliente (padrão com segurança de rede) | 15-private-network-standard-agent-setup |
| Isolamento total sem saída pública, você controla a rede, mas não deseja gerenciar recursos de dados | Rede virtual BYO com recursos de dados gerenciados pela plataforma | 11-private-network-basic-vnet |
| Isolamento total, mas você não pode gerenciar intervalos de IP ou sobreposições de espaço IP | Rede virtual gerenciada | 18-managed-virtual-network |
| Isolamento total por trás de um gateway de API | Rede virtual BYO com Gerenciamento de API do Azure | 16-private-network-standard-agent-apim-setup |
| Acessar recursos locais de agentes | Rede virtual BYO mais VPN ou ExpressRoute |
15-private-network-standard-agent-setup mais Acessar recursos locais |
Para o catálogo completo de modelos e o que cada um provisiona, consulte a configuração de infraestrutura README.
Requisitos para rede virtual própria
A rede virtual BYO e a rede virtual gerenciada fornecem isolamento total. A diferença é quem executa a rede: com a rede virtual gerenciada, Microsoft lida com os requisitos nesta seção para você. Escolha a rede virtual BYO quando quiser o controle total de uma rede que você já gerencia - seus próprios intervalos de IP, firewall, emparelhamento e roteamento.
Ao escolher a rede virtual BYO, planeje esses requisitos antes de implantar. O guia de configuração e a análise aprofundada abordam esses tópicos em detalhes.
- Uma sub-rede dedicada e delegada. Delegar uma sub-rede para
Microsoft.App/environments. A sub-rede não pode ser compartilhada por mais de um recurso do Foundry. Dimensione-o para a escala prevista; consulte Planeje o tamanho da sua sub-rede. - Somente espaço de endereço RFC 1918. Use
10.0.0.0/8,172.16.0.0/12, ou192.168.0.0/16. Não há suporte para intervalos públicos e CGNAT. Os intervalos de classe A (10.x) só estão disponíveis em determinadas regiões. - Sua escolha de recursos de dados. Com a rede virtual BYO, você escolhe como os recursos de dados do agente (Armazenamento do Azure, Pesquisa de IA do Azure e Azure Cosmos DB) são fornecidos:
- Recursos de dados gerenciados pela plataforma. Use recursos de dados multilocatários gerenciados pela plataforma para que você não traga ou configure seus próprios recursos. Escolha essa opção quando seus agentes não precisarem de recursos de dados gerenciados pelo cliente , por exemplo, muitos cenários de agente hospedado ou quando você quiser evitar o planejamento de capacidade para recursos como Azure Cosmos DB. Essa opção remove a necessidade de configurar recursos de dados que você não usa.
- Traga seus próprios recursos de dados. Utilize suas próprias instâncias do Armazenamento do Azure, Pesquisa de IA do Azure e Azure Cosmos DB para manter todos os dados do agente no seu locatário. Escolha essa opção quando precisar de dados do agente em recursos que você possui e gerencie.
- Pontos de extremidade privados e zonas de DNS Privado para a conta do Foundry e para cada recurso de dados fornecido por você, garantindo que a resolução de nomes permaneça dentro da rede virtual.
- Mesma região para o recurso Foundry e a rede virtual. Outros recursos podem estar em regiões diferentes, com implicações de custo entre regiões.
Importante
Defina a configuração de rede virtual ao criar a conta do Foundry. A injeção de rede faz parte do fluxo de criação de recursos e não pode ser adicionada a uma conta existente. A configuração de rede entra em vigor quando você cria o primeiro agente hospedado e não pode alterar a injeção de rede posteriormente. Para mover para uma configuração de rede diferente, crie novos projetos. A configuração se aplica ao nível da conta, portanto, abrange tanto os agentes hospedados quanto os agentes de prompt. Escolha uma rede virtual BYO antes de criar a conta.
Para ver um diagrama de topologia da opção de rede virtual própria (BYO), como a sub-rede delegada, as Micro VMs de agente hospedado e os pontos de extremidade privados para seus recursos de dados, consulte Análise detalhada da rede do Serviço de Agente do Foundry.
Suporte para ferramentas com isolamento de rede
Nem todas as ferramentas de agente dão suporte ao isolamento de rede. Algumas ferramentas não têm suporte por trás de uma rede virtual e outras chegam ao destino pela Internet pública, em vez da rede privada. Antes de se comprometer com uma configuração isolada, verifique as ferramentas do Agente com isolamento de rede para confirmar se há suporte para as ferramentas que seus agentes usam.
Planejar o tamanho da sub-rede
A sub-rede deve ser pelo menos /27 e você não pode alterar seu tamanho depois de atribuí-la, portanto, dimensione-a para a escala esperada. Todos os projetos na conta do Foundry compartilham a sub-rede, portanto, planeje o uso combinado de cada projeto, agente e sessão simultânea na conta. Azure reserva cinco endereços IP em cada sub-rede para uso interno.
- Os agentes hospedados são executados em uma Micro VM dedicada com sua própria interface de rede, portanto, cada um consome um endereço IP da sub-rede. O uso de IP é dimensionado com o número de projetos, os agentes hospedados em cada projeto e suas sessões simultâneas. As novas revisões também consomem endereços IP temporariamente durante a distribuição, quando as revisões antigas e novas são executadas em paralelo.
- Os agentes de comando não consomem um endereço IP a cada revisão. Eles usam um pequeno pool estático de endereços IP (até cerca de 10 por projeto), independentemente de quantos agentes de prompt ou revisões você executar.
| Tamanho da sub-rede | Recommendation |
|---|---|
| /24 | Recomendado para produção com agentes hospedados. Deixa espaço para dimensionar agentes hospedados em projetos, dar suporte a sessões simultâneas e absorver atualizações in-loco. |
| /27 | Mínimo suportado. Funciona para produção quando você executa agentes de prompt ou para implantações menores de agente hospedado. Deixa menos espaço para dimensionar agentes hospedados e sessões simultâneas. |
Para o modelo de alocação de IP, os limites de sessões simultâneas e os cálculos de dimensionamento, consulte Análise aprofundada da rede do Serviço Foundry Agent.
Agentes hospedados versus agentes de prompt
A opção de rede se aplica a toda a sua conta do Foundry, mas os dois tipos de agente consomem recursos de rede de forma diferente, conforme descrito em Planejar o tamanho da sub-rede. Ambos os tipos acessam seus recursos via endpoints privados em sua rede virtual.
Próximas Etapas
- Implante a opção com o guia de configuração ou o modelo na tabela.
- Valide a implantação: confirme a delegação da sub-rede, que o acesso público esteja desabilitado e que os endpoints resolvam para endereços IP privados de dentro da rede virtual. Confira Verificar a implantação.
- Solucione problemas de implantação ou erros de conectividade com o guia de solução de problemas.