Amazon API Gateway alternative or the managed default: which fits your APIs
Most readers arrive here for one of three reasons: a renewal that came in higher than expected, a per-call bill that rises with every new client or partner, or APIs that no longer sit in one AWS account. The first question is not which product is better in general but where your traffic starts and ends. If your APIs are concentrated in AWS, your team already manages IAM policies and CloudWatch, and you have little appetite for operating infrastructure, Amazon API Gateway remains the better default. It integrates directly with Lambda, IAM authorizers, Cognito and VPC links, and AWS runs the data plane for you. Leaving it only makes sense when the integration savings no longer outweigh the cost of the traffic it carries.
Apache APISIX fits a different profile. It is an Apache-2.0 gateway built on NGINX and etcd, and it can run in traditional, decoupled or standalone mode, so the same configuration model can run in AWS, another cloud and your own data center. Its plugin catalog covers authentication, traffic control and observability, and its openid-connect plugin works with providers such as Keycloak, Microsoft Entra ID and Okta. Choose it when you need one gateway policy set across environments, when traffic originates outside AWS, or when you need control over where request data is logged and processed. Confirm each plugin your APIs depend on against the current documentation before you commit to a design.
The decision turns on four points. First, call volume: model your current and projected requests against both pricing and the cost of the nodes, etcd, load balancers and monitoring you would run. Second, where traffic originates: AWS-internal callers favor the managed option, while mobile, partner or on-premises callers weigh toward a self-hosted gateway. Third, who will operate the nodes, because on-call coverage and upgrades are recurring work. Fourth, which authentication and caching behavior your APIs rely on. Export your authorizer types, usage plan keys and cache settings, then test whether each has an APISIX equivalent before you plan a migration.
Which gateway fits each scenario
This table maps common buyer situations to the gateway that usually fits best, with a short reason for each. Read it by finding the row that matches your main constraint, then confirming the trade-offs in your own environment before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| All APIs in one AWS account and Region | Amazon API Gateway | Native IAM, CloudWatch, Lambda and VPC Link integrations work with little glue code, and per-call billing may stay simple at modest volumes. |
| APIs spread across several clouds | Apache APISIX | One self-hosted gateway with the same routes, plugins and configuration can run in each cloud, so policies do not depend on one provider's service. |
| APIs in your own data centers | Apache APISIX | APISIX runs on infrastructure you control, including air-gapped networks, and its traditional, decoupled and standalone modes fit different network designs. |
| High call volume with steady traffic | Apache APISIX (self-hosted) | Node cost is driven by capacity you provision, so the per-call comparison should be modeled against your own traffic and staffing costs. |
| Low volume with spiky traffic | Amazon API Gateway | Pay-per-call billing avoids running idle gateway nodes, and autoscaling is handled by AWS. |
| Heavy reliance on Lambda authorizers and usage plans | Amazon API Gateway, unless you rebuild the logic | Authorizers and usage plans must be replaced with APISIX plugins such as openid-connect and rate limiting, which needs design and testing before cutover. |
| Need for Kubernetes-native ingress | Apache APISIX | The APISIX Ingress Controller lets platform teams manage routes through Kubernetes resources, which suits clusters run outside AWS. |
| Teams that want a managed control plane with no operations staff | Amazon API Gateway | AWS operates the service, while APISIX requires your team to run etcd, nodes, upgrades and monitoring. |
How APISIX runs: traditional, decoupled or standalone
In traditional mode, the data plane and control plane run together in the same APISIX deployment, and etcd stores the routes, plugins and upstreams. Client traffic is served on port 9080 and the Admin API listens on port 9180, so both the gateway and its configuration interface sit on the same nodes. This is the simplest topology to start with because there is one deployment to install, configure and monitor.
- Operational consequence: Every gateway node can change configuration, so the Admin API port must be restricted to administrators and automation only.
- Network exposure: Port 9180 should never be reachable from client networks, and access should be limited with firewall rules or an internal load balancer.
- Fit: Single-cluster or single-region setups where one team owns both traffic and configuration.
- etcd dependency: The etcd cluster is part of the critical path, so its backups and health checks belong in the runbook from day one.
- Scaling: Adding nodes adds both traffic capacity and administrative surface, which matters for audit scope.
Check the port layout and Admin API access rules in your own environment before exposing any node to a wider network.
In decoupled mode, the data plane and control plane run as separate deployments, and both connect to one shared etcd cluster. The control plane handles configuration writes through the Admin API while data plane nodes only read configuration and serve traffic. This separation suits organizations that want administrators away from the traffic path.
- Operational consequence: Data plane nodes can be scaled, replaced or placed in different networks without touching the administrative plane.
- Shared state: All control and data plane components depend on the same etcd cluster, so etcd availability and access control affect every environment that uses it.
- Fit: A central control plane managing several data planes, such as separate gateways per business unit, region or DMZ.
- Access separation: Operators who change routes can be kept apart from teams who only run gateway hosts, which supports least-privilege reviews.
- Backup scope: Backups must cover the shared etcd cluster, and restore tests should confirm that every connected data plane recovers correctly.
Confirm the exact connection and certificate settings for your APISIX version against the deployment modes documentation before standing up separate planes.
In standalone mode, APISIX runs without etcd. Configuration comes from a YAML or JSON file, conf/apisix.yaml or conf/apisix.json, or through the API. APISIX checks the file for changes every second and hot-reloads it without restarting, so a file update is enough to change routes and plugins. This makes configuration something you can version, review and deploy like any other code.
- Operational consequence: There is no etcd cluster to run, back up or secure, which removes one stateful component from the estate.
- GitOps fit: Teams can keep the file in Git, review changes through pull requests and roll back by reverting a commit.
- Trade-off: Dynamic changes through the Admin API are limited compared with the etcd-based modes, so confirm which operations your automation needs.
- Consistency across nodes: Each node reads its own copy of the file, so distribution and rollout order need a clear process.
- Fit: Stable, change-controlled gateways, edge deployments and environments where operators prefer declarative files over live APIs.
Confirm which plugins and dynamic operations your version supports in standalone mode, and test how the file is delivered to each node.
Capabilities side by side
This table compares the main capabilities of Amazon API Gateway with self-hosted Apache APISIX. Where a row depends on current AWS details, confirm the feature against AWS documentation before deciding, since AWS changes its service over time. Use the gap rows to see which AWS-native features need a replacement in your own design.
| Capability | Amazon API Gateway | Apache APISIX |
|---|---|---|
| License and hosting | AWS-managed service, runs only inside AWS and billed per call | Apache-2.0 licensed, self-hosted in your cloud accounts, data centers or on Kubernetes |
| Underlying technology | AWS-operated gateway, internals not exposed to customers | Built on NGINX with etcd as the configuration store, so routes and plugins update without restarts |
| API types | REST, HTTP and WebSocket APIs | HTTP, HTTPS, HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo and TCP/UDP proxying |
| Authentication | IAM and Lambda authorizers, Cognito user pools; confirm current options in AWS documentation | openid-connect plugin with Keycloak, Auth0, Microsoft Entra ID, Google and Okta; authorization code, client credentials, introspection and PKCE |
| Built-in policy plugins | Managed features such as throttling, validation and caching; confirm exact coverage in AWS documentation | More than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway functions |
| Custom extensions | Lambda functions and integrations; extensions run in AWS | Plugins written in Lua, or in Java, Go and Python through plugin runners, plus WebAssembly |
| Usage plans and API keys | AWS-native usage plans and API keys; no direct equivalent, so plan rate limits and key issuance with plugins or your own key service | Rate limiting and key-based access are handled by plugins; you design the key lifecycle and billing logic yourself |
| Caching | Stage-level response caching billed by the hour; confirm limits in AWS documentation | Caching is available through plugins; confirm the specific plugin and its behavior for your routes |
| Private backend access | VPC links to private resources inside your AWS network | Reaches private backends from wherever APISIX runs; network path is your design responsibility |
What happens to Lambda, IAM and caching when APIs leave AWS
Most API Gateway setups rely on three AWS-native behaviors: Lambda integrations, IAM-based access and usage plans with API keys, plus response caching on stages. On APISIX, none of these carry over as settings. Each one becomes something your team builds and tests. A Lambda integration becomes either an HTTP upstream pointing at the function's URL behind a function gateway, or plugin logic running at the gateway for simple transformations. The Lambda function itself does not move automatically, so decide per function whether it stays on AWS (called over HTTPS) or is rewritten as a service that APISIX reaches directly. Confirm the serverless and function-invocation plugins and their supported options in the APISIX plugin reference before you map any function.
IAM-based access has no direct equivalent in APISIX. API Gateway authorizers and IAM policies that check SigV4 signatures or Cognito tokens need replacing with checks your identity provider can issue. In practice that means the openid-connect plugin validating JWTs or token introspection against Keycloak, Microsoft Entra ID, Okta or another provider your organization already runs, or key-based consumer plugins for machine clients. Usage plans and API keys map to consumer and rate-limiting plugins: each client gets an identity, a quota and a throttle, and you must rebuild those quotas from the plan definitions you export. Note that the rate-limiting plugins keep counters per node unless you configure a shared store, so test quota accuracy under your real load.
Response caching is the item most likely to surprise teams. Stage-level caching in API Gateway is a managed, per-hour charge with no node to size. On APISIX, the team must choose a cache plugin or an upstream cache layer, decide what keys it uses, set time-to-live values per route, and size memory on each node or in the cache tier. Cache invalidation rules and authorization-aware cache keys need explicit design so one user's response is never served to another. Each mapping in this section needs testing against your own APIs with production-like traffic and the identity provider you will use, and you should verify the exact behavior of each plugin and its configuration keys in the APISIX documentation before cutover.
Where the gateway and its traffic live
Moving from Amazon API Gateway to Apache APISIX changes who holds the traffic path, the logs, the configuration and the evidence. Each card below covers one place where that shift matters, and the conditions under which it becomes a decision rather than a detail.
Traffic path and TLS termination
With API Gateway, TLS is terminated inside AWS-managed endpoints in the Region you deploy to. With APISIX, TLS terminates on nodes you place, whether in your VPC, a data center or an edge location. Confirm which network segment carries decrypted requests, where certificates are loaded, and whether any hop passes through a third-party proxy before reaching your gateway. This matters most under data residency rules that name specific locations or networks.
Where logs and metrics are stored
API Gateway sends access logs and metrics to CloudWatch in the account and Region you choose. An APISIX deployment writes logs and metrics to whichever sinks you configure, such as a self-run log pipeline or a SIEM. Decide who can read request payloads, which fields are masked, and how long records are kept. Retention and access rules are your responsibility to set and prove, especially when logs contain personal or cardholder data.
Where configuration lives
APISIX stores routes and plugins in etcd in traditional and decoupled modes, in a YAML or JSON file in standalone mode, or behind the Admin API. Each choice changes your backup, change control and disaster recovery plan. Etcd holds live state that must be backed up and restored, while a file-driven setup puts that state in version control. Confirm which store is the source of truth before any audit or rollback drill.
Identity provider placement and token handling
In API Gateway, Lambda authorizers and Cognito or IAM checks run inside AWS. With APISIX, the openid-connect plugin talks to your identity provider, such as Keycloak, Microsoft Entra ID or Okta, from the gateway itself. Check where client secrets are stored, how JWTs and introspection results are cached, and whether tokens are forwarded upstream. Network paths from the gateway to the identity provider become part of your control design.
Shared responsibility for patching and certificates
API Gateway is a managed service, so AWS operates the gateway fleet and its underlying patching. Running APISIX shifts that work to your team: OS and NGINX updates, APISIX version upgrades, etcd maintenance, and certificate issuance and renewal. Write down an owner and a cadence for each item, and confirm how you will learn of security advisories for every component in the stack.
Compliance evidence the team must produce
Managed services often supply inherited control documentation, while self-hosted gateways do not. You will need to produce your own evidence for access reviews, change records, configuration history, vulnerability scans and backup restores. Independent auditors assess whether those controls work; they do not certify the platform itself. Ask your assessor early which artifacts they will request and map each one to an owner in your team.
Per-call charges against the cost of running APISIX nodes
The Amazon side of the comparison is mostly metered. API Gateway bills per API call by tier for REST, HTTP and WebSocket APIs, and it adds charges for caching, which are billed by the hour for each cache size you provision, and for data transfer out to clients. Each of these is recurring and scales with traffic, so a quiet quarter and a peak month look very different on the invoice. Pull at least twelve months of AWS invoices and split the API Gateway line into request charges, cache-hour charges and data transfer. Then check your own call volumes per API and per stage, because the tier that applies depends on those numbers. Confirm current rates on the AWS pricing pages rather than relying on figures from older articles.
The APISIX side is mostly provisioned. Your costs include compute for the data plane nodes, sized to peak throughput with headroom for failover, an etcd cluster for configuration (typically three members in a production layout, which you should confirm against the deployment modes documentation for your chosen mode), load balancers in front of the nodes, log and metrics storage for monitoring, and certificate management. Recurring items also include upgrades and patching of the gateway, etcd and operating system, plus the staff time to run them. One-time items are the design of routes and plugins, migration of exported definitions, load testing and cutover. Costs fall when traffic is steady and automation handles deployment, and rise with the number of environments, regions and on-call hours you need.
When you request a written quote from an implementation partner, ask for the cost of each component separately: design, migration and testing as one-time items, and infrastructure estimates, support hours, patching cadence and handover documentation as recurring items. Ask which environment assumptions the price depends on, who pays for cloud or data center capacity, and what is excluded, such as plugin development or identity provider changes. DeployOpen scopes engagements in writing before work starts, so a quote should trace back to a stated scope. Build the final comparison from your own call volumes and AWS invoices, then add the internal staff hours you expect to spend, and compare totals over the same period.
How a move from API Gateway to APISIX runs in stages
The sequence turns each API Gateway stage into a tested APISIX route set that receives traffic in controlled steps, with a rollback path at every cutover. It ends with a documented record of what was moved, what was rebuilt and what was retired.
Inventory APIs, stages and dependencies
The platform owner lists every REST, HTTP and WebSocket API, each deployed stage, custom domain, backend integration (Lambda, HTTP endpoint or VPC link), authorizer, usage plan and API key, along with the clients that call them. The inventory is complete when each API has an owner, a traffic profile and a named cutover window agreed with its consumers.
Export OpenAPI definitions per stage
The API team exports each stage's definition using the method described in the export guide, then stores the files in version control alongside the stage name. Check that every export opens and validates, and record what the export does not contain, since usage plans, keys and authorizer code stay behind and must be recreated by hand.
Map each integration to an APISIX upstream
Engineers translate each backend integration into an APISIX upstream and route, with Lambda functions reached through an HTTP or serverless approach that the team confirms for its own setup, and VPC-internal services reached over network paths the cluster can route to. The mapping is done when each route has a documented upstream, timeout and health check, reviewed against the original integration settings.
Rebuild authentication and rate limits as plugins
Security engineers recreate each authorizer as an APISIX plugin, such as the openid-connect plugin for OAuth or OIDC flows with the organization's identity provider, and rebuild usage plans and API keys as consumer and traffic-control settings. Each rebuilt control is confirmed by a test that sends a valid and an invalid credential and a request over the limit, with the expected responses recorded.
Stand up the APISIX cluster with etcd and monitoring
The platform team deploys APISIX in the chosen mode (traditional, decoupled or standalone), a highly available etcd cluster where etcd is used, load balancers in front, and logging and metrics export to the existing monitoring stack. The stage is complete when a health check passes on every node, configuration changes reach all nodes, and alerts fire during a controlled failure test.
Test in parallel before any traffic moves
QA and the API owners run the same request sets against API Gateway and APISIX, comparing status codes, response bodies, latency and error handling, and they run load tests sized to the expected peak. Parallel testing is finished when the differences are either fixed or accepted in writing by the owner of each API.
Shift traffic stage by stage with rollback
Traffic moves one stage at a time, starting with low-risk consumers, by changing DNS weights or the load balancer target for each API. Each cutover keeps the API Gateway endpoint live and has a written rollback step that the on-call engineer can execute, and the stage is closed only after error rates and latency match the baseline for an agreed observation period.
Decommission API Gateway resources
Once every stage has run on APISIX through its observation period, the team removes API Gateway stages, custom domains, usage plans, keys and related authorizers, and archives the exports and test records. The decommission is complete when the account shows no active API Gateway resources and the archive holds the definitions, the rebuilt policies and the cutover logs.
Questions buyers ask before changing gateways
What does moving off Amazon API Gateway actually cost?
The cost is the sum of components, not a single license fee, because APISIX is Apache-2.0 licensed and the software itself carries no license charge. The recurring costs are the compute for APISIX data plane nodes, the etcd cluster in traditional or decoupled mode (or none if you run standalone mode), load balancers, logging and monitoring, and the people who operate and patch the stack. The one-time costs are design, migration work, testing and cutover. Costs go up with high availability requirements, number of environments, and how much custom plugin code you write. To compare fairly, ask for a written quote that separates design, migration, testing, run costs and any retainer, and ask your own team to model the current API Gateway bill by component, including caching hours and data transfer, against the same workload on your infrastructure.
How long does an API Gateway to APISIX migration take?
The duration depends on the number of APIs, the authentication design, and how much testing and traffic shifting your organization requires, so no single timeline applies. A small set of Lambda-backed or HTTP-backed APIs with simple API keys moves far faster than hundreds of APIs with Cognito or Lambda authorizers, VPC links, usage plans and custom domains. Test coverage is often the longest step: you need to compare responses, latency, error behavior and throttling between the two gateways before you move production traffic. Ask any provider for a phased plan with written milestones, and ask your team to inventory APIs, authorizers and integrations first, since that inventory determines most of the estimate.
What skills does the migration team need in-house?
The team needs working knowledge of four areas: AWS (API Gateway, IAM, Lambda, VPC networking, CloudWatch), network and DNS design including TLS certificates and load balancing, identity (OAuth 2.0 and OpenID Connect, the providers you use, and token validation), and operations (on-call, patching, backup of etcd, and capacity planning). Engineers who will write custom plugins also need Lua, or one of the plugin runners for Java, Go or Python. If your on-call team has never operated an NGINX-based service, plan for a training period before cutover. Ask your provider which of these skills they will supply during the engagement and which they expect you to keep after handover.
Can our team migrate APIs to APISIX without outside help?
A capable platform team can do it without outside help if it has the skills above and time for a staged cutover. Teams usually ask for help in three places: converting authorizers and usage plans into APISIX plugins and consumers, designing a high availability topology with etcd and load balancing, and building the test harness that proves parity before traffic moves. Ongoing security hardening and upgrade planning are also common reasons to keep an outside partner on retainer. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts or data centers, and most engagements are fixed-scope with agreed deliverables and timelines in writing before work starts.
Does APISIX replace every AWS-native feature of API Gateway?
No. APISIX covers the core job of routing, authentication, rate limiting, traffic control, observability and many protocols, but it does not replicate AWS-native integrations such as direct Lambda invocation in the way API Gateway does, IAM-based request signing, or managed custom domains, WAF and CloudWatch integration. Some of these gaps are solved with plugins, a Lambda-hosted upstream or a separate AWS service, while others change how you operate. Confirm the following against your own API inventory: how each Lambda and VPC link integration will be reached, how any Cognito or Lambda authorizer will be re-created with the openid-connect plugin or a custom plugin, whether caching requirements are met by the caching plugins you choose, and how request and response transformation maps to your current mapping templates.
How do we choose between APISIX, Kong Gateway and Tyk?
Choose on licensing, operating model and the features your APIs need, then test with your own traffic. APISIX is Apache-2.0 licensed, is built on NGINX and etcd, supports dynamic configuration without restarts, and offers three deployment modes including standalone file-driven mode. Kong Gateway OSS is Apache-2.0 licensed, and Kong's management control plane is offered through Kong Konnect, a SaaS platform. Tyk Gateway is MPL-2.0 except its commercial ee folder, and its dashboard and developer portal come under a commercial license. Ask each vendor which features your required use cases depend on, including authentication flows, caching, observability and developer portal needs, and run a proof of concept against the same API set before you decide.
What happens to usage plans and API keys during the move?
Usage plans and API keys do not transfer automatically, because API Gateway stores them in its own service. You will need to export the API definitions per stage (OpenAPI files do not carry usage plans, keys or authorizer code), then recreate the equivalent controls in APISIX. Typically, keys become consumers or API key checks, and usage plan quotas become rate-limiting plugins with matching limits per consumer. Plan a parallel period in which both gateways enforce the same limits, and give clients a dated cutover that covers new key issuance. Ask your provider how they will map each usage plan to an APISIX consumer and limit, and how key rotation will be handled for existing clients.
How DeployOpen works on this
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 Amazon API Gateway vs Apache APISIX, we start by mapping which APIs, authorizers and integrations would move, then build and test a self-hosted APISIX deployment that you run.
How we scope
- We inventory the APIs, Lambda and HTTP integrations, authorizers and usage plans currently running in API Gateway.
- We define which APISIX deployment mode fits your environment: traditional, decoupled or standalone.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy APISIX and its etcd cluster in your own accounts or data centers, with the Admin API restricted to trusted networks.
- We re-create authentication with the openid-connect plugin against your existing identity provider.
- We test routing, rate limits and caching against captured production traffic patterns before any DNS or traffic cutover.
How we hand over
- You receive configuration as code, runbooks for upgrades, backups of etcd and a record of every route and plugin.
- We document the API inventory, mapping from each API Gateway stage to APISIX routes, and the cutover plan.
- Your team is trained to operate the gateway, monitor it and roll back a route if a change misbehaves.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Security testing of the gateway, its APIs and its plugins can be scheduled as part of the same engagement.
- We prepare systems, controls and evidence for compliance assessments, though independent auditors issue any formal report.
