Freigeben über


API-Verbundverwaltung mit Arbeitsbereichen

GILT FÜR: Premium

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 Arbeitsbereichs-Gateway für das Routing von API-Datenverkehr an die Back-End-Dienste von APIs im Arbeitsbereich zugeordnet.
  • Das Plattformteam kann API-Richtlinien anwenden, die APIs in Arbeitsbereichen umfassen und 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.

Konzeptionelles Diagramm des API Management-Diensts mit Arbeitsbereichen

Hinweis

  • Die aktuellen Arbeitsbereichsfunktionen werden in der API Management-REST-API-Version 2023-09-01-preview oder höher unterstützt.
  • Informationen zur Preisgestaltung finden Sie unter API Management – Preise.

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)

In einer Organisation, die APIs mithilfe von Azure API Management verwaltet, arbeiten möglicherweise mehrere Entwicklungsteams, die verschiedene Arten von APIs entwickeln, definieren, verwalten und in die Produktion überführen. Mithilfe von Arbeitsbereichen können diese Teams API Management nutzen, um ihre APIs separat und unabhängig von der Verwaltung der Dienstinfrastruktur zu verwalten, zu schützen und darauf zuzugreifen.

Im Folgenden sehen Sie einen Beispielworkflow zum Erstellen und Verwenden eines Arbeitsbereichs.

  1. Ein zentrales API-Plattformteam, das die API Management-Instanz verwaltet, erstellt einen Arbeitsbereich und weist Arbeitsbereichsmitarbeitern mithilfe von RBAC-Rollen Berechtigungen zu, beispielsweise Berechtigungen zum Erstellen oder Lesen von Ressourcen im Arbeitsbereich. Für den Arbeitsbereich wird auch ein API-Gateway mit Arbeitsbereichsbereich erstellt.

  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 Arbeitsbereichsgateways konfiguriert, um die Laufzeit der im Arbeitsbereich verwalteten APIs zu aktivieren. Ein Arbeitsbereichsgateway ist eine eigenständige Azure-Ressource (Workspace Gateway Premium) mit der gleichen Kernfunktionalität wie das in Ihren API-Verwaltungsdienst integrierte Gateway.

Arbeitsbereichs-Gateways werden unabhängig vom API Management-Dienst und voneinander verwaltet. Sie gestatten die Isolation der Runtime zwischen Arbeitsbereichen oder Anwendungsfällen und erhöhen dadurch die API-Zuverlässigkeit, -Resilienz und -Sicherheit und ermöglichen die Zuordnung von Runtimeproblemen zu Arbeitsbereichen.

Zuordnen von Arbeitsbereichen zu einem Arbeitsbereichs-Gateway

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

Hinweis

Das Zuordnen mehrerer Arbeitsbereiche zu einem Arbeitsbereichsgateway ist nur für Arbeitsbereichsgateways verfügbar, die nach dem 15. April 2025 erstellt wurden.

  • Ein Arbeitsbereichsgateway verfügt über eine bestimmte Konfiguration (z. B. virtuelles Netzwerk, Skalierung, Hostname) und zugeordnete Computerressourcen (CPU, Arbeitsspeicher, Netzwerkressourcen).
  • Konfigurations- und Computerressourcen werden von allen Arbeitsbereichen gemeinsam genutzt, die auf einem Gateway bereitgestellt werden.
  • 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 auf einem Gateway bereitgestellt werden, desto höher ist das Risiko, dass eine API aus einem Arbeitsbereich Zuverlässigkeitsprobleme verursacht, die von einer API aus einem anderen Arbeitsbereich verursacht werden.
  • Überwachen Sie die Leistung Ihres Gateways 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.

  • Verwenden Sie dedizierte Gateways 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.
  • Zuverlässigkeit, Sicherheit und Kosten ausbalancieren – Ordnen Sie mehrere Arbeitsbereiche einem Gateway zu, um bei nicht kritischen Workloads ein Gleichgewicht zwischen diesen Aspekten zu erreichen. Durch das Verteilen von Arbeitsbereichen über mindestens zwei Gateways können Probleme wie Ressourcenausschöpfung oder Konfigurationsfehler daran gehindert werden, alle APIs innerhalb der Organisation zu beeinträchtigen.
  • Verwenden Sie unterschiedliche Gateways für unterschiedliche Anwendungsfälle – Gruppenarbeitsbereiche auf einem Gateway 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 sich auf die Quarantäne problematischer Arbeitsbereiche vor – Verwenden Sie einen Proxy, z. B. Azure-Anwendungsgateway oder Azure Front Door, vor freigegebenen Arbeitsbereichsgateways, um das Verschieben eines Arbeitsbereichs zu vereinfachen, der die Ressourcenausschöpfung auf ein anderes Gateway verursacht, wodurch die Auswirkungen auf andere Arbeitsbereiche verhindert werden, die das Gateway freigeben.

Hinweis

  • Ein Arbeitsbereichsgateway muss sich in derselben Region wie die primäre Azure-Region der API-Verwaltungsinstanz und im selben Abonnement befinden.
  • Alle Arbeitsbereiche, die einem Arbeitsbereichsgateway zugeordnet sind, müssen sich in derselben API-Verwaltungsinstanz befinden.
  • Ein Arbeitsbereichsgateway kann bis zu 30 Arbeitsbereichen zugeordnet werden (wenden Sie sich an den Support, um diesen Grenzwert zu erhöhen).

Gatewayhostname

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 werden benutzerdefinierte Domänennamen für Arbeitsbereichs-Gateways nicht unterstützt. Sie können Azure-Anwendungsgateway oder Azure Front Door mit einem benutzerdefinierten Hostnamen vor einem Arbeitsbereichsgateway konfigurieren.

Netzwerkisolation

Ein Arbeitsbereichs-Gateway kann optional in einem privaten virtuellen Netzwerk konfiguriert werden, um eingehenden und/oder ausgehenden Datenverkehr zu isolieren. Wird diese Einstellung konfiguriert, muss das Arbeitsbereichs-Gateway ein dediziertes Subnetz im virtuellen Netzwerk verwenden.

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

Hinweis

  • Die Netzwerkkonfiguration eines Arbeitsbereichs-Gateways ist unabhängig von der Netzwerkkonfiguration der API Management-Instanz.
  • Derzeit kann ein Arbeitsbereichs-Gateway nur in einem virtuellen Netzwerk konfiguriert werden, wenn das Gateway erstellt wird. Sie können die Netzwerkkonfiguration oder -einstellungen des Gateways später nicht mehr ändern.

Skalieren der Kapazität

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

Regionale Verfügbarkeit

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

Einschränkungen für Gateways

Die folgenden Einschränkungen gelten derzeit für Arbeitsbereichs-Gateways:

  • Einem Arbeitsbereich kann kein selbstgehostetes Gateway zugeordnet werden.
  • Arbeitsbereichs-Gateways unterstützen keine eingehenden privaten Endpunkte.
  • APIs in Arbeitsbereich-Gateways können keine benutzerdefinierten Hostnamen zugewiesen werden.
  • APIs in Arbeitsbereichen werden von Defender für APIs nicht abgedeckt.
  • Arbeitsbereichs-Gateways unterstützen die Anmeldeinformationsverwaltung des API Management-Diensts nicht.
  • Arbeitsbereichs-Gateways unterstützen nur internen Cache. Externer Cache wird nicht unterstützt.
  • Arbeitsbereichsgateways unterstützen keine synthetischen GraphQL-APIs
  • Die Erstellung von APIs direkt aus Azure-Ressourcen wie Azure OpenAI Service, App Service, Function Apps usw. wird von Arbeitsbereichs-Gateways nicht unterstützt.
  • Anforderungsmetriken können nicht nach Arbeitsbereich in Azure Monitor aufgeteilt werden. Alle Arbeitsbereichsmetriken werden auf Dienstebene aggregiert.
  • Arbeitsbereichs-Gateways unterstützen keine CA-Zertifikate.
  • Arbeitsbereichs-Gateways unterstützen keine verwalteten Identitäten, einschließlich verwandter Features wie das Speichern von Geheimnissen in Azure Key Vault und die Verwendung der Richtlinie authentication-managed-identity.
  • Arbeitsbereichsgateways können nur in der primären Azure-Region der API-Verwaltungsinstanz erstellt werden.

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, müssen Arbeitsbereichsmitgliedern Rollen (oder gleichwertige Berechtigungen mit benutzerdefinierten Rollen) zugewiesen werden, die auf den API Management-Dienst, den Arbeitsbereich und das Arbeitsbereichs-Gateway 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.

Hinweis

Richten Sie zur einfacheren Verwaltung Microsoft Entra ID-Gruppen ein, um Arbeitsbereichsberechtigungen für mehrere Benutzer zuzuweisen.

Arbeitsbereiche und andere Features von API Management

Arbeitsbereiche sind so konzipiert, dass sie eigenständig sind, um die Trennung des administrativen Zugriffs und der API-Runtime zu maximieren. Es gibt mehrere Ausnahmen, um eine höhere Produktivität zu gewährleisten und plattformweite Governance, Beobachtbarkeit, Wiederverwendbarkeit und API-Ermittlung zu ermöglichen.

  • 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 ist es nicht möglich, von Richtlinien auf Arbeitsbereichsebene (z. B. benannten Werten) auf Ressourcen auf Dienstebene zu verweisen. Auch Verweise anhand von Ressourcennamen, z. B. backend-id in der Richtlinie set-backend-service, sind nicht zulässig.

    Wichtig

    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. Es dürfen keine Ressourcen desselben Typs und mit demselben Azure-Ressourcennamen im selben Arbeitsbereich, in anderen Arbeitsbereichen oder auf Dienstebene vorhanden sein.

  • 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. APIs und Produkte innerhalb eines Arbeitsbereichs können im Entwicklerportal veröffentlicht werden, genau wie APIs und Produkte auf Serviceebene.

    Hinweis

    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

Beim Löschen eines Arbeitsbereichs werden alle untergeordneten Ressourcen (APIs, Produkte usw.) und das zugehörige Gateway gelöscht, wenn Sie den Arbeitsbereich über die Azure-Portalschnittstelle löschen. Die API Management-Instanz oder andere Arbeitsbereiche werden nicht gelöscht.