An API management platform bundles the gateway with the parts that don't fit neatly inside routing rules: developer portals, API key issuance, usage analytics, and monetisation. The three products that come up in almost every enterprise conversation — Kong, Apigee, and Azure API Management — take noticeably different approaches, and picking between them is less about feature checklists and more about which cloud and which operating model you're already committed to.
Kong: the plugin-first gateway
Kong is built on top of Nginx/OpenResty and is architected around plugins — rate limiting, auth, transformation, logging are all plugins you attach to a route or service, including ones you write yourself in Lua. This makes Kong the most flexible of the three and the easiest to self-host or run in Kubernetes via the Kong Ingress Controller. Kong Gateway (the open-source core) covers routing, load balancing, and a wide plugin ecosystem for free; the commercial Kong Konnect layer adds the developer portal, analytics dashboards, and multi-region management. Teams choose Kong when they want to run the gateway themselves, close to their own infrastructure, without being tied to a specific cloud.
Apigee: full API lifecycle management
Apigee (part of Google Cloud) leans hardest into the "management" half of API management — API proxies with declarative policy chains (XML-configured, not code), a strong developer portal out of the box, detailed analytics on API consumption per app and per developer, and built-in monetisation packages for charging partners by usage tier. Apigee's policy model is more rigid than Kong's plugin model but that rigidity buys consistency across large API programs with many teams publishing APIs independently. It's the heaviest of the three operationally and priced accordingly — it tends to show up in large enterprises with dedicated API platform teams, not in a five-person startup's stack.
If external partners need to self-serve API keys, read docs, and see their own usage dashboards, Apigee's portal tooling is mature enough that teams often adopt it just for that, even when the gateway features alone wouldn't justify the cost.
Azure API Management: the cloud-native default
Azure APIM is the natural choice for teams already committed to Azure — it integrates directly with Azure AD for auth, Application Insights for telemetry, and Azure Functions/App Service for backends, with policy defined in XML applied at the inbound/outbound/backend/error stages of the request pipeline. Its consumption tier makes it viable for small workloads at low cost, which Kong Konnect and Apigee don't really compete on. The tradeoff is that APIM's policy language is less expressive than Kong's plugin ecosystem for anything unusual, and you're implicitly betting your API layer on staying in Azure.
<inbound>
<rate-limit-by-key calls="100" renewal-period="60"
counter-key="@(context.Subscription.Id)" />
<validate-jwt header-name="Authorization"
failed-validation-httpcode="401">
<openid-config url="https://login.microsoftonline.com/common/.well-known/openid-configuration" />
</validate-jwt>
<base />
</inbound>Self-hosted vs. fully managed
Kong Gateway can run entirely on your own infrastructure with no dependency on Kong's cloud offering — attractive for teams with strict data residency requirements or an existing Kubernetes platform team. Apigee and Azure APIM are managed services by default (Apigee has a hybrid deployment option, but it's the exception, not the norm). The self-hosted route buys control and avoids vendor egress costs, at the price of owning upgrades, scaling, and on-call for the gateway itself.
The features that differ most between these platforms — developer portal quality, analytics depth, monetisation billing hooks — rarely show up in a routing-and-auth proof of concept. Evaluate against the actual API program you're running, not just the request path.
Picking one
If you're already deep in Azure and need something adequate without much operational overhead, APIM is the default. If you're running a large external API program with partners who need self-service onboarding and usage-based billing, Apigee's lifecycle tooling earns its cost. If you want maximum control, plan to self-host, or need a plugin architecture flexible enough for unusual requirements, Kong is the strongest fit. Very few teams need to evaluate all three from scratch — the cloud and operating model you're already in usually narrows it to one realistic choice.
| Platform | Strongest for | Model |
|---|---|---|
| Kong | Self-hosted, plugin flexibility | Open-source core + commercial Konnect |
| Apigee | Large partner API programs, monetisation | Managed (GCP), hybrid option |
| Azure APIM | Azure-native stacks, low ops overhead | Fully managed, consumption tier available |
Wrapping up
These platforms overlap on the basics — routing, auth, rate limiting — so the deciding factor is almost always outside the gateway itself: which cloud you're in, whether you need a serious developer portal, and whether self-hosting is a requirement or a preference. Match the platform to the API program, not the other way round.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.