API-Verbundverwaltung mit Arbeitsbereichen

GILT FÜR: Basic v2 | Standard v2 | Premium | Premium v2

Dieser Artikel enthält eine Übersicht über API Managementarbeitsbereiche und wie sie dezentrale API-Entwicklungsteams unterstützen, ihre APIs in einer gemeinsamen Dienstinfrastruktur zu verwalten und zu produktisieren.

Warum sollten Organisationen das API-Verbundmanagement verwenden?

Heute stehen Organisationen zunehmend vor Herausforderungen bei der Verwaltung einer Verbreitung von APIs. Da die Zahl der APIs und API-Entwicklungsteams wächst, so wächst auch die Komplexität der Verwaltung. Diese Komplexität kann zu erhöhtem Betriebsaufwand, Sicherheitsrisiken und reduzierter Flexibilität führen. Einerseits möchten Organisationen eine zentrale API-Infrastruktur einrichten, um API-Governance, Sicherheit und Konformität sicherzustellen. Andererseits möchten sie, dass ihre API-Teams Neuerungen einführen und schnell auf Geschäftsanforderungen reagieren können, ohne dass der Aufwand für die Verwaltung einer API-Plattform besteht.

Ein Verbundmodell des API Managements behebt diese Anforderungen. Das föderierte API-Management ermöglicht ein dezentrales API-Management durch Entwicklungsteams mit geeigneter Isolation der Steuerungs- und Datenebenen, während zentrale Governance, Überwachung und API-Entdeckung von einem API-Plattformteam gehandhabt werden. Dieses Modell überwindet die Einschränkungen alternativer Ansätze wie dem vollständig zentralisierten API Management durch das Plattformteam oder die Silo-API Management durch jedes Entwicklungsteam.

Das Verbund-API Management bietet Folgendes:

• Zentrale API-Governance und -Beobachtbarkeit
• Ein einheitliches Entwicklerportal für effektives Ermitteln und Onboarden von APIs
• Getrennte administrative Berechtigungen zwischen API-Teams, Verbesserung der Produktivität und Sicherheit
• Getrennte API-Runtime zwischen API-Teams, Verbesserung der Zuverlässigkeit, Resilienz und Sicherheit

So aktivieren Arbeitsbereiche das Verbund-API Management

Verwenden Sie Arbeitsbereiche, um verteiltes API-Management in Azure API Management zu implementieren. Arbeitsbereiche funktionieren wie „Ordner“ in einem API Management-Dienst:

• Jeder Arbeitsbereich enthält APIs, Produkte, Abonnements, benannte Werte und zugehörige Ressourcen. Eine vollständige Liste der Ressourcen und Vorgänge, die in Arbeitsbereichen unterstützt werden, finden Sie in der REST-API-Referenz von API Management.
• Der Zugriff von Teams auf Ressourcen innerhalb eines Arbeitsbereichs wird durch die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure mit integrierten oder benutzerdefinierten Rollen verwaltet, die Microsoft Entra-Konten zugewiesen und auf einen Arbeitsbereich zugeschnitten sind.
• Jeder Arbeitsbereich ist einem oder mehreren Gateways für das Routing von API-Datenverkehr an die Back-End-Dienste von APIs im Arbeitsbereich zugeordnet. Je nach Dienstebene und Ihren Anforderungen kann ein Arbeitsbereich das standardmäßige verwaltete Gateway des Diensts oder ein oder mehrere Arbeitsbereichsgateways verwenden.
• Das Plattformteam kann Richtlinien anwenden, die APIs und Produkte in Arbeitsbereichen umfassen, um die API-Laufzeit in der gesamten Organisation zu steuern. Mit einer integrierten Azure-Richtliniendefinition (API Management policies should inherit parent scope policies using <base/>) können Sie überwachen oder erzwingen, dass diese Richtlinien in allen Arbeitsbereichsressourcen angewendet werden.
• Das Plattformteam kann eine zentrale API-Ermittlungserfahrung mit einem Entwicklerportal implementieren.
• Jedes Arbeitsbereichsteam kann Gatewayressourcenprotokolle sammeln und analysieren, um seine eigenen Arbeitsbereich-APIs zu überwachen, während das Plattformteam über Verbundzugriff auf Protokolle über alle Arbeitsbereiche im API-Verwaltungsdienst verfügt, die Aufsicht, Sicherheit und Compliance im gesamten API-Ökosystem bereitstellt.

Arbeitsbereiche werden zwar unabhängig vom API Management-Dienst und anderen Arbeitsbereichen verwaltet, können aber entwurfsbedingt auf ausgewählte Ressourcen auf Dienstebene verweisen. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Arbeitsbereiche und andere Features von API Management.

Beispielszenario (Übersicht)

Eine Organisation, die APIs mithilfe von Azure API Management verwaltet, verfügt möglicherweise über mehrere Entwicklungsteams, die unterschiedliche APIs entwickeln, definieren, verwalten und produktieren. Mithilfe von Arbeitsbereichen können diese Teams die API-Verwaltung verwenden, um ihre APIs separat und unabhängig von der Verwaltung der Dienstinfrastruktur zu verwalten, darauf zuzugreifen und sie zu schützen.

Der folgende Workflow zeigt einen Beispielprozess zum Erstellen und Verwenden eines Arbeitsbereichs.

1. Ein zentrales API-Plattformteam, das die API-Verwaltungsinstanz verwaltet, erstellt einen Arbeitsbereich und weist Arbeitsbereichsmitarbeitern Mithilfe von RBAC-Rollen Berechtigungen zu. Weisen Sie beispielsweise Berechtigungen zum Erstellen oder Lesen von Ressourcen im Arbeitsbereich zu. Das Team erstellt oder ordnet dem Arbeitsbereich ein API-Gateway zu, um DEN API-Datenverkehr weiterzuleiten.

2. Ein zentrales API-Plattformteam verwendet DevOps-Tools, um eine DevOps-Pipeline für APIs in diesem Arbeitsbereich zu erstellen.

3. Arbeitsbereichsmitglieder entwickeln, veröffentlichen, produzieren und verwalten APIs im Arbeitsbereich.

4. Das zentrale API-Plattformteam verwaltet die Infrastruktur des Diensts, z. B. Überwachung, Resilienz und Durchsetzung von für alle APIs geltenden Richtlinien.

Arbeitsbereichs-Gateway

Jeder Arbeitsbereich ist mit einem oder mehreren Gateways konfiguriert, um die Laufzeit der im Arbeitsbereich verwalteten APIs zu aktivieren. Je nach Dienstebene und Ihren Anforderungen können Sie das standardmäßige verwaltete Gateway und/oder ein oder mehrere Arbeitsbereichsgateways (separate Gatewayressourcen) des Diensts verwenden.

Standardmäßig verwaltetes Gateway

In den v2-Ebenen können Sie einen Arbeitsbereich so konfigurieren, dass der API-Datenverkehr über das standardmäßige verwaltete Gateway des Diensts weitergeleitet wird, zusätzlich zu einer oder mehreren separaten Arbeitsbereichsgatewayressourcen. Wenn ein Arbeitsbereich das standardmäßige verwaltete Gateway verwendet:

• API-Datenverkehr wird über den Standard-Hostnamen des Diensts geleitet (z. B. <service-name>.azure-api.net).
• Der Arbeitsbereich teilt die Kapazität und Konfiguration des Gateways mit anderen Arbeitsbereichen und APIs auf Dienstebene.

Arbeitsbereichs-Gateway

Ein Arbeitsbereichsgateway ist eine eigenständige Azure Ressource (workspace gateway premium) mit der gleichen Kernfunktionalität wie das standardverwaltete Gateway.

Sie verwalten Arbeitsbereichsgateways unabhängig vom API-Verwaltungsdienst und voneinander. Sie ermöglichen die Isolierung der Laufzeit zwischen Arbeitsbereichen oder Anwendungsfällen, wodurch die ZUVERLÄSSIGKEIT, Resilienz und Sicherheit der API erhöht wird. Sie ermöglichen auch die Zuordnung von Laufzeitproblemen zu Arbeitsbereichen.

• Informationen zu den Kosten für Arbeitsbereichs-Gateways finden Sie unter API Management-Preise.
• Einen detaillierten Vergleich der API Management-Gateways finden Sie unter Übersicht über API Management-Gateways.

Zuordnen von Arbeitsbereichen zu einem Arbeitsbereichs-Gateway

Je nach Anforderungen Ihrer Organisation können Sie einen oder mehrere Arbeitsbereiche einem Gateway zuordnen.

• Ein Arbeitsbereichsgateway verfügt über bestimmte Konfigurationseinstellungen, z. B. virtuelles Netzwerk, Skalierung und Hostname, und zugewiesene Computerressourcen, einschließlich CPU, Arbeitsspeicher und Netzwerkressourcen.
• Alle auf einem Gateway bereitgestellten Arbeitsbereiche teilen die Konfigurations- und Computerressourcen.
• Fehler in einer API oder anomalen Datenverkehr können zu Erschöpfung dieser Ressourcen führen, was sich auf alle Arbeitsbereiche auf diesem Gateway auswirkt. Anders ausgedrückt: Je mehr Arbeitsbereiche Sie auf einem Gateway bereitstellen, desto höher ist das Risiko, dass eine API aus einem Arbeitsbereich Zuverlässigkeitsprobleme verursacht, die durch eine API aus einem anderen Arbeitsbereich verursacht werden.
• Überwachen Sie die Leistung Ihres Arbeitsbereichsgateways mithilfe integrierter Metriken für die CPU- und Arbeitsspeicherauslastung.

Berücksichtigen Sie Zuverlässigkeit, Sicherheit und Kosten bei der Auswahl eines Bereitstellungsmodells für Arbeitsbereiche.

• Zuweisen eines Arbeitsbereichs zu einem eigenen dedizierten Arbeitsbereichsgateway für unternehmenskritische Workloads – Um die ZUVERLÄSSIGKEIT und Sicherheit der API zu maximieren, weisen Sie jedem unternehmenskritischen Arbeitsbereich ein eigenes Gateway zu, und vermeiden Sie die gemeinsame Nutzung mit anderen Arbeitsbereichen.
• Wägen Sie Zuverlässigkeit, Sicherheit und Kosten ab – Ordnen Sie mehrere Arbeitsbereiche einem Arbeitsbereichsgateway (oder gegebenenfalls dem standardmäßig verwalteten Gateway) zu, um Zuverlässigkeit, Sicherheit und Kosten für nicht kritische Workloads auszugleichen. Verteilen Sie Arbeitsbereiche über mindestens zwei Gateways, um Probleme wie Ressourcenausschöpfung oder Konfigurationsfehler zu verhindern, die auswirkungen auf alle APIs innerhalb der Organisation haben.
• Verwenden Sie unterschiedliche Gateways für unterschiedliche Anwendungsfälle – Gruppenarbeitsbereiche auf einem Arbeitsbereichsgateway basierend auf einem Anwendungsfall oder Netzwerkanforderungen. Sie können z. B. zwischen internen und externen APIs unterscheiden, indem Sie sie separaten Gateways zuweisen, jeweils mit einer eigenen Netzwerkkonfiguration.
• Bereiten Sie das Isolieren problematischer Arbeitsbereiche vor – Verwenden Sie vor gemeinsam genutzten Arbeitsbereichsgateways einen Proxy, z. B. Azure Application Gateway oder Azure Front Door, um das Verschieben eines Arbeitsbereichs, der zur Erschöpfung von Ressourcen führt, auf ein anderes Gateway zu vereinfachen. Dieser Ansatz verhindert Beeinträchtigungen anderer Arbeitsbereiche, die sich das Gateway teilen.

Hostname des Arbeitsbereichsgateways

Jedes Arbeitsbereichsgateway stellt einen eindeutigen Hostnamen für APIs bereit, die in einem zugeordneten Arbeitsbereich verwaltet werden. Standardhostnamen folgen dem Muster <gateway-name>-<hash>.gateway.<region>.azure-api.net. Verwenden Sie den Gateway-Hostnamen, um API-Anforderungen an die APIs Ihres Arbeitsbereichs weiterzuleiten.

Derzeit unterstützen Arbeitsbereichsgateways keine benutzerdefinierten Hostnamen. Sie können Azure-Anwendungsgateway oder Azure Front Door mit einem benutzerdefinierten Hostnamen vor einem Arbeitsbereichsgateway konfigurieren.

Netzwerkisolation für Arbeitsbereichsgateways

Sie können optional eine Arbeitsbereichsgatewayressource in einem privaten virtuellen Netzwerk konfigurieren, um eingehenden und ausgehenden Datenverkehr zu isolieren. Wenn Sie diese Isolation konfigurieren, muss das Arbeitsbereichsgateway ein dediziertes Subnetz im virtuellen Netzwerk verwenden.

Ausführliche Anforderungen finden Sie unter Netzwerkressourcenanforderungen für Arbeitsbereichs-Gateways.

Kapazität für Arbeitsbereichsgateways skalieren

Verwalten Sie die Kapazität eines Arbeitsbereichgateways, indem Sie Skalierungseinheiten hinzufügen oder entfernen, ähnlich wie die Einheiten , die Sie der API-Verwaltungsinstanz in bestimmten Dienstebenen hinzufügen können. Die Kosten für ein Arbeitsbereichs-Gateway basieren auf der Anzahl der ausgewählten Einheiten.

Regionale Verfügbarkeit von Arbeitsbereichsgateways

Eine aktuelle Liste der Regionen, in denen Arbeitsbereichsgateways vorhanden sind, finden Sie unter Verfügbarkeit von v2-Stufen und Arbeitsbereichsgateways.

Einschränkungen für Arbeitsbereiche und Arbeitsbereichsgateways

Arbeitsbereichseinschränkungen

• Einem Arbeitsbereich kann kein selbstgehostetes Gateway zugeordnet werden.
• APIs in Arbeitsbereichen werden von Defender für APIs nicht abgedeckt.
• Arbeitsbereiche unterstützen keine Anmeldeinformationsverwaltung
• Arbeitsbereiche unterstützen nur internen Cache; Externer Cache wird nicht unterstützt
• Arbeitsbereiche unterstützen keine synthetischen GraphQL-APIs
• Arbeitsbereiche unterstützen im Azure-Portal nicht das direkte Erstellen von APIs aus Azure-Ressourcen wie Azure OpenAI Service, App Service, Function Apps usw.
• Arbeitsbereiche unterstützen keine MCP-Server
• Anforderungsmetriken können nicht nach Arbeitsbereich in Azure Monitor aufgeteilt werden. Alle Arbeitsbereichsmetriken werden auf Dienstebene aggregiert.
• Arbeitsbereiche unterstützen keine CA-Zertifikate
• Arbeitsbereiche unterstützen keine verwalteten Identitäten, einschließlich zugehöriger Funktionen wie dem Speichern von Geheimnissen in Azure Key Vault und der Verwendung der Richtlinie authentication-managed-identity

Einschränkungen für das Arbeitsbereichsgateway

Die folgenden Einschränkungen gelten für die Ressource für das Gateway des verwalteten Arbeitsbereichs. Sie gelten nicht bei der Verwendung von Arbeitsbereichen auf dem standardmäßig verwalteten Gateway des Diensts.

• Arbeitsbereichs-Gateways unterstützen keine eingehenden privaten Endpunkte.
• Arbeitsbereichsgateways unterstützen keine benutzerdefinierten Hostnamen
• Arbeitsbereiche können nur mit Arbeitsbereichsgateways verknüpft werden, die sich in derselben Region und demselben Abonnement wie die API Management-Ressource befinden.

Globale Richtlinienvererbung in Arbeitsplatz-Gateways

Arbeitsbereich-Gateways führen die gesamte Richtlinienkette aus, einschließlich der globalen Richtlinie auf Servicelevel (global.policy.xml). Dieses Verhalten bedeutet, dass alle richtlinien, die auf globaler Ebene definiert sind, ausgewertet und für API-Aufrufe ausgeführt werden, die von Arbeitsbereichsgateways verarbeitet werden, genau wie für das Standardgateway. Dieses Verhalten ist entwurfsmäßig und konsistent mit dem Api-Verwaltungsrichtlinienauswertungsmodell, bei dem Sie Richtlinien hierarchisch in den folgenden Bereichen anwenden: globaler (Dienst) > -Arbeitsbereich-Produkt-API-Vorgang >>> .

Empfehlungen für globale Richtlinien mit Workspace-Gateways

• Überprüfen Sie Ihre globale Richtlinie, um sicherzustellen, dass sie nur Richtlinien enthält, die für alle Gateways gelten sollen, einschließlich Arbeitsbereichsgateways.

• Wenn Sie ein anderes Verhalten pro Gateway benötigen, verwenden Sie die Auswahlrichtlinie , context.Deployment.Gateway.Id um Richtlinien basierend auf dem Gateway, das die Anforderung verarbeitet, bedingt auszuführen.

• Wenn Sie eine authentifizierungsverwaltete Identität im globalen Bereich definieren, das Token jedoch nicht für apIs mit Arbeitsbereichsbereich verfügbar sein sollte, verschieben Sie die Richtlinie auf einen schmaleren Bereich (z. B. Produkt- oder API-Ebene) und nicht auf die globale Richtlinie.

RBAC-Rollen für Arbeitsbereiche

Mit Azure RBAC werden die Berechtigungen von Arbeitsbereichsmitarbeitern zum Lesen und Bearbeiten von Entitäten im Arbeitsbereich konfiguriert. Eine Liste der Rollen finden Sie unter Verwenden der rollenbasierten Zugriffssteuerung in API Management.

Um APIs und andere Ressourcen im Arbeitsbereich zu verwalten, weisen Sie Arbeitsbereichsmitgliedern (oder gleichwertigen Berechtigungen über benutzerdefinierte Rollen) Rollen zu, die auf den API-Verwaltungsdienst und den Arbeitsbereich ausgerichtet sind. Die servicebezogene Rolle ermöglicht es, bestimmte Ressourcen auf Dienstebene von Ressourcen auf Arbeitsplatzebene aus zu referenzieren. Organisieren Sie z. B. einen Benutzer in einer Gruppe auf Arbeitsbereichsebene, um die API und die Produktsichtbarkeit zu steuern.

Wenn der Arbeitsbereich ein dediziertes Arbeitsbereichsgateway verwendet, sollten Mitgliedern, die das Gateway verwalten, auch eine Rolle zugewiesen werden, die der Arbeitsbereichsgatewayressource zugeordnet ist.

Arbeitsbereiche und andere Features von API Management

Arbeitsbereiche sind eigenständig, um die Trennung des administrativen Zugriffs und der API-Laufzeit zu maximieren. Um eine höhere Produktivität zu gewährleisten und plattformweite Governance, Observability, Wiederverwendbarkeit und API-Ermittlung zu ermöglichen, gibt es mehrere Ausnahmen.

• Ressourcenverweise: Ressourcen in einem Arbeitsbereich können auf andere Ressourcen im Arbeitsbereich und auf ausgewählte Ressourcen der Dienstebene verweisen, etwa Benutzer, Autorisierungsserver oder integrierte Benutzergruppen. Sie können nicht auf Ressourcen aus einem anderen Arbeitsbereich verweisen.

  Aus Sicherheitsgründen können Sie in Richtlinien auf Arbeitsbereichsebene nicht auf Ressourcen auf Dienstebene verweisen, auch nicht mithilfe von Ressourcennamen, z. B. backend-id in der Richtlinie set-backend-service.

  Important

  Alle Ressourcen in einem API Management-Dienst (z. B. APIs, Produkte, Tags oder Abonnements) müssen eindeutige Namen aufweisen, auch wenn sie sich in verschiedenen Arbeitsbereichen befinden. Sie können nicht über Ressourcen desselben Typs und mit demselben Azure Ressourcennamen im selben Arbeitsbereich, in anderen Arbeitsbereichen oder auf Dienstebene verfügen.

• Entwicklungsportal: Arbeitsbereiche sind ein administratives Konzept und werden Kunden im Entwicklungsportal nicht als solche angezeigt. Dies gilt auch für die Benutzeroberfläche und die zugrunde liegende API des Entwicklungsportals. Sie können APIs und Produkte innerhalb eines Arbeitsbereichs im Entwicklerportal veröffentlichen, genau wie APIs und Produkte auf Dienstebene.

  Note

  API Management unterstützt das Zuweisen von auf Dienstebene definierten Autorisierungsservern zu APIs innerhalb von Arbeitsbereichen.

Migrieren von Vorschauarbeitsbereichen

Wenn Sie Vorschauarbeitsbereiche in Azure API Management erstellt haben und diese weiterhin verwenden möchten, migrieren Sie Ihre Arbeitsbereiche zur allgemein verfügbaren Version, indem Sie jeden Arbeitsbereich ein Arbeitsbereichs-Gateway zuordnen.

Einzelheiten und Informationen zu anderen Änderungen, die sich auf Ihre Vorschauarbeitsbereiche auswirken könnten, finden Sie unter Breaking Changes für Arbeitsbereiche (März 2025).

Löschen eines Arbeitsbereichs

Wenn Sie einen Arbeitsbereich mithilfe der Azure Portalschnittstelle löschen, löschen Sie auch alle untergeordneten Ressourcen (APIs, Produkte usw.) und ein dediziertes Arbeitsbereichsgateway, wenn einer zugeordnet ist. Die API Management-Instanz oder andere Arbeitsbereiche werden nicht gelöscht.

Verwandte Inhalte

• Erstellen eines Arbeitsbereichs
• Arbeitsbereiche brechen Änderungen – Juni 2024
• Breaking Changes für Arbeitsbereiche - März 2025
• Grenzwerte – Arbeitsbereiche in API Management