Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Microsoft Foundry Agent Service suporta várias opções de rede, desde uma configuração totalmente pública para prototipagem rápida até isolamento completo da rede dentro da sua própria rede virtual. Este artigo compara as opções, mapeia cada uma com objetivos comuns e encaminha-o para o modelo de implementação e o guia de configuração da opção que escolher.
Depois de escolheres uma opção, segue o tutorial ligado para a implementar e depois valida a implementação. Se encontrares problemas, usa as orientações de resolução de problemas associadas.
Comportamento de rede predefinido
Quando crias um recurso Foundry sem qualquer configuração de rede, obténs uma base totalmente pública:
- Inbound: o endpoint da Foundry é acessível através da internet pública. Qualquer chamador com uma credencial válida e a URL do endpoint pode aceder a ela.
- Outbound: os agentes acedem aos seus dados e recursos do Azure através de redes públicas, podendo aceder apenas a endpoints acessíveis pela internet.
- Armazenamento: o estado do agente utiliza armazenamento gerido pela Microsoft por defeito. Se trouxer o seu próprio armazenamento e outros recursos do Azure, configura o acesso à rede a esses recursos como parte da sua configuração de rede.
Nada é privado até escolheres uma das opções na secção seguinte. Cada opção altera o lado de entrada, de saída, ou ambos.
Opções de rede
Uma configuração de rede combina duas decisões relacionadas:
- Acesso de saída: como os seus agentes acedem aos seus dados e a outros recursos do Azure. Esta decisão determina o principal isolamento: manter a saída pública ou confiná-la a uma rede virtual para que o tráfego permaneça na sua rede privada. A rede virtual pode ser uma que você traz e gere (rede virtual BYO) ou uma que a Microsoft gere por si.
- Acesso de entrada: quais as redes que podem aceder ao seu ponto final do Foundry. Ou público (opcionalmente restrito a endereços IP selecionados) ou privado através de um endpoint privado.
As duas decisões estão ligadas. Quando isolas a saída numa rede virtual, o acesso de entrada ao endpoint Foundry também passa por um endpoint privado, porque os recursos nessa rede virtual chegam ao endpoint através da rede privada. Começa pelo modelo de saída, porque essa escolha determina o isolamento e as opções de entrada disponíveis para ti. A tabela seguinte mostra os três modelos de saída e as opções de entrada disponíveis em cada um.
| Modelo de saída | Opções de entrada | Melhor para |
|---|---|---|
| Saída pública | Público (endereços IP selecionados opcionalmente), ou um endpoint privado na sua rede virtual | Sem isolamento de saída. Utilize o acesso de entrada público para prototipagem e testes, ou um endpoint privado para restringir quem pode chamar, enquanto o tráfego de saída permanece público. |
| Rede virtual BYO | Endpoint privado na sua rede virtual | Isolamento total onde controlas os intervalos de IP, peering e roteamento. Os agentes são inseridos numa sub-rede que delegas e geres. |
| Rede virtual gerenciada | Endpoint privado na sua rede virtual | Isolamento total sem gerir intervalos de IP, ou quando o teu espaço de IP se sobrepõe. Os agentes funcionam numa rede virtual gerida pela Microsoft. |
Com egresso público, adicionar um ponto final privado protege apenas o tráfego de entrada: os clientes chegam ao ponto final do Foundry em privado, mas o tráfego de saída do agente não fica isolado.
Com a rede virtual BYO, pode trazer os seus próprios recursos de dados ou utilizar recursos de dados geridos pela plataforma. Para mais informações, consulte Requisitos para a sua própria rede virtual.
Note
O isolamento de rede aplica-se ao nível da conta Foundry e do projeto. Abrange agentes alojados, agentes de prompt e os restantes recursos da Foundry existentes na conta. Os dois tipos de agentes consomem recursos de rede de forma diferente dentro de uma configuração isolada. Para obter mais detalhes, consulte Análise aprofundada da rede do Foundry Agent Service.
Opções de rede por cenário
A tabela seguinte associa objetivos comuns a uma opção recomendada e a um modelo de implementação. Os templates de infraestrutura como código estão no repositório de configuração da infraestrutura dos exemplos do Foundry (Bicep, com uma versão equivalente em Terraform).
| O teu objetivo | Opção recomendada | Implementar com |
|---|---|---|
| O caminho mais rápido para obter um agente funcional, sem isolamento | Armazenamento público, gerido pela Microsoft | Implemente o seu primeiro quickstart de agente alojado (Azure Developer CLI ou VS Code) |
| Mantém os dados do agente nos teus próprios recursos do Azure, sem isolamento | Público, armazenamento próprio (padrão) | 41-standard-agent-setup |
| Restringe quem pode chamar o endpoint, a saída pública é aceitável | Saída pública com um ponto final privado | 10-private-network-basic |
| Isolamento total sem saída pública, controla a rede e quer trazer os seus próprios recursos de dados | Rede virtual BYO com recursos de dados de trazer os seus próprios dados (padrão seguro em rede) | 15-private-network-standard-agent-setup |
| Isolamento total sem saída pública, controlas a rede mas não queres gerir os recursos de dados | Rede virtual BYO com recursos de dados geridos pela plataforma | 11-private-network-basic-vnet |
| Isolamento total, mas não consegues gerir intervalos de IP nem sobreposições de espaço de IP | Rede virtual gerenciada | 18-managed-virtual-network |
| Isolamento total por trás de um gateway de API | BYO virtual network com API Management do Azure | 16-private-network-standard-agent-apim-setup |
| Aceder aos recursos locais dos agentes | Rede virtual BYO mais VPN ou ExpressRoute |
15-private-network-standard-agent-setup mais Aceder a recursos no local |
Para o catálogo completo de modelos e o que cada um prevê, consulte o README de configuração de infraestrutura.
Requisitos para trazer a sua própria rede virtual
Tanto a rede virtual BYO como a rede virtual gerida proporcionam isolamento total. A diferença está em quem gere a rede: com rede virtual gerida, a Microsoft trata dos requisitos desta secção por si. Escolha a rede virtual BYO quando quiser ter controlo total sobre uma rede que já gere – os seus próprios intervalos de IP, firewall, peering e encaminhamento.
Ao escolher a rede virtual BYO, planeie estes requisitos antes de implementar. O guia de configuração e a análise aprofundada abordam-nos exaustivamente.
- Uma sub-rede dedicada e delegada. Delegar uma sub-rede a
Microsoft.App/environments. A sub-rede não pode ser partilhada por mais do que um recurso da Foundry. Ajusta o tamanho à escala que esperas; ver Planeie o tamanho da sua sub-rede. - Apenas espaço de endereços RFC 1918. Use
10.0.0.0/8,172.16.0.0/12, ou192.168.0.0/16. Os intervalos públicos e de CGNAT não são suportados. As gamas Classe A (10.x) só estão disponíveis em certas regiões. - A sua escolha de recursos de dados. Com a rede virtual BYO, escolhe como os recursos de dados dos agentes (Armazenamento do Azure, Pesquisa de IA do Azure e Azure Cosmos DB) são fornecidos:
- Recursos de dados geridos pela plataforma. Use recursos de dados multitenant e geridos pela plataforma para não trazer ou configurar os seus próprios. Escolha esta opção quando os seus agentes não precisarem de recursos de dados geridos pelo cliente—por exemplo, muitos cenários de agentes alojados—ou quando quiser evitar o planeamento de capacidade para recursos como o Azure Cosmos DB. Esta opção elimina a necessidade de configurar recursos de dados que não utiliza.
- Traga os seus próprios recursos de dados. Use o seu próprio Armazenamento do Azure, Pesquisa de IA do Azure e Azure Cosmos DB para que todos os dados do agente fiquem no seu tenant. Escolha esta opção quando precisar de dados de agentes em recursos que possui e gere.
- Pontos finais privados e zonas DNS privadas para a conta do Foundry e para cada recurso de dados que adicionar, para 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 diferentes regiões, com implicações de custo entre regiões.
Importante
Defina a configuração da rede virtual quando cria a conta 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 da rede entra em vigor quando crias o primeiro agente alojado, e não podes alterar a injeção de rede depois. Para mudar para uma configuração de rede diferente, crie novos projetos. A configuração aplica-se ao nível da conta, pelo que abrange tanto os agentes alojados como os agentes de prompt. Decida sobre uma rede virtual BYO antes de criar a conta.
Para obter um diagrama de topologia da opção de rede virtual BYO — a sub-rede delegada, as Micro VMs de agente alojado e os pontos finais privados para os seus recursos de dados — consulte Análise aprofundada da rede do Foundry Agent Service.
Suporte de ferramentas com isolamento de rede
Nem todas as ferramentas de agentes suportam isolamento de rede. Algumas ferramentas não são suportadas por uma rede virtual, e outras chegam ao seu destino através da internet pública em vez da sua rede privada. Antes de te comprometeres com uma configuração isolada, verifica as ferramentas do Agente com isolamento de rede para confirmar que as ferramentas que os teus agentes usam são suportadas.
Planeie o tamanho da sua sub-rede
A sub-rede deve ter pelo menos /27, e não podes alterar o seu tamanho depois de a atribuir, por isso dimensiona-a para a escala que esperas. Todos os projetos na conta Foundry partilham a sub-rede, por isso planeie o uso combinado de cada projeto, agente e sessão simultânea na conta. O Azure reserva cinco endereços IP em cada sub-rede para uso interno.
- Os agentes alojados correm numa Micro VM dedicada com a sua própria interface de rede, pelo que cada um consome um endereço IP da subrede. O uso do IP escala com o número de projetos, os agentes alojados em cada projeto e as suas sessões simultâneas. Novas revisões também consomem temporariamente endereços IP durante a implementação, quando as versões antigas e novas são executadas em paralelo.
- Os agentes de prompt não consomem um endereço IP por revisão. Utilizam um pequeno conjunto estático de endereços IP (até cerca de 10 por projeto), independentemente da quantidade de agentes de prompt ou revisões que utilize.
| Tamanho da sub-rede | Recommendation |
|---|---|
| /24 | Recomendado para produção com agentes alojados. Deixa margem para escalar agentes hospedados entre projetos, suportar sessões simultâneas e absorver atualizações no mesmo local. |
| /27 | Mínimo suportado. Funciona para produção quando executas prompt agents, ou para implementações hosted-agent mais pequenas. Deixa menos margem para escalar agentes alojados e sessões simultâneas. |
Para o modelo de alocação de IP, limites de sessões concorrentes e cálculos de dimensionamento, veja Deep dive into Foundry Agent Service networking.
Agentes hospedados vs. agentes baseados em prompts
A opção de rede aplica-se a toda a sua conta Foundry, mas os dois tipos de agentes consomem recursos de rede de forma diferente, como descrito em Planeie o tamanho da sua sub-rede. Ambos os tipos chegam aos seus recursos através de endpoints privados na sua rede virtual.
Passos seguintes
- Implementa a opção com o tutorial de configuração ou o modelo da tabela.
- Valide a implementação: confirme a delegação da subrede, que o acesso público está desativado e que os endpoints resolvem para endereços IP privados a partir da rede virtual. Consulte Verificar a implantação.
- Resolva quaisquer erros de implementação ou conectividade com o guia de resolução de problemas.