Azure API Management + Developer Portal Enterprise (2026)

Azure API Management and Google Apigee are both top-tier enterprise API gateway platforms and they cover overlapping ground, but the differences matter for any Microsoft-centric enterprise. APIM has tighter native integration with the rest of the Microsoft cloud — Entra ID identity (OAuth, managed identity, Workload ID Conditional Access), Microsoft Defender for APIs runtime protection, Application Insights observability, Key Vault references for named-value secrets, and Azure Functions / Logic Apps / App Service / AKS backend integration all work without integration plumbing. Apigee has a longer history in API monetization, broader analytics tooling, and a more mature multi-cloud deployment story for organizations already on GCP. The pragmatic decision in 2026 — enterprises already deep in Microsoft (Microsoft 365, Entra ID, Power Platform, Fabric, Azure) build their API gateway tier on APIM; enterprises deep in Google Cloud keep Apigee. Dual-gateway architectures are rare and almost always transitional rather than steady-state.

Kong is the leading open-source API gateway and Kong Enterprise / Kong Konnect compete with APIM on commercial features. Kong wins on raw gateway performance per CPU core at very high request rates, on Kubernetes-native deployment ergonomics, and on the open-source extensibility model where teams build custom plugins in Lua or Go. APIM wins on managed-service operational overhead (you do not run the control plane), on Developer Portal time-to-value (the APIM portal ships ready out of the box, Kong Konnect portal requires more configuration), on Entra ID and Microsoft cloud integration depth, and on the audit-evidence package regulated enterprises need. The decision depends on team profile — engineering-heavy organizations with platform teams that want full control and have the headcount choose Kong; teams that need the managed-service operational model and Microsoft integration depth choose APIM.

AWS API Gateway and Azure API Management are the two market-leading hyperscale-cloud API gateways and they cover the same baseline territory — request routing, throttling, auth integration, observability, and consumer self-service through a Developer Portal. The differentiators in 2026 — APIM ships a richer policy expression engine (named policy fragments, XML-based composition, custom expressions in C#-like syntax) where AWS API Gateway leans more on Lambda authorizers for custom behavior; APIM ships a far more capable Developer Portal out of the box; AWS API Gateway has tighter native Lambda integration where APIM has tighter Functions + Logic Apps + AKS integration. The enterprise decision is again platform alignment — Microsoft-centric organizations choose APIM, AWS-centric organizations choose API Gateway, and dual-gateway environments are transitional artifacts of multi-cloud strategy.

Tyk is the second most-deployed open-source API gateway after Kong and is particularly strong in the Kubernetes-native and edge-deployment use cases. Tyk wins on lighter operational footprint than Kong, simpler dashboard, and a strong GraphQL federation story. APIM wins on managed-service overhead (no control plane to run), on Entra ID and Microsoft Defender for APIs integration, on the rich policy expression engine, and on enterprise procurement and compliance posture. EPC Group sees Tyk most often in Kubernetes-first organizations with platform engineering teams that want the open-source model, and APIM in enterprises that want managed-service operational overhead and tighter Microsoft cloud integration. Both can coexist in larger enterprises where different teams own different API portfolios.

For new enterprise APIM deployments in 2026, the default recommendation is Standard v2. It delivers VNet integration with private endpoints (the historical Premium-only feature that drove most v1 enterprises onto Premium tier unnecessarily), the rebuilt v2 gateway runtime with better cold-start and scale behavior, full Developer Portal customization, and the full policy expression engine — at a price point well below Premium. The Premium tier remains the right answer for three specific cases — multi-region active-active deployments needing Traffic Manager-coordinated failover, self-hosted gateways at scale running inside customer datacenters or other clouds, and federal or FedRAMP High deployments requiring internal VNet mode with zero public IP. The Basic v2 tier is the right answer for SMB and single-team API portfolios that do not need VNet integration. The Consumption tier is the right answer for serverless API tiers fronting Functions backends where the rest of the stack is also serverless. EPC Group runs tier modeling during Phase 1 of the accelerator using actual traffic data — the answer depends on real consumer volume, not theoretical claims.

The self-hosted gateway is a Premium-tier feature and the right answer in three specific topologies. Topology one — hybrid backends. When the API backend services live on-premises (legacy SOAP, mainframe, legacy SQL) the gateway has to be network-adjacent to the backend for latency and security reasons; the self-hosted gateway runs inside the customer datacenter on Kubernetes or Docker. Topology two — edge deployment. Retail point-of-sale, manufacturing-floor IoT, and similar edge sites need a local API gateway terminating local APIs without the round-trip to Azure region. Topology three — multi-cloud and sovereign cloud. When APIs route to AWS or GCP backends, or when data-residency rules forbid traffic transiting Azure regions outside a specified jurisdiction, the self-hosted gateway runs in the target cloud or region. Operations follow the Kubernetes-native model — the gateway container deploys via Helm chart, configuration syncs through an outbound HTTPS channel from the APIM control plane in Azure, and observability ships back to Application Insights via the standard telemetry connector. EPC Group includes self-hosted gateway design and the first cluster deployment as part of the Phase 3 build phase for any topology requiring it.

APIM separates versioning from revisions and the distinction matters. A version is a public, consumer-visible variant of an API — typically expressed as a URL path segment (/v1/, /v2/), a header value, or a query parameter — and consumers explicitly choose which version they call. Versions are how you ship breaking changes without breaking existing consumers. A revision is an internal, non-consumer-visible iteration on a specific version — you can have ten revisions of v1 under the hood, each one a candidate deploy, and you swap which revision is current for that version without consumers seeing the change. Revisions are how you ship non-breaking implementation changes (policy tweaks, backend swaps, header additions) with safe rollback if anything regresses. EPC Group standardizes on semantic versioning for public versions, a revision lifecycle (draft → smoke-tested → current → archived) for revisions, and a deprecation policy that gives consumers a documented sunset window before a version is removed. The combination is the cleanest version-and-revision discipline most enterprise API portfolios will ever see.

The AI gateway pattern places APIM in front of Azure OpenAI Service deployments and uses the token-limit, emit-token-metric, and load-balancer policies released in 2025 specifically for this use case. The token-limit policy enforces per-subscription-key prompt-plus-completion token quotas at the gateway tier — a finance department subscription can be capped at 1 million tokens per month, an engineering subscription at 10 million, and the cap is enforced before the request reaches Azure OpenAI. The emit-token-metric policy ships prompt-and-completion token counts to Application Insights with consumer subscription, operation, and model dimensions — Power BI dashboards built on the Log Analytics workspace give finance the per-team and per-application cost attribution they need without parsing per-deployment OpenAI billing. The load-balancer policy distributes requests across multiple Azure OpenAI deployments (different regions, different model versions, different SKUs — Standard, Provisioned, Batch) with weight-based or fallback routing. Semantic caching policy uses embedding similarity to return cached responses for similar prompts. The combination delivers governance, cost attribution, and resilience as managed-service features rather than custom application code. EPC Group ships this pattern as part of any Azure OpenAI deployment that involves more than one consuming application.