Which to choose when you weigh Azure API Management against Kong Gateway open source
Start with the reason you are looking at this now. A renewal, a tier change or a data residency requirement makes Azure API Management's managed model harder to justify when the bill grows with usage or when traffic and configuration must stay inside your own boundary. Azure API Management fits teams that want a managed gateway, a developer portal and Azure-native identity without running infrastructure. Kong Gateway open source fits teams with platform engineers who are willing to operate the gateway themselves and want configuration kept in Git, applied with decK and reviewed like any other code change.
The decision turns on three questions. First, how much of the developer portal and analytics you need out of the box. Kong Gateway OSS gives you routing, load balancing, health checks, authentication and rate limiting plugins, but the portal, dashboards and most governance workflows are not part of the open-source package, so you must confirm which of them you will build, buy or run separately. Second, which features your architecture depends on. Some capabilities, including fully self-hosted control plane and data plane setups, belong to the commercial Kong Gateway Enterprise offering, and database-dependent plugins such as cluster-strategy rate limiting only run in traditional mode. Check each feature against Kong's deployment topologies documentation before you assume it is available.
Third, who operates the cluster. Ask who will patch the gateway, rotate certificates, run upgrades and respond to incidents at three in the morning. Kong's version support policy covers only Kong Gateway Enterprise, so the open-source edition has no published support window to plan around, and you should confirm your own patch cadence and staffing before committing. If your platform team can carry that load, the self-run model can lower recurring licensing cost. If it cannot, a managed option or Azure API Management may remain the better fit, and the decision should be written down with the costs and risks each path carries.
Which option fits which scenario
This table matches common situations in Azure API Management estates to the Kong Gateway option that fits best, and notes what you must add yourself. Read each row as a starting point, then confirm the gaps against your own requirements, especially where a feature needs a Kong Enterprise license.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Azure-centric team that depends on a managed developer portal | Stay on Azure API Management or add a separate portal | Kong Gateway OSS has no developer portal, so you must build or add one. Confirm the portal and sign-up workflow you need before choosing this path. |
| GitOps-driven platform team managing gateway config in Git | Kong Gateway OSS with decK | Declarative files can be kept in Git and synced with decK, which exports with deck gateway dump. Confirm your pipeline can run decK against your target nodes. |
| Air-gapped or sovereign deployment with no outbound control plane | Kong Gateway OSS in DB-less mode | DB-less mode needs no database and reads declarative files, with a read-only Admin API. Confirm which plugins you need, since database-dependent plugins require traditional mode. |
| Estate needing cluster-wide rate limiting or OAuth2 storage | Kong Gateway OSS in traditional mode, or a different gateway | Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are not available in DB-less mode. Confirm whether your OSS build covers them or whether you need an alternative such as Apache APISIX. |
| Multi-cloud estate across AWS, Azure and on-premises | Kong Gateway OSS on Kubernetes or Linux packages | Kong installs with Docker, Kubernetes or packages for several Linux distributions, so the same gateway runs in each location. Confirm container and OS versions against the release you pick. |
| Team needing built-in analytics and enterprise support SLAs | Kong Gateway Enterprise or Azure API Management | Analytics dashboards and vendor support are not part of the OSS edition. Request the written feature list and support terms from Kong before deciding. |
| Team that already runs Kubernetes ingress with Kong | Kong Gateway OSS with the Kong Ingress Controller | The Apache-2.0 Kong Ingress Controller is the official Kubernetes option. Confirm the controller version against the Gateway version you deploy. |
How decK and DB-less mode change day-to-day configuration
In DB-less mode, Kong Gateway needs no database and takes its entire configuration from declarative files, which means the gateway's routes, services, consumers and plugins can live in a Git repository next to the application code. The node exposes a read-only Admin API, so changes are made to the files and applied, not clicked into a console. decK, Kong's Apache-2.0 licensed command-line tool, syncs those files to open-source Kong Gateway and can also run deck gateway dump to export a running configuration, which is the practical starting point when you are moving existing Azure API Management definitions into Kong's format. Confirm the exact file format and dump options against the decK documentation for the version you deploy.
Compared with Azure API Management, the day-to-day workflow changes shape. Azure API Management teams usually make changes in the Azure portal or publish them through Bicep, ARM templates or an APIOps-style pipeline that extracts and reapplies definitions. With Kong, the declarative file is the source of truth, and the portal is not part of the gateway at all. Your team must therefore own the review and promotion pipeline: branch protection, peer review of route and plugin changes, a staging environment that mirrors production, and a rollback path. Decide early who approves changes to authentication plugins and rate limits, since a mistake there is as easy to merge as a typo in a route.
The trade-off is that some administrative workflows are not available in the open-source edition. Only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, so DB-less deployments need a different rate limiting design. Konnect's hosted control plane and Enterprise features may cover team-level access control, visual administration and certain analytics, but confirm these against Kong's pricing page and your own requirements before assuming the open-source edition covers them. Map each admin task your operators perform today to either a file in Git, a pipeline step or a paid feature, and price that gap explicitly.
What you must add yourself for a developer portal and analytics
Kong Gateway OSS handles the request path, but the surrounding API program is largely yours to build or assemble. The gaps below cover what consumers see, how keys are issued, how traffic is observed and how staff sign in, and each one has a different open-source option to evaluate.
Developer portal and self-service sign-up
Azure API Management ships a developer portal where consumers register, browse products and manage their own applications. Kong Gateway OSS does not include an equivalent portal in the sources reviewed here, so confirm with Kong whether any portal capability in your target edition meets your needs. If external partners must self-register, evaluate a full suite such as Gravitee or WSO2 API Manager, which include developer portals. Check whether sign-up approval, terms acceptance and account moderation are included.
API documentation publishing
Consumers need current reference documentation generated from OpenAPI definitions, kept in step with each gateway release. Azure API Management renders these in its portal from imported definitions. With Kong, you typically generate and host documentation yourself, pulling definitions from your Git repository so the published version matches the declarative configuration. For internal APIs, Backstage's API catalog can index definitions and documentation without a public portal. Decide who owns publishing and how stale docs are caught.
Subscription and key management
Azure API Management issues subscription keys tied to products, with rotation and regeneration in the portal. With Kong, consumers and credentials are created through the Admin API or decK and authenticated with plugins such as key auth, JWT or OAuth2. Note that OAuth2 depends on database-backed traditional mode, which affects your topology. A full suite like WSO2 API Manager or Gravitee covers subscription tiers and key lifecycle, so decide whether you need that workflow or only machine credentials.
Analytics dashboards and alerting
Azure API Management provides built-in analytics and Azure Monitor integration. Kong's open-source gateway exposes traffic through logging and metrics plugins, so you will assemble dashboards and alerts in your own stack, such as Prometheus and Grafana or an OpenTelemetry pipeline. Define the metrics that matter for each API, such as latency, error rate and per-consumer usage, and confirm which ones your chosen logging plugin emits. Budget for storage of access logs and a team that owns the alert rules.
Entra ID and workforce identity integration
Many Azure API Management deployments authenticate publishers and developers through Microsoft Entra ID. Kong can validate Entra-issued JWTs at the gateway using its JWT plugin, configured against your tenant's signing keys and issuer. Portal and admin sign-in are separate concerns, so check how staff authenticate to any portal, console or Admin API you deploy. Confirm token claims, audience values and key rotation handling with your identity team before cutover.
Backstage for internal API catalogs
Internal teams often need a catalog of APIs, owners and documentation more than a public storefront. Backstage, the CNCF framework for building a software catalog and docs portal, can register API definitions and link them to owning teams. It does not handle subscriptions or key issuance, so pair it with the gateway's own credential process. This is the lighter option when your consumers are internal and the gap matters mainly for discovery and ownership.
What hosting control and data location mean for regulated teams
Azure API Management is a managed service: the control plane, management APIs, developer portal and configuration store run in Microsoft's management plane. The self-hosted gateway lets you keep request traffic inside your own network, but it is offered only on specific tiers, and it still depends on connectivity to Azure to receive configuration and report status. Before you rely on that model for a regulated workload, confirm with Microsoft which tier, which region and which connectivity requirements apply to your contract, and get the answer in writing. A self-run Kong Gateway OSS deployment is different in kind: the data plane, the declarative configuration and the logs can all sit in accounts or data centers you control, with no vendor control plane in the request path.
That shift changes who owns the evidence. With Kong Gateway OSS in DB-less mode, the configuration is a set of declarative files you can keep in Git and review like any other code, and the read-only Admin API gives you a way to inspect live state. Decide where access logs, audit trails and gateway configuration are stored, who holds the keys to the repository and the Kubernetes or VM hosts, and how changes are approved. Identity also moves to your side: JWT, OAuth and ACL decisions, and the identity provider behind them, must be wired and documented by your team or your implementation partner, not inherited from a managed service.
Compliance outcomes are decided by independent auditors and certification bodies, not by the platform or by DeployOpen. What DeployOpen can do is plan the control set, configure the systems, and assemble the evidence an assessor will ask for, such as access reviews, change records, backup and restore tests, and logging coverage. Ask your assessor early which controls they expect to see for a self-operated gateway, and ask Microsoft for the current compliance documentation covering the Azure API Management tier you use, so you can compare what each side provides and where your own responsibilities begin.
Cost components on each side and what drives them
Azure API Management costs split into tier charges, networking, and the Azure services around it, while Kong Gateway OSS moves the spend to infrastructure, data stores, observability, and people. Use the cards below to build a like-for-like model, and ask your Azure account team and Kong for written quotes for the parts that depend on your traffic and feature needs.
Azure API Management tier and unit charges
Azure API Management bills by tier, and the tier you need is set by the features you rely on, such as multi-region deployment, the self-hosted gateway, virtual network integration, or the developer portal. Charges recur monthly for as long as the instance runs, so a tier chosen for one feature often carries the others with it. Ask for the exact tier, unit count and any add-on charges for your expected traffic, and confirm which features each tier includes.
Networking and data transfer on Azure
Traffic that leaves Azure, crosses regions, or passes through virtual network connections can add recurring egress and gateway networking charges that sit outside the API Management line item. Large response payloads and cross-region calls to back ends make this cost grow with usage rather than with the number of APIs. Model your outbound volume per API and ask Azure for the networking charges that apply to your topology.
Azure-side services the gateway depends on
Many Azure API Management deployments also rely on services such as Entra ID for sign-in, Application Insights or Log Analytics for logs and metrics, Key Vault for certificates and secrets, and private DNS. Each adds its own recurring charge and its own configuration effort. List every service your APIs touch today, because some of them will need an open-source equivalent after the move.
Kong Gateway OSS infrastructure
Running Kong Gateway OSS means paying for compute and storage for data plane nodes in your own cloud account or data center, sized for peak request rate, latency targets and high availability across zones. These costs are recurring and scale with nodes, not with API calls. Confirm the node count and size needed for your peak traffic in a load test, then price it against your own provider's rates.
Load balancers, databases and observability
Kong in traditional mode needs a database, and database-dependent plugins such as cluster-strategy rate limiting and OAuth2 only work in that mode. DB-less mode removes the database but moves configuration into files in Git and a read-only Admin API. Load balancers, database hosting or backup, and log and metric pipelines are recurring items you carry yourself. Decide the mode first, because it changes these line items more than any other choice.
Portal build-out and the platform team
Kong Gateway OSS does not include the developer portal or the analytics dashboards that Azure API Management provides, so you will need to build or buy them. Build-out is largely one-time engineering, while maintenance is recurring. The bigger recurring cost is the platform team that upgrades, patches and supports the gateway, and a Kong Enterprise licence applies only if you need features such as the Enterprise-only capabilities listed in the pricing and version documentation. Ask Kong which features you need and whether they are in the open-source edition.
What moving from Azure API Management to Kong involves
The sequence moves your APIs, policies, consumers and traffic from Azure API Management to self-run Kong Gateway in stages, so each API can be checked and rolled back on its own. The output is a declarative Kong configuration in Git, a tested staging environment, and a DNS cutover that retires Azure resources only after traffic has moved.
Inventory APIs, policies and consumers
Start by listing every API, operation, product, subscription, named value and policy in each Azure API Management instance, and note which APIs carry rate limits, JWT validation, header or body transformations, or custom inbound logic. Export the configuration with the APIOps tooling and record which policies are defined at the global, product, API and operation scopes. The step is done when every API has a row in a migration sheet with its policies, upstream URL, owner and consumer count.
Map policies to Kong plugins
Work through the inventory and map each Azure policy to a Kong plugin, such as rate limiting, JWT, key authentication, request transformer or response transformer, and record the plugin name and settings beside each policy. Policies with no direct plugin, such as complex XML-based logic, custom expressions or calls to external services, need a custom plugin, a route-level workaround or a change in the upstream service, and each one should be costed as separate work. The step is done when every policy is either mapped, assigned to custom work with an owner, or marked for retirement with the API owner's approval.
Build declarative configuration in Git
Write the Kong configuration as declarative files, one service and route set per API, and use decK to dump the current state and sync it to a Kong Gateway instance. DB-less mode keeps the configuration in files that can be reviewed in pull requests, but it exposes only a read-only Admin API and does not support database-dependent plugins such as cluster-strategy rate limiting or OAuth2, so confirm early whether any mapped policy needs those plugins and choose traditional mode if it does. The step is done when the files are in version control, a diff against the running staging gateway is empty, and the team can reproduce the deployment from a clean checkout.
Test each API in staging
Deploy the configuration to a staging gateway and run functional tests for every route, including authentication failures, rate limit responses, transformed payloads and error bodies, and compare the responses with those Azure returns for the same requests. Load-test the APIs that carry the most traffic, and confirm that upstream health checks behave as expected when a backend is unavailable. The step is done when every API has a passing test set, and the API owners have signed off on any intentional differences in headers, status codes or error formats.
Migrate subscriptions and consumer credentials
Azure subscription keys and Entra ID tokens do not carry over as-is, so decide for each consumer group whether to re-issue Kong consumer credentials, such as API keys or JWT credentials, or to keep an existing identity provider in front of Kong and issue tokens from it. Create Kong consumers that match your product and subscription tiers, and provide consumers with a dated plan for switching credentials, since Kong does not import Azure developer accounts. The step is done when every active consumer has a new credential, or an identity-based path that does not require one, and a record of which consumers have confirmed the change.
Run parallel traffic
Send a small share of real traffic through Kong while Azure continues to serve the rest, using DNS weighting, a load balancer or a client-side switch, and compare logs, latency, error rates and rate limit counts between the two paths. Watch for consumers that still call the Azure hostname directly, and keep rollback instructions ready for each API. The step is done when the Kong path shows error rates and latency that the owners have accepted, and the Azure path shows no unexpected traffic from consumers that have already switched.
Switch DNS API by API
Move each API to its Kong hostname one at a time, starting with the lowest-risk APIs, and lower the DNS TTL in advance so that a rollback takes effect quickly. Update the public and partner documentation, notify consumers of the new endpoint, and keep the Azure route in place until the owner confirms the switch. The step is done when every API resolves to Kong, the Azure gateway receives no production traffic, and the change log records the date and owner for each cutover.
Retire Azure resources and keep evidence
After the final cutover and an agreed observation period, export the last Azure configuration and logs for your records, remove consumer access, and decommission the API Management instance, its networking and any associated resources, confirming with your finance and compliance teams what must be retained. Confirm with your own auditors and Microsoft's current terms what data and logs have to be kept, and what to ask for in writing from Microsoft when you cancel. The step is done when the Azure instance is deleted, the retained evidence is stored in your own environment, and the migration record is signed off.
Questions buyers ask before choosing Kong over Azure API Management
How much effort does a move from Azure API Management to Kong Gateway take?
Effort depends mainly on how many APIs, policies and subscriptions you have, and how many of those policies map cleanly to Kong plugins. Simple routing and JWT validation translate quickly. Custom policy XML, named values tied to Azure services and developer accounts take longer because each needs a decision and a test. Ask any partner to size the work from an export of your APIs and policies, not from the number of APIs alone. Kong's open-source edition is Apache-2.0 licensed, so the software itself carries no license cost, while the engineering, testing and cutover work is the main one-time expense.
Can an internal team run Kong Gateway open source on its own?
A team with container, Kubernetes or Linux operations skills and an API gateway owner can run Kong Gateway open source, provided it accepts that it operates the gateway, its upgrades and its monitoring itself. The open-source edition installs with Docker, Docker Compose, Kubernetes or system packages for Ubuntu, RHEL, Debian and Amazon Linux. DB-less mode keeps configuration in declarative files that can live in Git, which simplifies operations. Confirm internally who owns on-call, certificate rotation and upgrades before committing, because no vendor support window applies to the open-source edition.
How long does a migration from Azure API Management to Kong take?
No fixed duration applies, because the timeline depends on the size of the API estate, the complexity of policies, the number of consuming applications and how many can change their endpoints on the same day. Teams usually move APIs in waves and keep Azure API Management running until each wave passes testing. Ask for a plan that lists waves, cutover steps, rollback criteria and the dependency on consumers. A written scope agreed before work starts is the reliable way to fix dates.
Which Kong Gateway features need the paid Enterprise edition?
Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane belong to the commercial Kong Gateway Enterprise offering, and Kong Gateway 3.10 removed the unlicensed free mode from Enterprise. The open-source edition includes routing, load balancing, health checking, JWT, basic auth, OAuth and ACL authentication, rate limiting and transformation plugins, DB-less declarative deployment and hybrid control plane and data plane separation. Only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, so check that each policy you rely on works in your chosen mode. Confirm the exact edition for every feature against Kong's current documentation before you design around it.
Does Kong Gateway open source include a developer portal?
No. Kong Gateway open source is a gateway and does not ship a developer portal, so API documentation, sign-up, subscription management and key issuance must come from another system. Options include building a portal on your own stack, or using a tool such as Backstage for an internal API catalog. Kong's declarative configuration and decK help keep routes and plugins in version control, but they do not replace the portal's publishing and onboarding functions. Plan this work separately from the gateway migration, and migrate existing developer accounts and keys with care.
How do you handle analytics and monitoring after leaving Azure API Management?
Azure API Management includes built-in analytics and diagnostics, and Kong open source does not provide an equivalent dashboard out of the box. You need to decide how logs, metrics and traces leave the gateway and where they are stored, usually with a self-hosted observability stack. Define the dashboards and alerts that replace the ones your operations and finance teams use today before cutover. Ask any implementation partner to list each Azure metric or report you depend on and the replacement for it.
What does the migration need from our side, such as identity mapping and test coverage?
You need to supply platform skills, a named owner for the gateway, and decisions on identity. If Azure API Management validates tokens issued by Microsoft Entra ID, you must map those validations to Kong's JWT or OAuth plugins and confirm how signing keys and issuers are configured. You also need test coverage: automated tests that replay representative traffic against both gateways, plus contract tests for each consumer. Gaps in test coverage are the most common source of cutover surprises, so agree the test scope in writing before work begins.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Azure API Management vs Kong Gateway open source, we start with the routes, policies and plugins you actually depend on, then decide with you where Kong Gateway OSS fits and where paid Kong editions or other gateways would be needed.
How we scope
- Inventory which Azure API Management policies, products and subscriptions your APIs depend on today.
- Map each policy to a Kong plugin, and flag any gap that needs a custom plugin or a different gateway.
- Confirm with Kong which features need DB-less mode and which need traditional mode with a database.
- Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope.
How we build
- Stand up Kong Gateway OSS with Docker, Kubernetes or Linux packages in your chosen environment.
- Convert routes, plugins and consumers into declarative files kept in Git and synced with decK.
- Test authentication, rate limiting and transformations against representative traffic before any DNS change.
- Add the logging, metrics and portal tooling your team needs, since Kong OSS does not include a developer portal.
How we hand over
- Document the gateway topology, configuration repository, deployment steps and rollback procedure.
- Provide a runbook for certificate rotation, upgrades within the 3.9 release line and plugin changes.
- Walk your platform and security teams through the configuration workflow and access controls.
- Deliver evidence of configuration, testing and access controls that your own auditors can review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover planned version upgrades, security patch reviews and changes to routes or plugins.
- Ask any provider to confirm the support window for the open-source release you run, as Kong publishes none for OSS.
- A quote follows from the written scope, so ask for line items for build, testing, handover and retainer.
