適用於：進階 | 進階 v2
本文概述了 API 管理工作區，以及說明它們如何幫助分散式 API 開發團隊，在共同的服務基礎結構中管理其 API 並將其 API 產品化。
為什麼組織應該聯合 API 管理？
現今，組織在管理數量激增的 API 方面面臨日益嚴峻的挑戰。 隨著 API 和 API 開發團隊數目的成長，管理它們的複雜性也隨之增加。 這種複雜性會導致營運的額外負荷增加、安全性風險上升以及敏捷性下降。 一方面，組織想要建立一個集中式的 API 基礎結構，以確保能實現 API 的治理、安全性和合規性。 另一方面，他們又希望其 API 團隊能夠創新並快速回應業務需求，而無需承擔管理 API 平台的額外負荷。
聯合的 API 管理模型可以滿足這些需求。 聯合的 API 管理可讓開發團隊進行分散式 API 管理，並適當隔離控制平面和資料平面，同時維持由 API 平台團隊管理的集中式治理、監視和 API 探索。 此模型克服了其他方法的局限性，例如平台團隊完全集中式的 API 管理或各個開發團隊各自獨立的 API 管理。
聯合的 API 管理可提供：
- 集中式的 API 治理與可檢視性
- 統一的開發人員入口網站，適用於有效率的 API 探索和上線
- API 團隊之間隔離的管理權限，從而提高生產力和安全性
- API 團隊之間隔離的 API 執行階段，從而提高可靠性、復原性和安全性
工作區如何實現聯合的 API 管理
在 Azure API 管理中，使用工作區來實作聯合的 API 管理。 工作區在 APIM 服務內的功能如同「資料夾」：
- 每個工作區都包含 API、產品、訂用帳戶、具名值和相關資源。 如需工作區中支援的資源和作業完整清單，請參閱 APIM REST API 參照。
- 團隊對工作區內資源的存取會透過 Azure 的角色型存取控制 (RBAC) (其中內建的角色或自訂角色可指派給 Microsoft Entra 帳戶，並限定在特定的工作區範圍內) 來進行管理。
- 每一個工作區都會與一或多個工作區閘道相關聯，以便將 API 流量路由傳送至工作區中的 API 後端服務。
- 平台團隊可以套用涵蓋工作區中的 API 和產品的原則，以管控整個組織的 API 執行階段。 內建的 Azure 原則定義 (
API Management policies should inherit parent scope policies using <base/>) 可讓您稽核或強制執行這些原則，確保其套用至所有工作區資源。 - 平台團隊可以使用開發人員入口網站來實作集中式的 API 探索體驗。
- 每個工作區小組都可以收集並分析網關資源記錄，以監視自己的工作區 API，而平臺小組可同盟存取 API 管理服務中所有工作區的記錄，提供其 API 生態系統的監督、安全性和合規性。
附註
- APIM REST API 版本 2023-09-01-preview 或更新版本支援最新的工作區功能。
- 如需定價考量，請參閱 API 管理定價。
雖然工作區與 APIM 服務和其他工作區獨立管理，但依據設計可以參考選取的服務層級資源。 請參閱後文的工作區和其他 APIM 功能。
範例案例概觀
使用 Azure API 管理管理 API 的組織可能會有多個開發小組開發、定義、維護及產品化不同的 API 集合。 工作區可讓這些小組分別使用 APIM 來管理、存取及保護其 API，並且獨立於管理服務基礎結構。
以下是用來建立和使用工作區的範例工作流程。
管理 API 管理執行個體的中央 API 平台小組會建立工作區，並使用 RBAC 角色將權限指派給工作區共同作業者，例如，在工作區中建立或讀取資源的權限。 也會為工作區建立一個限定於工作區範圍的 API 閘道。
中央 API 平台小組會使用 DevOps 工具來為該工作區中的 API 建立 DevOps 管線。
工作區成員會在工作區中開發、發佈、產品化及維護 API。
中央 API 平台小組會管理服務的基礎結構，例如監視、復原以及強制執行所有 API 原則。
工作區閘道
每個工作區都會設定一或多個 工作區閘道 ，以啟用工作區內受控 API 的運行時間。 工作區閘道是獨立的 Azure 資源（工作區閘道進階版），其核心功能與 API 管理服務中內建的閘道相同。
工作區閘道與 APIM 服務和其他閘道獨立管理。 它們允許在工作區或使用案例之間隔離執行階段，從而提高 API 的可靠性、復原性和安全性，並且能夠將執行階段問題歸因於工作區。
附註
在 2025 年 8 月，我們宣布了對工作區中的閘道和層級支援即將進行的變更。 如需詳細資料，請參閱公告
將工作區與工作區閘道連結起來
視組織的需求而定，您可以將一個工作區或多個工作區與工作區網關建立關聯。
附註
將多個工作區與工作區網關建立關聯僅適用於 2025 年 4 月 15 日之後建立的工作區閘道。
- 工作區閘道具有特定設定（例如虛擬網路、規模、主機名）和配置運算資源（CPU、記憶體、網路資源）。
- 所有部署在閘道上的工作區都會共用設定和計算資源。
- API 或異常流量中的 Bug 可能會導致這些資源耗盡，而影響該閘道上的所有工作區。 換句話說，在閘道上部署的工作區越多，來自工作區的 API 將遇到來自另一個工作區之 API 所造成的可靠性問題的風險就越高。
- 使用內建的度量工具來監視閘道的效能，檢查 CPU 和記憶體的使用率。
選擇工作區的部署模型時，請考慮可靠性、安全性和成本。
- 針對任務關鍵性工作負載使用專用閘道 - 若要將 API 可靠性和安全性最大化，請將每個任務關鍵性工作區指派給自己的網關，避免與其他工作區共用。
- 平衡可靠性、安全性和成本 - 讓多個工作區與閘道產生關聯，以平衡非關鍵工作負載的可靠性、安全性和成本。 將工作區分散到至少兩個網關可以幫助防止某些問題，例如資源耗盡或配置錯誤，以免影響組織內的所有 API。
- 針對不同的使用案例使用不同的閘道 - 根據使用案例或網路需求，將閘道上的工作區分組。 例如，您可以將它們指派給個別閘道，每個閘道都有自己的網路組態，以區分內部和外部 API。
- 準備隔離有問題的工作區 - 在共用工作區閘道前使用 Proxy，例如 Azure 應用程式閘道或 Azure Front Door，以簡化將造成資源耗盡的工作區移至不同的閘道，以防止對共用閘道的其他工作區造成影響。
附註
- 工作區閘道必須位於與 API 管理實例的主要 Azure 區域和相同訂用帳戶中的相同區域中
- 與工作區閘道相關聯的所有工作區都必須位於相同的 API 管理實例中
- 工作區閘道最多可與 30 個工作區相關聯（請連絡支援人員以增加此限制）
閘道主機名稱
每個工作區閘道都會為相關聯工作區中管理的 API 提供唯一的主機名。 預設主機名稱會遵循模式 <gateway-name>-<hash>.gateway.<region>.azure-api.net。 使用網關主機名稱，將 API 請求路由至工作區中的 API。
目前，工作區閘道不支援自訂主機名稱。 您可以使用工作區閘道前的自訂主機名來設定 Azure 應用程式閘道或 Azure Front Door。
網路隔離
工作區閘道可以選擇性地設定在私人虛擬網路中，以隔離輸入和/或輸出流量。 如果已設定，工作區閘道必須在虛擬網路中使用專用子網路。
如需詳細需求，請參閱工作區閘道的網路資源需求。
附註
- 工作區閘道的網路設定與 APIM 執行個體的網路設定無關。
- 目前，只有在建立閘道時，才能在虛擬網路中設定工作區閘道。 您稍後無法變更閘道的網路設定或其他設定。
縮放容量
透過新增或移除擴展單位來管理閘道容量，這類似於某些服務層級中可新增至 API 管理實例的 單位 。 工作區閘道的成本取決於您選取的單位數目。
區域可用性
如需可用工作區閘道的現行區域清單，請參閱 v2 層和工作區閘道的可用性。
閘道條件約束
下列條件約束目前適用於工作區閘道：
- 工作區無法與自我裝載閘道相關聯
- 工作區閘道不支援輸入私人端點
- 工作區閘道中的 API 無法指派自訂主機名稱
- 適用於 API 的 Defender 未涵蓋工作區中的 API
- 工作區閘道不支援 APIM 服務的認證管理員
- 工作區閘道僅支援內部快取；不支援外部快取
- 工作區閘道不支援合成的 GraphQL API
- 工作區閘道不支援直接從 Azure 資源 (例如 Azure OpenAI 服務、App Service、Function Apps 等等) 中建立 API
- 工作區閘道不支援 MCP 伺服器
- 要求計量無法依 Azure 監視器中的工作區分割；所有工作區計量都會在服務層級匯總
- 工作區閘道不支援 CA 憑證
- 工作區閘道不支援受控識別，包括在 Azure Key Vault 中儲存祕密和使用
authentication-managed-identity原則等相關功能 - 工作區閘道只能在 API 管理實例的主要 Azure 區域中建立
工作區的 RBAC 角色
Azure RBAC 可用來設定工作區共同作業者的權限，以讀取和編輯工作區中的實體。 如需角色清單，請參閱如何在 API 管理中使用角色型存取控制。
若要管理工作區中的 API 和其他資源，工作區成員必須在 APIM 服務、工作區和工作區閘道的限定範圍中獲得角色指派 (或使用自訂角色的同等權限)。 服務範圍角色允許從工作區層級資源參考特定的服務層級資源。 例如，將使用者組織為工作區層級群組，以控制 API 和產品可見度。
附註
為了更容易管理，請設定 Microsoft Entra 群組，將工作區權限指派給多個使用者。
工作區和其他 API 管理功能
工作區設計成獨立式，以最大化系統管理存取和 API 執行階段的隔離。 有數個例外狀況可確保更高的生產力，並啟用全平台治理、可檢視性、再使用性和 API 探索。
資源參考 - 工作區中的資源可以參考工作區中的其他資源，以及服務層級的選取資源，例如使用者、授權伺服器或內建使用者群組。 它們無法參考其他工作區的資源。
基於安全性考量，您無法從工作區層級原則 (例如具名值) 或資源名稱 (例如 set-backend-service 原則中的
backend-id) 參考服務層級資源。重要事項
APIM 服務中的所有資源 (例如 API、產品、標籤或訂用帳戶) 都必須有唯一的名稱，即使它們位於不同的工作區中也一樣。 在相同工作區、其他工作區或服務等級中，不能有相同類型且具有相同 Azure 資源名稱的任何資源。
開發人員入口網站 - 工作區是系統管理概念，因此不會向開發人員入口網站取用者展示，包括透過開發人員入口網站 UI 和底層 API。 工作區內的 API 和產品可以發佈至開發人員入口網站，如同服務層級上的 API 和產品。
附註
APIM 支援將服務層級上定義的授權伺服器指派給工作區內的 API。
從預覽工作區移轉
如果您在 Azure APIM 中建立預覽工作區，並想要繼續使用這些工作區，請藉由將工作區閘道與每個工作區建立關聯，以移轉工作區至正式推出版本。
如需詳細資訊並了解可能會影響預覽工作區的其他變更，請參閱工作區中斷性變更 (2025 年 3 月)。
刪除工作區
如果您使用 Azure 入口網站介面刪除工作區，則刪除工作區會刪除其所有子資源 (API、產品等) 及其相關聯閘道。 但不會刪除 APIM 執行個體或其他工作區。