Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Microsoft Foundry Agent Service unterstützt mehrere Netzwerkoptionen, von einer vollständig öffentlichen Einrichtung für schnelle Prototyperstellung bis hin zur vollständigen Netzwerkisolation innerhalb Ihres eigenen virtuellen Netzwerks. In diesem Artikel werden die Optionen verglichen, die einzelnen den gemeinsamen Zielen zugeordnet, und Sie werden auf die Bereitstellungsvorlage und den Konfigurationsleitfaden für die von Ihnen ausgewählte Option verweist.
Nachdem Sie eine Option ausgewählt haben, folgen Sie der verknüpften Vorgehensweise, um sie bereitzustellen, und überprüfen Sie dann die Bereitstellung. Wenn Sie Probleme haben, verwenden Sie die verknüpften Anleitungen zur Problembehandlung.
Standardmäßiges Netzwerkverhalten
Wenn Sie eine Foundry-Ressource ohne Netzwerkkonfiguration erstellen, erhalten Sie einen vollständigen öffentlichen Basisplan:
- Eingehend: Der Foundry-Endpunkt ist über das öffentliche Internet erreichbar. Jeder Aufrufer mit gültigen Anmeldeinformationen und der Endpunkt-URL kann ihn erreichen.
- Ausgehend: Agenten greifen über öffentliche Netzwerke auf Ihre Daten und Azure-Ressourcen zu und können nur über das Internet zugängliche Endpunkte erreichen.
- Speicher: Der Agentstatus verwendet standardmäßig Microsoft verwalteten Speicher. Wenn Sie Ihren eigenen Speicher und andere Azure Ressourcen mitbringen, konfigurieren Sie den Netzwerkzugriff auf diese Ressourcen als Teil Ihrer Netzwerkeinrichtung.
Nichts ist privat, bis Sie eine der Optionen im nächsten Abschnitt auswählen. Jede Option ändert die eingehende Seite, die ausgehende Seite oder beides.
Netzwerkoptionen
Eine Netzwerkkonfiguration kombiniert zwei verwandte Entscheidungen:
- Ausgehender Zugriff (Ausgang): Wie Ihre Agents Ihre Daten und andere Azure Ressourcen erreichen. Diese Entscheidung bestimmt die Hauptisolation: Halten Sie den Ausgang öffentlich, oder beschränken Sie sie auf ein virtuelles Netzwerk, damit Datenverkehr in Ihrem privaten Netzwerk bleibt. Das virtuelle Netzwerk kann ein netzwerk sein, das Sie mitbringen und verwalten (BYO virtual network) oder ein Microsoft für Sie verwaltet.
- Eingehender Zugriff: welche Netzwerke Ihren Foundry-Endpunkt erreichen können. Entweder öffentlich (optional auf ausgewählte IP-Adressen beschränkt) oder privat über einen privaten Endpunkt.
Die beiden Entscheidungen sind miteinander verbunden. Wenn Sie den Ausgang in einem virtuellen Netzwerk isolieren, durchläuft der eingehende Zugriff auf den Foundry-Endpunkt auch einen privaten Endpunkt, da die Ressourcen in diesem virtuellen Netzwerk den Endpunkt über das private Netzwerk erreichen. Beginnen Sie mit dem Egress-Modell, denn diese Entscheidung bestimmt den Isolationsgrad und die Ihnen zur Verfügung stehenden Optionen für eingehenden Datenverkehr. In der folgenden Tabelle sind die drei Ausgangsmodelle und die jeweils verfügbaren eingehenden Auswahlmöglichkeiten aufgeführt.
| Ausgangsmodell | Eingehende Optionen | Am besten geeignet für: |
|---|---|---|
| Öffentlicher Ausgang | Öffentliche (optional ausgewählte IP-Adressen) oder ein privater Endpunkt in Ihrem virtuellen Netzwerk | Keine Ausgangsisolation. Verwenden Sie für Prototypen und Tests öffentlichen eingehenden Zugriff oder einen privaten Endpunkt, um Aufrufer einzuschränken, während der ausgehende Datenverkehr öffentlich bleibt. |
| VIRTUELLE BYO-Netzwerke | Privater Endpunkt in Ihrem virtuellen Netzwerk | Vollständige Isolation, bei der Sie IP-Bereiche, Peering und Routing steuern. Agents werden in ein Subnetz eingefügt, das Sie delegieren und verwalten. |
| Verwaltetes virtuelles Netzwerk | Privater Endpunkt in Ihrem virtuellen Netzwerk | Vollständige Isolation ohne Verwaltung von IP-Bereichen oder wenn sich Ihr IP-Speicherplatz überlappt. Agents werden in einem Microsoft verwalteten virtuellen Netzwerk ausgeführt. |
Wenn öffentlicher Egress aktiviert ist, sichert das Hinzufügen eines privaten Endpunkts nur den eingehenden Datenverkehr: Aufrufer erreichen den Foundry-Endpunkt privat, aber der ausgehende Datenverkehr des Agents ist nicht isoliert.
Mit BYO virtual network können Sie Eigene Datenressourcen mitbringen oder plattformverwaltete Datenressourcen verwenden. Weitere Informationen finden Sie unter Anforderungen für eigene virtuelle Netzwerke.
Note
Die Netzwerkisolation gilt auf Der Ebene des Foundry-Kontos und des Projekts. Es umfasst gehostete Agenten, Prompt-Agenten und die anderen Foundry-Ressourcen im Konto. Die beiden Agenttypen verbrauchen Netzwerkressourcen innerhalb eines isolierten Setups unterschiedlich. Ausführliche Informationen finden Sie unter Deep Dive into Foundry Agent Service Networking.
Netzwerkoptionen nach Szenario
Die folgende Tabelle ordnet allgemeine Ziele einer empfohlenen Option und einer Bereitstellungsvorlage zu. Die Infrastructure-as-Code-Vorlagen befinden sich im Infrastruktur-Setup-Repository für Foundry-Beispiele (Bicep mit einem Terraform-Spiegel).
| Ihr Ziel | Empfohlene Option | Bereitstellen mit |
|---|---|---|
| Schnellster Weg zu einem funktionsfähigen Agenten, ohne Isolation | Öffentlicher, Microsoft verwalteter Speicher | Schnellstart: Ihren ersten gehosteten Agent bereitstellen (Azure Developer CLI oder VS Code) |
| Behalten Sie Agent-Daten in Ihren eigenen Azure-Ressourcen, keine Isolierung | Öffentlich, kundeneigener Speicher (Standard) | 41-standard-agent-setup |
| Beschränken Sie, wer den Endpunkt aufrufen kann; öffentlicher ausgehender Datenverkehr ist zulässig. | Öffentlicher Ausgang mit einem privaten Endpunkt | 10-private-network-basic |
| Vollständige Isolation ohne öffentlichen Ausgang, Sie steuern das Netzwerk und möchten Ihre eigenen Datenressourcen mitbringen. | BYO virtuelles Netzwerk mit Datenressourcen vom Typ Bring Your Own (netzwerkgesicherter Standard) | 15-private-network-standard-agent-setup |
| Vollständige Isolation ohne öffentlichen Ausgang, Sie steuern das Netzwerk, möchten aber keine Datenressourcen verwalten. | BYO virtuelles Netzwerk mit plattformverwalteten Datenressourcen | 11-private-network-basic-vnet |
| Vollständige Isolation, aber Sie können keine IP-Bereiche verwalten oder sich Ihr IP-Adressraum überschneidet | Verwaltetes virtuelles Netzwerk | 18-managed-virtual-network |
| Vollständige Isolation hinter einem API-Gateway | Eigenes virtuelles Netzwerk mit Azure API Management | 16-private-network-standard-agent-apim-setup |
| Zugriff auf lokale Ressourcen über Agenten | BYO virtual network plus VPN oder ExpressRoute |
15-private-network-standard-agent-setup plus Auf lokale Ressourcen zugreifen |
Den vollständigen Vorlagenkatalog und die einzelnen Bestimmungen finden Sie im Infrastruktursetup README.
Anforderungen für eigene virtuelle Netzwerke
Sowohl BYO virtual network als auch verwaltetes virtuelles Netzwerk bieten vollständige Isolation. Der Unterschied besteht darin, wer das Netzwerk ausführt: Mit verwaltetem virtuellen Netzwerk übernimmt Microsoft die Anforderungen in diesem Abschnitt für Sie. Wählen Sie BYO virtual network aus, wenn Sie die vollständige Kontrolle über ein bereits verwaltetes Netzwerk wünschen – Ihre eigenen IP-Bereiche, Firewall, Peering und Routing.
Wenn Sie BYO virtual network auswählen, planen Sie diese Anforderungen, bevor Sie bereitstellen. Das Setup-How-to und der Deep Dive decken sie vollständig ab.
- Ein dediziertes, delegiertes Subnetz. Delegieren eines Subnetzes an
Microsoft.App/environments. Das Subnetz kann nicht von mehreren Foundry-Ressourcen gemeinsam genutzt werden. Wählen Sie die Größe entsprechend der erwarteten Skalierung; siehe Planen Sie Ihre Subnetzgröße. - Nur RFC 1918-Adressraum. Verwenden Sie
10.0.0.0/8,172.16.0.0/12oder192.168.0.0/16. Öffentliche und CGNAT-Bereiche werden nicht unterstützt. Bereiche der Klasse A (10.x) sind nur in bestimmten Regionen verfügbar. - Ihre Auswahl an Datenressourcen. Mit dem virtuellen BYO-Netzwerk wählen Sie aus, wie Agentdatenressourcen (Azure Storage, Azure KI-Suche und Azure Cosmos DB) bereitgestellt werden:
- Plattformverwaltete Datenressourcen. Verwenden Sie mehrinstanzenfähige, plattformverwaltete Datenressourcen, damit Sie ihre eigenen nicht mitbringen oder konfigurieren. Wählen Sie diese Option aus, wenn Ihre Agents keine vom Kunden verwalteten Datenressourcen benötigen, z. B. viele Szenarien mit gehosteten Agents oder wenn Sie die Kapazitätsplanung für Ressourcen wie Azure Cosmos DB vermeiden möchten. Mit dieser Option wird die Notwendigkeit entfernt, datenressourcen einzurichten, die Sie nicht verwenden.
- Eigene Datenressourcen. Verwenden Sie Ihre eigenen Azure Storage, Azure KI-Suche und Azure Cosmos DB, damit alle Agentdaten in Ihrem Mandanten verbleiben. Wählen Sie diese Option aus, wenn Sie Agentdaten in Ressourcen benötigen, die Sie besitzen und verwalten.
- Private Endpunkte und private DNS-Zonen für das Foundry-Konto und für jede Datenressource, die Sie einbringen, damit die Namensauflösung innerhalb des virtuellen Netzwerks bleibt.
- Dieselbe Region für die Foundry-Ressource und das virtuelle Netzwerk. Andere Ressourcen können sich in verschiedenen Regionen befinden, wobei sich die kostenübergreifenden Auswirkungen ergeben.
Important
Legen Sie die Konfiguration des virtuellen Netzwerks fest, wenn Sie das Foundry-Konto erstellen. Die Netzwerkeinfügung ist Teil des Create-Resource-Flusses und kann keinem vorhandenen Konto hinzugefügt werden. Die Netzwerkkonfiguration wird wirksam, wenn Sie den ersten gehosteten Agent erstellen und anschließend die Netzwerkeinfügung nicht mehr ändern können. Um zu einer anderen Netzwerkkonfiguration zu wechseln, erstellen Sie neue Projekte. Die Konfiguration gilt auf Kontoebene und umfasst somit sowohl gehostete als auch Prompt-Agents. Entscheiden Sie sich für ein virtuelles BYO-Netzwerk, bevor Sie das Konto erstellen.
Ein Topologiediagramm der OPTION BYO virtual network – das delegierte Subnetz, gehostete Agent Micro-VMs und private Endpunkte für Ihre Datenressourcen – finden Sie unter Deep Dive into Foundry Agent Service Networking.
Toolunterstützung mit Netzwerkisolation
Nicht alle Agenttools unterstützen die Netzwerkisolation. Einige Tools werden nicht hinter einem virtuellen Netzwerk unterstützt, und einige erreichen ihr Ziel über das öffentliche Internet und nicht über Ihr privates Netzwerk. Bevor Sie sich für ein isoliertes Setup verpflichten, überprüfen Sie die Agent-Tools mit Netzwerkisolation , um zu bestätigen, dass die von Ihren Agents verwendeten Tools unterstützt werden.
Planen der Subnetzgröße
Das Subnetz muss mindestens /27 sein, und Sie können seine Größe nach der Zuweisung nicht mehr ändern. Wählen Sie sie daher so, dass sie der erwarteten Größenordnung entspricht. Alle Projekte im Foundry-Konto teilen das Subnetz. Planen Sie also die kombinierte Nutzung jedes Projekts, Agents und gleichzeitiger Sitzung im Konto. Azure reserviert fünf IP-Adressen in jedem Subnetz für die interne Verwendung.
- Gehostete Agents werden in einer dedizierten Micro-VM mit einer eigenen Netzwerkschnittstelle ausgeführt, sodass jeder eine IP-Adresse aus dem Subnetz nutzt. Die IP-Verwendung wird mit der Anzahl der Projekte, den gehosteten Agents in jedem Projekt und ihren gleichzeitigen Sitzungen skaliert. Neue Überarbeitungen nutzen auch vorübergehend während des Rollouts IP-Adressen, wenn alte und neue Überarbeitungen parallel ausgeführt werden.
- Eingabeaufforderungs-Agents verbrauchen pro Revision keine IP-Adresse. Sie nutzen einen kleinen, statischen Pool von IP-Adressen (bis zu etwa 10 pro Projekt), unabhängig davon, wie viele Prompt-Agents oder Überarbeitungen Sie ausführen.
| Subnetzgröße | Recommendation |
|---|---|
| /24 | Empfohlen für die Produktion mit gehosteten Agents. Lässt ausreichend Spielraum, um gehostete Agenten projektübergreifend zu skalieren, gleichzeitige Sitzungen zu unterstützen und In-Place-Upgrades zu bewältigen. |
| /27 | Unterstützte Mindestwerte. Eignet sich für den Produktivbetrieb, wenn Sie Prompt-Agenten ausführen oder kleinere Bereitstellungen gehosteter Agenten nutzen. Lässt weniger Spielraum für die Skalierung gehosteter Agenten und gleichzeitiger Sitzungen. |
Informationen zum IP-Zuweisungsmodell, grenzwerte für gleichzeitige Sitzungen und zur Größenanpassung finden Sie unter Deep dive into Foundry Agent Service Networking.
Gehostete Agents im Vergleich zu Prompt-Agents
Die Netzwerkoption gilt für Ihr gesamtes Foundry-Konto, aber die beiden Agenttypen verbrauchen Netzwerkressourcen anders, wie in "Planen Ihrer Subnetzgröße" beschrieben. Beide Typen erreichen Ihre Ressourcen über private Endpunkte in Ihrem virtuellen Netzwerk.
Nächste Schritte
- Stellen Sie die Option mit der Setup-Vorgehensweise oder der Vorlage aus der Tabelle bereit.
- Überprüfen Sie die Bereitstellung: Bestätigen Sie die Subnetzdelegierung, dass der öffentliche Zugriff deaktiviert ist und dass die Endpunkte innerhalb des virtuellen Netzwerks in private IP-Adressen aufgelöst werden. Siehe Überprüfen der Bereitstellung.
- Behandeln von Bereitstellungs- oder Konnektivitätsfehlern mit dem Handbuch zur Problembehandlung.