Nätverksalternativ för Foundry Agent Service

Microsoft Foundry Agent Service har stöd för flera nätverksalternativ, från en helt offentlig konfiguration för snabba prototyper till fullständig nätverksisolering i ditt eget virtuella nätverk. Den här artikeln jämför alternativen, mappar var och en till vanliga mål och pekar på distributionsmallen och konfigurationsguiden för det alternativ du väljer.

När du har valt ett alternativ följer du den länkade instruktionen för att distribuera det och verifierar sedan distributionen. Om du stöter på problem använder du den länkade felsökningsguiden.

Standardbeteende för nätverk

När du skapar en Foundry-resurs utan någon nätverkskonfiguration får du en helt offentlig baslinje:

• Inkommande: Foundry-slutpunkten kan nås via det offentliga Internet. Alla anropare med en giltig autentiseringsuppgift och slutpunkts-URL:en kan nå den.
• Utgående: agenter når dina data och Azure resurser via offentliga nätverk och kan bara nå internettillgängliga slutpunkter.
• Lagring: agenttillstånd använder Microsoft-hanterad lagring som standard. Om du tar med din egen lagring och andra Azure resurser konfigurerar du nätverksåtkomst till dessa resurser som en del av nätverkskonfigurationen.

Ingenting är privat förrän du väljer något av alternativen i nästa avsnitt. Varje alternativ ändrar den inkommande sidan, den utgående sidan eller båda.

Nätverksalternativ

En nätverkskonfiguration kombinerar två relaterade beslut:

• Utgående (utgående) åtkomst: hur dina agenter når dina data och andra Azure resurser. Det här beslutet avgör den huvudsakliga isoleringen: håll utgående offentlig eller begränsa den till ett virtuellt nätverk så att trafiken stannar i ditt privata nätverk. Det virtuella nätverket kan vara ett som du tar med och hanterar (byo-virtuellt nätverk) eller en Microsoft hanterar åt dig.
• Inkommande åtkomst: vilka nätverk som kan nå din Foundry-slutpunkt. Antingen offentligt (eventuellt begränsat till valda IP-adresser) eller privat via en privat slutpunkt.

De två besluten är sammankopplade. När du isolerar utgående trafik i ett virtuellt nätverk går ingående åtkomst till Foundry-slutpunkten också via en privat slutpunkt, eftersom resurserna i det virtuella nätverket når slutpunkten över det privata nätverket. Börja med utgående modell eftersom det valet avgör isolering och de inkommande alternativ som är tillgängliga för dig. I följande tabell visas de tre utgående modellerna och de inkommande alternativen som är tillgängliga för var och en.

Med publik utgående trafik skyddar en privat slutpunkt endast den inkommande trafiken: anropande klienter når Foundry-slutpunkten privat, men agentens utgående trafik är inte isolerad.

Med det virtuella BYO-nätverket kan du ta med dina egna dataresurser eller använda plattformshanterade dataresurser. Mer information finns i Bring-your-own virtual network requirements.

Nätverksalternativ efter scenario

I följande tabell mappas gemensamma mål till ett rekommenderat alternativ och en distributionsmall. Infrastruktur-som-kod-mallarna finns i Foundry samples infrastructure setup repository (Bicep, med en Terraform-spegel).

För hela mallkatalogen och vad varje mall tillhandahåller, se README-filen för infrastrukturkonfigurationen.

Krav för eget virtuellt nätverk

Både det virtuella BYO-nätverket och det hanterade virtuella nätverket ger fullständig isolering. Skillnaden är vem som kör nätverket: med hanterat virtuellt nätverk hanterar Microsoft kraven i det här avsnittet åt dig. Välj ett virtuellt BYO-nätverk när du vill ha fullständig kontroll över ett nätverk som du redan hanterar – dina egna IP-intervall, brandvägg, peering och routning.

När du väljer virtuellt BYO-nätverk planerar du för dessa krav innan du distribuerar. Installationsguiden och djupdykningen täcker dem i sin helhet.

• Ett dedikerat delegerat undernät. Delegera ett undernät till Microsoft.App/environments. Undernätet kan inte delas av mer än en Foundry-resurs. Dimensionera det utifrån den skala du förväntar dig; Se Planera storleken på undernätet.
• Endast adressutrymme enligt RFC 1918. Använd 10.0.0.0/8, 172.16.0.0/12eller 192.168.0.0/16. Offentliga intervall och CGNAT-intervall stöds inte. Klass A-intervall (10.x) är endast tillgängliga i vissa regioner.
• Ditt val av dataresurser. Med det virtuella BYO-nätverket väljer du hur agentdataresurser (Azure Storage, Azure AI-sökning och Azure Cosmos DB) tillhandahålls:
  • Plattformshanterade dataresurser. Använd multitenanta, plattformshanterade dataresurser så att du inte tar med eller konfigurerar dina egna. Välj det här alternativet när dina agenter inte behöver kundhanterade dataresurser, till exempel många scenarier med värdbaserad agent, eller när du vill undvika kapacitetsplanering för resurser som Azure Cosmos DB. Det här alternativet tar bort behovet av att konfigurera dataresurser som du inte använder.
  • Ta med dina egna dataresurser. Använd dina egna Azure Storage, Azure AI-sökning och Azure Cosmos DB så att alla agentdata finns kvar i klientorganisationen. Välj det här alternativet när du behöver agentdata i resurser som du äger och hanterar.
• Privata slutpunkter och privata DNS-zoner för Foundry-kontot och för varje dataresurs som du tar in, så att namnuppslagningen stannar inom det virtuella nätverket.
• Samma region för Foundry-resursen och det virtuella nätverket. Andra resurser kan finnas i olika regioner, med kostnadskonsekvenser mellan regioner.

Ett topologidiagram över alternativet virtuellt BYO-nätverk – det delegerade undernätet, virtuella mikrodatorer med värdbaserad agent och privata slutpunkter till dina dataresurser – finns i Djupdykning i Foundry Agent Service-nätverk.

Verktygsstöd med nätverksisolering

Alla agentverktyg stöder inte nätverksisolering. Vissa verktyg stöds inte bakom ett virtuellt nätverk och vissa når sitt mål via det offentliga Internet i stället för ditt privata nätverk. Innan du genomför en isolerad installation kontrollerar du Agentverktyg med nätverksisolering för att bekräfta att de verktyg som dina agenter använder stöds.

Planera storleken på undernätet

Undernätet måste vara minst /27 och du kan inte ändra dess storlek när du har tilldelat det, så ändra storlek på det för den skalning du förväntar dig. Alla projekt i Foundry-kontot delar undernätet, så planera för den kombinerade användningen av varje projekt, agent och samtidig session i kontot. Azure reserverar fem IP-adresser i varje undernät för internt bruk.

• Värdagenter körs på en dedikerad mikro-VM med ett eget nätverksgränssnitt, så varje agent använder en IP-adress från undernätet. IP-användning skalar med antalet projekt, värdbaserade agenter i varje projekt och deras samtidiga sessioner. Nya revisioner använder även IP-adresser tillfälligt under distributionen, när gamla och nya revisioner körs parallellt.
• Prompt-agenter förbrukar ingen IP-adress per revision. De använder en liten, statisk pool med IP-adresser (upp till cirka 10 per projekt), oavsett hur många promptagenter eller revisioner du kör.

Information om IP-allokeringsmodellen, begränsningar för samtidiga sessioner och storleksberäkning finns i Djupdykning i Foundry Agent Service-nätverk.

Hostade agenter jämfört med promptagenter

Nätverksalternativet gäller för hela foundry-kontot, men de två agenttyperna använder nätverksresurser på olika sätt, enligt beskrivningen i Planera din undernätsstorlek. Båda typerna når dina resurser via privata slutpunkter i ditt virtuella nätverk.

Nästa steg

1. Distribuera alternativet med installationsguiden eller mallen från tabellen.
2. Verifiera distributionen: bekräfta delegering av undernät, att offentlig åtkomst är inaktiverad och att slutpunkterna matchar privata IP-adresser inifrån det virtuella nätverket. Se till Verifiera distributionen.
3. Felsöka eventuella distributions- eller anslutningsfel med felsökningsguiden.

Relaterat innehåll

• Konfigurera privata nätverk för Foundry Agent Service
• Djupdykning i Foundry Agent Service-nätverk
• Konfigurera hanterat virtuellt nätverk
• Konfigurera nätverksisolering