Asking the selection question the right way

Routing, transformations and monitoring integrations are available in all three solutions. Selection depends on how these capabilities work together in the intended environment: deployment, configuration changes, extensions and onboarding application teams.

Deployment models: who operates what

Tyk offers an open-source gateway alongside the commercial Self-Managed and Tyk Cloud offerings [1]. Tyk Cloud can be combined with gateways operated by Tyk or by your own team [5]. On Kubernetes, Tyk Operator supports the management of API definitions [1].

Kong Gateway is designed for hybrid environments. It runs self-managed via Docker or on Kubernetes with the Kong Ingress Controller. With Konnect there is additionally a model in which the control plane runs as SaaS while the data planes are either managed or self-hosted [2].

Azure API Management is a managed Azure service. For hybrid scenarios, a self-hosted gateway runs as a container controlled by a central APIM instance [3]. Developer portal, workspaces, networking and self-hosted gateway availability depend on the selected tier [8].

If gateways need to run close to workloads across several environments, compare data plane placement and operational effort. Tyk, Kong and Azure API Management offer different hybrid options. Where Azure is already the target platform, include the effort of integrating with existing services in the assessment.

Configuration as code and API ops

Keeping configuration changes traceable

As API and team numbers grow, exclusively manual changes become harder to trace. Versioned configurations and reviews support reproducible operations. Check which parts of the platform can be managed as code.

How the three solve it

Tyk. On Kubernetes the Tyk Operator takes on this task, and API definitions can be created on the basis of OpenAPI documents [1].

Kong. decK manages declarative configurations and supports comparison and synchronisation with supported gateway deployments. When using it in CI pipelines, check compatibility with the deployment model and required features [9].

Azure API Management. Azure API Management is controlled through the management plane: Azure portal, CLI, PowerShell and a REST API through which the instance can also be managed from pipelines. The behaviour of individual APIs is controlled by policies, which apply as statements globally, per workspace, product, API or operation [3].

Version gateway configuration and review changes before delivery. Keep credentials in an appropriate secrets management system. A traceable approval process helps teams detect drift and roll out changes in a controlled way.

Plugin ecosystem and extensibility

Tyk. Tyk relies on custom plugins that hook into defined points of the middleware chain; Go is recommended, and JavaScript, Python, Lua and, via gRPC, further languages are also supported [4].

Kong. Kong extends its gateway through plugins from the Kong Plugin Hub, among other things for authentication, traffic control, analytics and monitoring [2].

Azure API Management. APIM takes a different approach: instead of a plugin model, behaviour is adapted through policy statements, and extension runs through integration with Azure services such as Key Vault, Monitor and Entra ID [3].

Whoever plans a lot of custom logic in the gateway should assess this difference early: writing a plugin in your own language is something different from modelling logic in policy definitions.

Team onboarding

The path of a new team

API-producing teams need roles, approvals and a reliable publishing path. A developer portal primarily helps API consumers with documentation, registration and access. Assess these two journeys separately during selection.

What the three offer

Tyk. Tyk Dashboard provides a management interface and APIs. Roles and API ownership can separate access between teams; the available capabilities depend on the licence and offering [6]. API definitions can be published through automated workflows.

Kong. Kong Manager is also available as an open-source interface. Advanced management features such as role-based access control depend on edition and licence [2, 7]. Tools such as decK support automated publishing workflows [9].

Azure API Management. Workspaces let teams manage their own APIs within shared guardrails. The developer portal provides documentation and access for API consumers. Check the availability of both features in the intended tier [3, 8].

In any case it is worth playing through the onboarding of a new team once in full before the decision is made.

Licence and OSS models, roughly

Tyk. Tyk provides its gateway as open source, Self-Managed and Cloud are the commercial offerings [1].

Kong. Kong Gateway and Kong Manager are also available as open source. Advanced management and security features, such as RBAC in the enterprise offering, need to be assessed against the required edition and licence [2, 7].

Azure API Management. Azure API Management is a proprietary Azure service in several tier groups (Classic, V2, Consumption); the developer portal itself is open source [3].

Compare licence and infrastructure costs, support, required features and internal operational effort for the intended operating model. Features and terms can change; selection should use the actual edition and current tier being offered.

CriterionTykKong GatewayAzure API Management
Self-managed operation Open-source gateway and Self-Managed Docker, Kubernetes with Ingress Controller Service runs in Azure; self-hosted gateway as a container for hybrid scenarios
Managed variant Tyk Cloud: managed control plane, managed or self-hosted gateways Konnect: control plane as SaaS, data planes managed or self-hosted Managed Azure service; capabilities depend on tier
Configuration as code Tyk Operator on Kubernetes, OpenAPI-based API definitions decK with declarative state files Management plane via CLI, PowerShell and REST API; policies per scope
Extension Custom plugins in Go, JavaScript, Python, Lua, further languages via gRPC Plugins from the Kong Plugin Hub Policy statements and integration with Azure services
Licence model Open-source gateway, Self-Managed and Cloud commercial Open-source core, enterprise features commercial Proprietary service in tier groups Classic, V2, Consumption

Properties from vendor documentation, checked on 6 September 2026. Capabilities and deployment options depend on edition and tier.

What operations show and the matrix does not

Experience across API projects. Our experts' experience spans migrations between different infrastructures and gateway solutions, as well as transitions from centralised to decentralised architectures. Our knowledge of gateway tools includes Tyk, Axway, Kong and Apigee.

Selection also needs to account for the path into operation: How will interfaces remain usable during a migration? How will security requirements be implemented in the target architecture? How can configurations be checked and changes rolled back when needed? These questions belong in selection and migration planning. A feature matrix alone does not answer them.

De-risking the decision

A proof of concept with representative APIs and an application team should exercise publishing, changes, security checks and fallback procedures under realistic conditions. Agree on evaluation criteria before starting.

It surfaces exactly the friction points that later define operations: how the configuration can be versioned, how misconfigurations become visible and how much platform knowledge a team needs to work independently.

Key takeaway

Choose the gateway against your architecture, security requirements and operating workflows. Check who runs the platform, how changes are approved and how new teams publish APIs. A proof of concept adds verifiable results to documented capabilities.

What you can decide afterwards

  • Which operating model you can sustain: your own clusters, a control plane as SaaS or a managed Azure service.
  • How gateway configuration gets into your repository and who reviews it before it goes into production.
  • Which representative APIs, team and success criteria you use for the proof of concept.

Frequently asked questions

Which of the three is best?

The right choice depends on requirements: features, security controls, operations, team workflows and cost. A shortlist based on these criteria can then be evaluated with representative APIs.

What is the difference between an API gateway and API management?

The gateway is the runtime component in the request path. API management is the platform around it, with a developer portal, versioning and analytics. The gateway enforces what the platform defines.

Why do you not quote prices?

Prices depend on edition, usage, support and operating model and can change. Compare current offers for the same requirements and include your own operational effort.

Is a gateway enough as API security?

No. A gateway can check identities, limit requests and validate schemas. The application must also ensure that a user may perform the requested action on the specific record. Missing this check creates a Broken Object Level Authorization (BOLA) (opens in a new tab).

Can we switch later?

Versioned configurations make a gateway change easier. Policies, extensions, identities and the behaviour of existing API clients still need to be checked. Plan tests, a controlled cutover and a rehearsed fallback procedure.

Sources

Read on

Expertise API Engineering Insights Manage API migrations in controlled steps Insights Internal Developer Platform Workshop Practical API security testing