Azure API Management vs Apache APISIX: which fits your API program
Azure API Management fits when Microsoft should run the gateway, portal and management plane for you, and APISIX fits when your team is ready to run the gateway itself and keep it portable. If your renewal, tier change, data residency rule or Azure lock-in concern is pushing you to re-evaluate, the decision turns on three questions: who will operate the gateway, where traffic and configuration must live, and whether you need a developer portal on day one. Azure API Management suits organizations that want managed operations, Entra ID alignment, Azure-native networking and a built-in developer portal without assembling those pieces themselves. Its policy model is the main thing to map if you leave, because APISIX expresses the same intent through plugins, not policy XML.
APISIX fits when you want a self-run gateway built on NGINX and etcd, configuration that updates without restarts, and a plugin model you can extend in Lua or through plugin runners in Java, Go and Python. It also fits when traffic or configuration must stay in a data center, a non-Azure cloud or an air-gapped network. The openid-connect plugin can integrate with Microsoft Entra ID, so identity alignment does not require staying on Azure. The trade-off is ownership: you will carry upgrades, certificates, etcd operations and monitoring, and APISIX does not ship a developer portal with the gateway. Confirm the release and support model in the APISIX downloads page before you pick a version, because that page does not mark any release as long-term support.
Before you commit, run a short assessment against your own estate. List every API, its consumers and the Azure features it depends on, including virtual network integration, managed identities and diagnostics. Then decide whether the developer portal is a day-one need or can follow the gateway cutover. If you choose APISIX, ask your team or partner to confirm which of your policies have direct plugin equivalents and which need custom code, and name an owner for on-call and patching. A pilot with two or three low-risk APIs will show whether your team can carry the operating load before you move the rest.
Which option fits which scenario
This table maps common Azure API Management situations to the option that usually fits better, with a one-line reason for each. Read it as a starting point for your own estate, then check the reasons against your traffic, team and compliance constraints. The main takeaway is that APISIX suits teams willing to run their own gateway, while Azure API Management suits teams that want Microsoft to run the management plane.
| Scenario | Better fit | Reason |
|---|---|---|
| Single-cloud Azure estate with Entra ID | Azure API Management | Native Entra ID integration, Azure networking and Azure Monitor keep operations inside one vendor's tooling. |
| Multi-cloud or on-premises traffic | Apache APISIX | A self-run gateway can sit in any cloud or data center, and its decoupled mode keeps the data plane close to the traffic it serves. |
| Air-gapped or strict sovereignty requirements | Apache APISIX | Standalone or decoupled deployments need no SaaS control plane, though you must confirm which Azure-hosted components you still depend on. |
| No platform engineers on the team | Azure API Management | Microsoft operates the managed gateway and portal, while APISIX requires your team to run etcd, upgrades and certificate rotation. |
| Large external developer program with a portal | Azure API Management | The managed developer portal and subscription handling need less build work than assembling a portal around APISIX. |
| High-throughput east-west internal APIs | Apache APISIX | Running the gateway beside services avoids an extra managed hop, and you can size and tune it to your own load tests rather than tier limits. |
| Mixed fleet with custom Lua or Go logic | Apache APISIX | Plugins written in Lua or through plugin runners in Java, Go and Python let engineers extend the gateway in code. |
Where traffic, configuration and identity live
Azure API Management and a self-hosted APISIX cluster place the gateway, the configuration store and the identity dependencies in different spots. Each placement changes where traffic and logs sit, who can change routes and policies, and which identity system your consumers and administrators depend on. Check these four points before you map any policy to a plugin.
Data location for traffic and logs
In Azure API Management, request and response data passes through Azure-hosted gateways in the region you select, and diagnostics and logs flow to Azure services you configure. With self-hosted APISIX, the gateway runs in your own VMs, Kubernetes cluster or data center, so client payloads, access logs and tokens stay where you put them. Confirm which regions your APIs will serve from, where your log sink lives, and whether any plugin sends telemetry or payloads to an external service.
Control plane location
Azure API Management keeps its management plane in Azure, so publishing, policy changes and subscription management depend on Azure's control services. In APISIX, the traditional mode keeps the Admin API on port 9180 next to the gateway, decoupled mode shares one etcd cluster between control and data planes, and standalone mode reads a YAML or JSON file with no etcd at all. Pick the mode before you design network rules, because it decides which hosts must reach each other and which system holds the authoritative configuration.
Hosting models for each side
Azure API Management offers managed tiers, and its self-hosted gateway runs on your infrastructure while still connecting to Azure. APISIX has no managed Azure tier from the project itself, so you own the VM images, Kubernetes manifests, etcd backups, certificates and upgrades, or you buy operations from a vendor. Ask which hosting model your operations team can staff for 24 hours, and who gets paged when etcd or a gateway node fails.
Identity under Entra ID or another IdP
Azure API Management usually validates tokens issued by Microsoft Entra ID, which keeps workforce and partner identity in one tenant. The APISIX openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows. Choose the identity provider that your consumers already use, then test each flow, because moving off Entra ID changes token issuers, claims, client registrations and developer sign-in.
Compliance evidence you must produce
Moving the gateway moves the evidence trail with it. Access reviews, change records for routes and plugins, key rotation logs, and retention settings for access logs must now come from your own systems rather than Azure's audit features. DeployOpen can prepare the controls, configuration and evidence for an assessment, but it does not issue audit reports or certifications. Ask your independent auditor which evidence they will accept for the gateway before cutover.
What running APISIX outside Azure actually requires
The first decision is which deployment mode to run, because it determines what you operate beyond the gateway itself. APISIX supports three modes according to its deployment modes documentation. In *traditional* mode, the data plane and control plane run together on the same nodes. In *decoupled* mode, separate data plane and control plane nodes share one etcd cluster, which suits teams that want to keep administrative access away from the traffic path. In *standalone* mode there is no etcd at all: the configuration lives in a YAML or JSON file (conf/apisix.yaml or conf/apisix.json), or it is pushed through the API. A small team with a single region and a clear owner for routes often starts in standalone mode, and a platform team managing many gateways usually needs decoupled mode. Confirm the mode against the documentation before you size anything, because etcd carries a cluster to maintain, back up and monitor.
In traditional and decoupled modes, etcd is the configuration store that every gateway node reads from, so its health directly controls whether route and plugin changes propagate. Plan for etcd backups, quorum across failure domains and certificate rotation for its peer and client connections. In file-driven standalone mode, APISIX checks the file every second and hot-reloads changes without a restart, which removes etcd from the operating model but moves the change process into your Git workflow and deployment pipeline. Whichever mode you choose, the Admin API on port 9180 must never be reachable from client networks. Restrict it to a management subnet or bind it to localhost, replace the default admin key before go-live, and log every call that changes routes or plugins. Client traffic arrives on port 9080, so keep those two listeners on separate network paths.
Before you accept any topology, have the platform team check it against the APISIX deployment modes documentation and the port defaults listed there. Ask them to write down the mode, the number of etcd members and their locations, which ports are open between each network zone, and who may call the Admin API. Then test the failure cases: stop one etcd member, rotate the Admin API key, and edit the standalone file while traffic flows. Each test shows whether your runbook is accurate. The traffic and control paths also need to reach your identity provider for the openid-connect plugin, and the team that owns that connection should sign off on it. Treat this review as the input to your cost estimate, since the etcd cluster, the file pipeline and the hardening work all carry staffing time that a quote should itemize.
What each option costs to own, by component
Azure API Management charges by tier and unit, while self-hosted APISIX has no license fee under Apache-2.0 but moves the infrastructure, etcd, observability and staffing costs onto your budget. The cards below separate one-time costs from recurring ones and list what to ask for before comparing totals.
Azure API Management tier and units
Azure charges by the pricing tier you select and, for some tiers, by unit count, and changes between the classic and v2 tiers affect what you pay for scale and features. Ask whether the quote covers each region you need, how many units a peak forecast requires, and whether the tier includes the features your policies depend on. Tier charges recur monthly for as long as the service runs, so the main levers are the tier choice and unit count. Confirm current rates on the Azure pricing page rather than relying on older figures.
Premium features for multi-region and self-hosted gateway
Multi-region deployment and the self-hosted gateway are features you may only get in higher tiers, so they can change which tier you need. If your architecture depends on either, the tier choice becomes a fixed recurring cost that a self-hosted APISIX cluster does not carry. Check with Microsoft which tier includes the self-hosted gateway and whether it needs continuous outbound connectivity to Azure. Put this line item in the quote explicitly so it is not hidden inside a general tier figure.
Networking and data transfer
Traffic leaving Azure, traffic between regions and virtual network integration can add charges that scale with request volume and response size. A self-hosted gateway shifts this cost to your own network and cloud contracts, which may be cheaper or more expensive depending on where your consumers sit. Estimate outbound volume per API from your current logs, then ask Microsoft and your network provider to price the same flows. This cost recurs and rises with traffic growth.
APISIX software and support
Apache APISIX is licensed under Apache-2.0, so the software itself carries no license fee. Your recurring costs become the compute, load balancers, storage and staff that run it, plus any commercial support contract you choose to buy from a vendor. Ask any support provider for the scope of covered versions, response commitments and whether upgrades and security patches are included. Treat these as separate line items from the software license, since the license cost is zero by definition.
Compute, load balancers and etcd cluster
A production APISIX deployment runs gateway nodes behind a load balancer and, in traditional or decoupled mode, an etcd cluster that stores configuration. Each of these is compute you provision, patch and back up, and etcd needs careful sizing for its disk and quorum behavior. The one-time cost is the initial build and hardening; the recurring cost is the instances and their monitoring. Ask your team or implementation partner to size gateway nodes, etcd members and load balancer tiers for your peak traffic and failover target.
Observability, certificates and the platform team
Logging, metrics, tracing, certificate issuance and renewal, and on-call coverage are costs that Azure partly absorbs in its managed service and that you must fund yourself with APISIX. The largest recurring item is usually people: the platform engineers who upgrade APISIX, tune plugins and answer incidents. Ask how many hours per month your team expects to spend on operations, and what a fixed-scope implementation covers versus an ongoing retainer. Azure's built-in monitoring may not match what you need, so confirm what you will rebuild.
How a move from Azure API Management to APISIX runs
The sequence moves APIs, policies, keys and traffic to self-hosted Apache APISIX one API at a time, so each cutover can be checked and reversed before the Azure side is retired.
Export APIs, policies and products
Your team extracts the API definitions, policy XML, products, named values and subscriptions from the Azure API Management instance, usually with the open-source APIOps tooling covered in the export guide. Secret values are not included in a plain export, so record where each one lives. The step is done when every API in scope has a saved definition and a list of policies attached to it, and someone other than the author has reviewed the inventory.
Map each policy to an APISIX plugin
Working from the export, the platform team lists every inbound, backend and outbound policy and matches it to an APISIX plugin, such as a rate limit, JWT validation, header transformation or response rewrite. Some policies will have no one-to-one plugin and need a custom Lua or plugin-runner implementation, or a change to the upstream service. The step closes with a mapping sheet that flags each policy as direct, partial or custom, with the owner for each gap. Confirm plugin behavior against the current APISIX documentation, not from memory.
Stand up a non-production APISIX cluster
Your team deploys APISIX in a non-production environment inside your own cloud account, data center or network, and chooses the deployment mode that matches your operating model: traditional or decoupled with etcd, or standalone with a file-driven configuration. Admin API access, TLS certificates and identity provider connections are set up here. The step is complete when test routes respond on the client port, the Admin API is restricted to administrators, and the configuration is kept under version control.
Verify mapped policies behave the same
Each mapped policy is tested against APISIX with the same requests and expected responses that your Azure configuration produces, including error codes, rate-limit headers, token rejection and transformed payloads. Differences are logged, fixed in the mapping or accepted by the API owner in writing. This is the point where you confirm that every mapped policy behaves the same under APISIX, since plugin defaults and policy semantics do not always match. The step is done when the test results for each API are signed off by its owner.
Move keys, subscriptions and developer access
Consumer applications, subscription keys and developer accounts are migrated or re-issued according to your plan. Credentials that cannot be copied are re-created, and consumers receive a dated cutover notice with the new endpoint and credential steps. Ask your team to confirm how each consumer group authenticates today so no integration is left without access at switch time. The step closes when a reconciliation report shows every active consumer mapped to an APISIX consumer or identity provider client.
Run parallel traffic and switch DNS API by API
Traffic is sent to both gateways for a chosen API, with the Azure route remaining the authoritative path until results match. DNS or routing is then switched for that API alone, and the old route is kept available for rollback. The same pattern repeats for each API in the order agreed with the owners. The step is done for an API when its traffic, error rates and consumer reports stay within the thresholds the owner agreed before the switch.
Decommission the Azure instance
Once every API has been switched and the rollback window agreed in the plan has closed, the Azure API Management instance is disabled, its diagnostics and logs are archived under your retention rules, and the subscription resources are removed. Confirm with your compliance owner which records must be kept before deletion. The step is complete when no production traffic reaches Azure, the archive is verified, and the decommission is recorded in your change system.
Questions buyers ask before choosing APISIX over Azure API Management
How much effort does a switch from Azure API Management to APISIX take?
The effort depends mostly on how many APIs, policies and consumers you have, not on the gateway itself. Each API needs its routes, upstreams and authentication rebuilt as APISIX routes and plugins, and each policy in Azure API Management needs a mapped plugin or a custom one. Rate limits, JWT validation and header transformations usually map cleanly to built-in plugins, while policies with complex XML logic, custom expressions or backend calls need review and testing. Subscriptions, keys and developer accounts are a separate workstream because they cannot be copied as-is. Ask for a written inventory of APIs, policies and consumers before estimating anything, since that inventory is what sets the work.
Can our own team migrate to APISIX without outside help?
A team with gateway, networking and Kubernetes or Linux operations experience can run a pilot alone, especially for a small number of APIs. Larger estates benefit from an outside partner for policy mapping, test harnesses, cutover planning and hardening. Be honest about skills in NGINX configuration, etcd operations, TLS certificate handling and the Admin API. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, typically under a fixed scope agreed in writing before work starts, so you can keep ownership of the result while buying only the parts you need.
How long does an APISIX migration take in practice?
No migration duration has been established for this comparison, so treat any number you see elsewhere with caution. Timing depends on API count, policy complexity, the number of consumers that must re-issue credentials, change control windows and how many environments you run. A phased approach, moving API by API and switching DNS one route at a time, makes the timeline easier to predict. Ask any implementation partner, including DeployOpen, for a written scope with deliverables and milestones, and check that it names the environments, cutover steps and rollback plan included.
What does running APISIX need from our staff after go-live?
After go-live, someone must own the gateway like any production infrastructure. The recurring work includes patching the APISIX release and its dependencies, operating the etcd cluster in traditional or decoupled mode, managing TLS certificates, reviewing plugin changes, monitoring latency and error rates, and handling incidents. Standalone mode removes etcd but moves configuration into version-controlled files, which suits GitOps teams. Plan for an on-call rota, a runbook, and a named owner for plugin code, including any custom Lua or plugin-runner code written in Java, Go or Python. Confirm which of these your team already covers before you commit.
Does Apache APISIX have long-term support releases?
The APISIX downloads page does not mark any release as long-term support, so you should not assume an LTS line exists. The current releases listed on that page are 3.19.0, released on September 28, 2026, and APISIX Ingress Controller 2.2.0, released on August 18, 2026. Ask the Apache APISIX project and your own support provider how long each minor version receives security fixes, how upgrades are staged, and whether a commercial support option is available to you. Build your upgrade cadence around those answers and record them in your change policy.
Do we need a developer portal if we move to APISIX?
APISIX is a gateway and does not ship a developer portal, so you will need one only if external or internal consumers must discover APIs, sign up and manage keys themselves. Options include a portal from another self-hosted platform such as Gravitee or WSO2 API Manager, or Backstage's API catalog for internal APIs. If your consumers rely on Azure API Management's portal today, list those workflows first, because replacing them is a separate project from moving traffic. Confirm which portal features your consumers actually use before choosing a path.
How does Entra ID login work through the APISIX openid-connect plugin?
The openid-connect plugin lets APISIX act as the relying party for an OpenID Connect provider such as Microsoft Entra ID, and it supports authorization code, client credentials, token introspection and PKCE flows. You register an application in Entra ID, configure the discovery URL, client ID, client secret and redirect URI in the route's plugin settings, and choose which flow each route uses. For machine-to-machine APIs, token introspection or JWT validation at the gateway is usually the cleaner path. Test token audience, issuer and expiry handling in a staging tenant, and confirm the exact configuration keys against the plugin documentation for your release.
What should a quote for this migration include?
A useful quote lists the in-scope APIs and environments, the policy mapping approach, the plugins and any custom code, the identity integration with Entra ID, cutover and rollback steps, testing, documentation, handover and any post-go-live support. Ask whether the quote covers the APISIX cluster build, hardening, backup of etcd or configuration files, and monitoring setup. Items left out, such as developer portal replacement or subscription migration, should appear as explicit exclusions. Fixed scope agreed in writing before work starts makes these items comparable across proposals.
How DeployOpen helps evaluate, implement and migrate APISIX
DeployOpen plans, implements, integrates, 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 Apache APISIX, that means working from your actual policy inventory, traffic and identity setup to decide whether APISIX fits, then building it in your environment.
How we scope
- We inventory your Azure API Management APIs, policies, products, named values and identity integrations before any design work starts.
- We map each policy in use to an APISIX plugin, flag gaps, and list what must be built or replaced.
- Scope, deliverables and timelines are agreed in writing before work begins, and quotes follow from that written scope.
How we build
- We deploy APISIX in the traditional, decoupled or standalone mode that matches your network and change process.
- We wire the openid-connect plugin to your existing identity provider and test authorization code and client credentials flows.
- We run security tests on the gateway and the APIs behind it, and document the results alongside the configuration.
How we hand over
- We deliver configuration as code, runbooks for routine operations, and a record of each mapped policy and its test result.
- We document the cutover plan API by API, including DNS changes, key reissue and rollback steps.
- We train your platform and security staff to operate, monitor and back up the APISIX deployment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover APISIX version upgrades, plugin updates and configuration changes as your API catalog grows.
- We prepare systems and evidence for compliance assessments, while independent auditors issue any audit reports or certifications.
