Migrate from Amazon API Gateway to Apache APISIX

Migrate from Amazon API Gateway to Apache APISIX: what the move involves

The move is mostly re-creating routes, authentication and policies on a gateway you run, then shifting traffic in stages. If your renewal, per-call bill or residency rules are pushing you off Amazon API Gateway, expect the work to sit in route inventory, auth rebuild and cutover testing rather than in the gateway software itself. The main risks are authorizer behavior that differs from what your clients expect, usage plans and API keys that have no one-to-one equivalent, and integrations that depend on AWS-side features such as VPC links. The effort depends on how many stages, custom domains and authorizers you run, so count those before you ask anyone for a quote.

Platform engineering usually owns the APISIX deployment and etcd, security owns the identity and token design, and API owners own the route definitions and their tests. Apache APISIX is Apache-2.0 licensed and runs on infrastructure you control, in traditional mode with etcd or in standalone mode driven by a YAML or JSON file, so the gateway stays in your cloud account or data center. Work that normally takes most of the time includes mapping Lambda, HTTP and VPC link integrations to APISIX upstreams, rebuilding Lambda authorizers and Cognito checks with plugins such as openid-connect, and replacing usage plans with rate limiting plugins. Confirm current plugin behavior against the APISIX documentation and your own identity provider before you commit to a design.

Plan the cutover as parallel running, not a single switch. Run APISIX in front of a small set of low-risk APIs, compare responses, latency and error rates with API Gateway, then move DNS or load balancer weights one stage at a time, keeping API Gateway in place until rollback is proven. Ask your partner or internal team to document the rollback path, the test evidence per API and the owner for each route. Recurring costs will shift to the nodes, etcd, load balancers, monitoring and on-call staff you now run, so confirm those components with your infrastructure team before the decision is final.

Which API Gateway features map cleanly to APISIX and which need rework

This table maps the main Amazon API Gateway features to Apache APISIX and marks each as clean, needs rework or gap. Read the middle column first, then use the right column to plan the work and the questions to put to your team or vendor. The main takeaway: routing, WebSocket traffic and JWT validation move over with little change, while stage models, usage quotas, API keys and caching need design decisions and confirmation in your APISIX release before cutover.

Feature	Fit in APISIX	What to confirm or rework
REST and HTTP APIs	Clean. Routes, methods and upstreams map directly to APISIX routes over HTTP and HTTPS.	Recreate resource paths and methods from the OpenAPI export, then test each route against the existing endpoint.
Stages	Needs rework. APISIX has no stage object, so dev, test and prod must be modeled as separate configurations.	Choose one configuration per environment, stored in etcd in traditional or decoupled mode or in a YAML file in standalone mode.
Lambda proxy and HTTP integrations	Needs rework. HTTP integrations map to upstreams, while Lambda targets need a function endpoint or a plugin.	Confirm the Lambda invocation plugin in your release, or front functions with an HTTP endpoint and test payload handling.
VPC link integrations	Needs rework. The gateway must reach private services directly from its own network location.	Place APISIX nodes in the same VPC or a peered network, and confirm routing and security group rules before cutover.
Lambda and JWT authorizers	Clean for JWT. The openid-connect plugin works with Keycloak, Microsoft Entra ID and Okta. Lambda authorizer code needs rework.	Port Lambda authorizer logic into a Lua plugin or an external plugin runner in Java, Go or Python, and test token rejection paths.
Usage plans, API keys and throttling	Gap. Usage plans and per-key quotas have no confirmed direct equivalent, and throttles need rebuilding as traffic control plugins.	Confirm which key and quota plugins your release provides, export current limits per stage, and test burst behavior under load.
Caching	Gap until confirmed. Stage cache size, TTL and key rules must be matched to APISIX caching options.	Confirm cache behavior, TTL and invalidation with your team before sizing nodes, because cache memory drives node capacity.
Custom domains and TLS	Needs rework. Certificates and host routing are configured on APISIX, while DNS records stay outside the gateway.	Issue certificates for each host, then lower DNS record TTLs ahead of cutover so traffic can move in stages.
WebSocket APIs	Clean. APISIX lists WebSocket support, alongside HTTP/3 with QUIC.	Test connection lifetime, idle timeouts and reconnect behavior under expected load before cutover.

Which API definitions and integrations move, and through which export path

API Gateway keeps some of your API configuration in its own control plane, and some of it lives in OpenAPI files, Lambda code and AWS resources. Knowing which piece is which decides what you can export, what you must rebuild by hand and what needs a decision before any APISIX configuration is written.

OpenAPI definitions per stage

API Gateway can export a REST API stage as an OpenAPI 3.0 or 2.0 definition, optionally with API Gateway integration extensions or Postman extensions. Treat that file as the starting description of routes, methods and parameters, not as a finished APISIX configuration. Confirm in your own account which export format and extensions your API type supports, and export each stage separately because stages can differ in deployed settings.

The application/json export limit

Exports are documented as producing application/json content, so teams with YAML-first workflows should plan a conversion step before feeding files into review. Check the exported file for content types on each operation, since request and response mappings may not carry over cleanly. Keep the original export under version control as the baseline for later comparison.

Integrations rebuilt as upstreams

The integration block in each exported operation describes where a request goes: a Lambda function, an HTTP endpoint or a VPC link. In APISIX these become upstream definitions and routes, each with its own host, port and TLS settings. Map every integration type to a concrete upstream address you control, and record which network path each one needs before you touch DNS.

Items that stay behind

Usage plans, API keys, authorizer code and the Lambda functions themselves are not part of the OpenAPI export. Usage plans and keys must be re-created as consumer and rate limiting policies, and key values must be issued again or migrated under a controlled process. Authorizer and Lambda code remain in AWS and need an owner to decide whether to port, keep or retire each one.

Inventory before any configuration

Before writing a single route, list every API, stage, custom domain, integration, authorizer, usage plan, API key and calling application, and record its owner and traffic. Pull the list from the AWS console, CLI or infrastructure code and reconcile it with what clients actually call. Unknown consumers are the most common source of breakage at cutover, so the inventory should name them.

Migration sequence from inventory to decommission

The sequence moves APIs from Amazon API Gateway to self-hosted Apache APISIX one stage at a time, so each API is proven on the new gateway before traffic leaves the old one. Each step produces a written artifact that the next step depends on, and the final decommission only happens after parity is shown.

Inventory APIs, stages and dependencies
Export every REST, HTTP and WebSocket API and each of its stages, using the OpenAPI definitions per stage. Record for each route its integration type (Lambda, HTTP proxy, VPC link or mock), its authorizer, its usage plan and API keys, its custom domain and its caller list. Usage plans, keys and authorizer code do not come out in the export, so capture them from the console or the AWS CLI by hand. The output is a route inventory that maps each API stage to its upstream, auth method, rate limits and owning team. The step is done when the platform owner and each API owner have signed off on the inventory.
Pilot one low-risk API on APISIX
Choose one internal API with few callers, a read-only profile and a plain HTTP backend. Deploy APISIX in standalone mode, which reads routes from a YAML or JSON file and reloads changes without a restart, or in decoupled mode if the pilot needs a shared control plane. Rebuild the routes, upstreams and authentication plugin for that API, then test them in a non-production environment. The output is a pilot report that records which features were recreated, which had no direct equivalent, and the team's effort per route. Confirm with your APISIX distribution that the deployment mode you choose meets your operating model before you extend it.
Run a parallel test with mirroring or split routing
Place APISIX in front of the pilot API while API Gateway stays live. Use traffic mirroring where the backend tolerates duplicate requests, or split routing at the load balancer or DNS layer where it does not. Compare status codes, response bodies, latency, authentication outcomes and rate-limit behavior between the two gateways over a window that covers your normal peak traffic. Keep a record of every difference and whether it is a defect or an accepted change. The output is a parity test result set signed off by the API owner. Do not cut over an API that has unexplained differences in authorization or rate-limit results.
Cut over stage by stage
Move the remaining APIs one stage at a time, starting with development, then test, then production, and within production start with the callers that carry the least risk. Shift traffic by changing the load balancer target group or the DNS record for each API, and keep the previous API Gateway endpoint live as a rollback path. Write a cutover runbook for each API that lists the change window, the traffic shift method, the health checks, the rollback command and the named approver. The output is a completed runbook per stage with the observed results attached. Confirm the rollback path works in a rehearsal before any production shift.
Decommission API Gateway and close out
After every stage has run on APISIX for a period your security and operations teams agree on, disable the custom domains, remove usage plans and API keys only after confirming no caller still uses them, and delete the API Gateway resources. Retain the exported definitions, the route inventory, the parity results and the runbooks as records of the migration. Review the AWS bill to confirm the per-call charges have stopped and that any remaining AWS resources, such as the Lambda functions or VPC links still in use, are documented under their new owner. The output is a decommission record listing each deleted resource, the date, the approver and the evidence. Ask your DeployOpen or internal team to confirm that the audit trail meets your compliance needs.

How APISIX deployment modes shape the target architecture

The deployment mode you choose for Apache APISIX determines where configuration lives, what must stay highly available, and how much operational surface your team owns, so it should be settled before any route is rebuilt. APISIX offers three modes. In traditional mode, the data plane and control plane run together, client traffic arrives on port 9080, and the Admin API listens on port 9180. In decoupled mode, separate data plane and control plane nodes share one etcd cluster, which lets you place gateway nodes close to workloads while keeping configuration centralized. In standalone mode, there is no etcd at all: configuration comes from a YAML or JSON file or from the API.

etcd is needed in traditional and decoupled modes, where dynamic updates through the Admin API depend on it. Standalone file-driven mode is the lighter option for a fixed set of routes. APISIX checks conf/apisix.yaml or conf/apisix.json for changes every second and hot-reloads them without a restart, so a configuration file can be versioned in Git and rolled out through your normal pipeline. The trade-off is that changes flow from files rather than the Admin API, which affects how teams that currently edit API Gateway stages will work. Ask whether the platform team can own file-based delivery, and whether any API consumers need routes changed on demand.

Do not pick the mode from the inventory alone. After you complete the API inventory, map each API's availability target, the network zones it must traverse, and whether gateway nodes must keep serving traffic if a central cluster is unreachable. Clients with APIs in several data centers or private subnets often need decoupled nodes close to each workload, while smaller estates may run well in standalone mode. Confirm these requirements with your network, security and operations owners, and check the current APISIX deployment modes documentation against the version you plan to run before you commit.

What drives migration cost and duration

This table lists the inputs that most change the effort of moving from Amazon API Gateway to Apache APISIX, with why each matters and how to keep it down. Use it to scope your inventory before asking for a quote, since the quote should itemize each driver separately.

Driver	Why it changes cost or effort	How to keep it down
API count and stage count	Each API and each stage (for example dev, test, prod) becomes its own set of routes, upstreams and deployment checks, so effort grows with the product of the two numbers.	Retire unused APIs and stages before migrating, and consolidate duplicate APIs that differ only by stage variables.
Authorizer complexity	Lambda authorizers with custom logic must be re-implemented as APISIX plugins or external identity checks, which is the most design-heavy part of the work.	Move to standard token validation (for example the openid-connect plugin with your identity provider) where possible, and document each custom authorizer's inputs and outputs first.
Number of integration types	Lambda, HTTP proxy, mock and VPC link integrations each map to a different APISIX pattern (upstream nodes, service discovery or private network routing), and each needs its own test path.	Group APIs by integration type, migrate one type at a time, and reuse one upstream pattern for similar backends.
Usage plan and API key dependencies	API Gateway usage plans and keys do not carry over as-is. Quotas, throttles and per-client key issuance must be rebuilt with APISIX traffic and consumer controls, and client onboarding may change.	Export the list of plans, keys and quota limits from the existing account, and decide which ones still matter before rebuilding them.
Client-side changes	Changing hostnames, base paths, TLS certificates or key formats can require updates in partner systems, mobile apps and internal consumers, often on their release schedules.	Keep public hostnames and paths stable through a DNS or load balancer cutover, and agree on a client change calendar with each owner before cutover.
Observability and logging rebuild	CloudWatch metrics, access logs and alarms do not move automatically. Dashboards, alert rules and log pipelines must be recreated and compared against the old baseline during parallel running.	Define the metrics and alerts you rely on today, and reuse existing Prometheus, OpenTelemetry or SIEM pipelines where they already exist.
Compliance evidence needs	Assessors may ask for change records, access control configuration, logging coverage and proof that controls on the new gateway match the old ones. Collecting this evidence adds work beyond technical cutover.	Ask early which controls and evidence your auditor expects, and keep a mapping of old and new controls with dated test results from each stage.

What usually goes wrong when moving off API Gateway

Most failed cutovers from Amazon API Gateway trace back to behavior that was never written down: who could call an API, how often, and under which timeouts. Each risk below is a place where an APISIX route can look correct in testing and still differ from the stage it replaces in production.

Lost authorizer behavior

A Lambda or Cognito authorizer in API Gateway often decides which claims reach the backend, and an export of the OpenAPI file does not include the authorizer code. Rebuilding that logic in APISIX with plugins such as openid-connect or jwt-auth can change which tokens are accepted or how claims are forwarded. Before cutover, compare accepted and rejected tokens from both gateways using the same captured requests.

Missed usage plan enforcement

API keys and usage plans in API Gateway set quotas and throttles per client, and those objects do not travel with the OpenAPI file. If keys are not re-issued and limits re-created as APISIX consumers and rate-limiting plugins, clients may run unthrottled or be blocked unexpectedly. Build a table mapping each usage plan to its APISIX equivalent, then test a client at its exact quota boundary.

Mismatched timeouts and payload limits

API Gateway enforces its own integration timeout and payload size ceiling, and APISIX applies upstream timeouts and body size limits that are set separately. A request that completed under one gateway can return a 504 or 413 under the other, particularly for long-running Lambda calls or large uploads. Record the timeouts and limits from each integration, set them explicitly on each APISIX upstream, and test the slowest and largest real requests.

DNS and certificate cutover errors

Moving a custom domain involves the TLS certificate, the DNS record, and the hostname the client sends in the Host header. A certificate that covers only the old domain, or a DNS change with a long cache, can split traffic between two gateways for hours. Confirm that the APISIX certificate covers every hostname in use, lower the record time-to-live before the change, and verify the handshake from each network segment.

Clients still calling old stage URLs

Each API Gateway stage has its own invoke URL, such as one with a stage name in the path, and some clients, scripts or partner systems hard-code it. Turning off the old stage breaks every caller that was never inventoried, and those failures often surface days later in batch jobs. Use access logs from the API Gateway stage to list actual callers before the switch, and keep the old stage running in read-only or redirect mode for a defined period.

Running both gateways without rollback

A parallel run only protects you if traffic can return to the previous gateway within minutes, and that requires the old stage, DNS records and upstream endpoints to stay live and in sync. Teams often shift traffic in steps but never write down the step that reverses them, or change backend code during the same window. Define the rollback trigger, the owner who makes the call, and the exact DNS or weight change to reverse it, and rehearse it in a non-production environment first.

How the migration differs by starting point

A small footprint usually means a few REST or HTTP APIs in one or two accounts, most of them fronting Lambda functions. Scope is narrow, so the migration can be planned as one wave with a short list of routes, and the main effort is translating each Lambda integration into an APISIX upstream or a serverless plugin call. Testing can focus on request and response shape, because the functions themselves do not change. Team skills center on NGINX-style configuration and the Admin API, and on running one etcd cluster or a standalone file-driven setup.

Scope: Export each stage's OpenAPI definition and list every Lambda integration, authorizer and usage plan that depends on it.
Testing: Replay representative requests against APISIX and compare status codes, headers and payloads with API Gateway responses.
Skills: Expect the team to learn route, upstream and plugin objects. Standalone mode can reduce the number of moving parts if the estate is small.
Operations: Decide early whether one or two gateway nodes are enough for current traffic, and who patches them.
Cutover: A single DNS change per API can be enough, but keep API Gateway running until rollback is tested.

Before you start, confirm with your team which Lambda integrations use IAM-based authorization or Lambda authorizers, since those need a replacement design rather than a direct copy.

Questions buyers ask before moving off Amazon API Gateway

What drives the cost of moving from Amazon API Gateway to Apache APISIX?

The cost depends on how many APIs you run, how many use Lambda, HTTP or VPC link integrations, how many authorizers and usage plans you must rebuild, and how many environments and regions the gateway must cover. The one-time work is inventory, conversion, policy rebuilding, testing and cutover. The recurring costs are the compute and load balancers for APISIX nodes, the etcd cluster, monitoring, logging, certificates and the people who patch and operate the platform. On the AWS side, the per-call charges you stop paying are offset by these running costs, so the comparison depends on your call volume and staffing. Ask for a quote that lists each API, integration type, authorizer and environment in scope, and that separates one-time migration work from ongoing support.

How long does an API Gateway to APISIX migration take?

The duration is set by the number of APIs, the complexity of their integrations and authorizers, the number of stages and environments, and how much of your existing test coverage can be reused. APIs that are plain HTTP proxies with simple routes move faster than those that depend on Lambda authorizers, custom mapping templates, or VPC link paths into private networks. Each stage needs its own parallel run and sign-off before traffic moves. We do not publish a fixed timeline. Agree a timeline in the written scope after the API inventory is complete, since the inventory is what reveals the real size of the work.

What does our team need to provide during the migration?

You will need to provide access to the AWS accounts and API Gateway stages, the exported OpenAPI definitions or a way to export them, the backend service owners who can confirm behavior, and the identity provider settings used by your authorizers. Your security team should define which controls must remain in place, such as token validation rules, TLS settings and logging retention. Your operations team should name who will own the APISIX clusters after handover, and where etcd, certificates and monitoring will run. Expect your engineers to review each converted route and plugin configuration, because they know the business behavior that an export file does not describe.

Can our own engineers do this migration without a partner?

Yes, a capable platform team can perform this migration in-house, and APISIX's documentation covers the core deployment modes, the Admin API and the plugin model. The questions to weigh are whether your team has spare capacity for the full inventory and testing, whether it already operates Kubernetes or similar infrastructure, and whether it has staff who can own the gateway after go-live. A partner is useful when you want the work scoped in writing, when you need hardening and evidence for an assessment, or when you want the platform handed over with documentation and runbooks. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope.

How do we shift traffic to APISIX without an outage?

Shift traffic in stages. First, run APISIX alongside API Gateway with the same backends, and send only test or internal traffic through it. Next, route a small share of production traffic, watch error rates, latency and authentication failures, and increase the share only after each step is stable. Keep the original API Gateway stage available so you can route back quickly. Change DNS or the load balancer target only after the routes pass your test suite and a documented rollback has been rehearsed. Confirm with your team how long the old stage must remain live, because that also affects your AWS charges during the overlap.

What happens to usage plans and API keys when we leave API Gateway?

Usage plans, API keys and their quotas do not move automatically, because they are AWS-specific objects. You need to decide which consumers, keys and quota tiers must continue, then recreate them as APISIX consumers with key authentication or another supported method, and rebuild their rate and quota limits with APISIX traffic control plugins. Key values should be reissued or migrated through a planned process, since clients must update their credentials. Plan a communication step for API consumers and confirm which quotas they depend on before cutover. The exact mapping depends on how your usage plans are configured, so the inventory should list each plan, key and its limits.

How should we handle authorizers and identity during the move?

Each Lambda, Cognito or IAM authorizer must be replaced with an equivalent control in APISIX. For OAuth and OpenID Connect tokens, APISIX's openid-connect plugin works with providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports flows such as authorization code, client credentials, token introspection and PKCE. Confirm the exact claims, scopes and token lifetimes your clients depend on, and test rejected and expired tokens as well as accepted ones. Remove any authorizer logic that only existed to work around API Gateway limits, and keep the security intent of the original design.

How DeployOpen scopes and runs an API gateway migration

DeployOpen plans and runs the move from Amazon API Gateway to self-hosted Apache APISIX inside your own cloud accounts or data centers. We start from a written, fixed scope that names the APIs, stages, authorizers and traffic shifts in play, then build, test and hand over the gateway with the documentation your team needs to run it.

How we scope

Inventory every REST, HTTP and WebSocket API, stage, custom domain and usage plan to be moved.
Map each Lambda, HTTP and VPC link integration to an APISIX upstream and list the authorizers to rebuild.
Agree in writing which stages move first, what cutover criteria apply and what remains out of scope.

How we build

Convert exported OpenAPI definitions into APISIX routes and plugin configuration, kept under version control.
Re-create authorizers with APISIX authentication plugins, including openid-connect against your existing identity provider.
Replace usage plans and API keys with rate limiting and consumer controls, then test each route before any DNS change.

How we hand over

Deliver the gateway deployment, configuration repository and runbooks for the deployment mode your team selects.
Document the mapping from each API Gateway stage and integration to its APISIX equivalent, including gaps and workarounds.
Walk your platform and security teams through operations, monitoring, backups and the staged traffic shift outcomes.

How we support

Fixed-scope engagements close with agreed handover deliverables, with any further work quoted from a new written scope.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask us to confirm APISIX release and support status against your own environment before the upgrade plan is fixed.

Migrate from Amazon API Gateway to Apache APISIX