API gateway alternative for multicloud

Amazon API Gateway alternative for APIs spread across clouds and data centers

If your APIs run in AWS, in another cloud and in your own data centers, you probably maintain three gateway configurations that drift apart over time. A single self-hosted gateway, run in each environment with the same routes, policies and tooling, can remove that duplication. The main candidates are Apache APISIX and Kong Gateway OSS, both of which can be installed on any Linux host, container platform or Kubernetes cluster you control. Amazon API Gateway is an AWS-managed service that only runs inside AWS, so the alternative is a gateway your own teams operate on infrastructure you choose, with the licensing and support trade-offs covered later on this page.

The practical question is which configuration model fits your change process. APISIX supports traditional, decoupled and standalone deployment modes, and its standalone mode reads a conf/apisix.yaml or conf/apisix.json file that can be versioned in Git and hot-reloaded. Kong Gateway OSS offers DB-less mode with declarative files, and its decK tool exports and syncs that configuration. Before choosing, list every environment, the identity provider each one uses and whether any route depends on a database-backed plugin, because Kong's documentation limits such plugins to traditional mode. Confirm with each vendor that the exact plugin set you need is available in the open-source edition.

Plan for the operating model as well as the software. Each environment needs its own gateway nodes, health checks, certificates and monitoring, and someone must own upgrades across all of them. Check the release status of each candidate before you commit: the APISIX downloads page does not mark any release as long-term support, and Kong's published version support policy covers only Kong Gateway Enterprise. Ask your internal team or a qualified partner to document a patch cadence for each environment, so a security fix in one cloud does not wait on a manual step in another.

What running one API gateway across clouds and data centers requires

A single gateway spanning several clouds and data centers only works if the same routes, policies and identity checks behave the same everywhere. The cards below cover the design decisions and checks that connect those environments, and note where the result depends on your own architecture rather than on the product.

Consistent routes and policies everywhere

The same route, upstream and plugin set should produce the same behavior in every environment. Apache APISIX and Kong Gateway both express routes and plugins as configuration, so one definition can be applied to each location. Check that every plugin you depend on is available in the open-source edition you choose, and that rate limits and quotas behave the same when a node runs in a different location. Note that keeping environments in step depends on your release process and the discipline of your teams.

A versioned, reviewable configuration source

Keep gateway configuration in Git so every route change has an author, a review and a rollback point. Kong's DB-less mode reads declarative files that can live in Git, and decK exports and syncs them. APISIX standalone mode reads a YAML or JSON file that it reloads when the file changes. Decide which mode fits each environment, because database-backed plugins require the traditional topology in Kong. The pipeline that validates and promotes these files is your design to build and own.

Identity provider access in each location

Each location may need to validate tokens from a different identity provider, or from one central provider reached over different networks. The APISIX openid-connect plugin supports Keycloak, Auth0, Microsoft Entra ID, Google and Okta, with authorization code, client credentials, token introspection and PKCE flows. Confirm that each data center can reach the identity endpoints it needs, and test token validation during failover. Which provider is authoritative for each consumer group is a governance decision for your organization.

Traffic control and observability per environment

Rate limiting, health checks and logs must be configured and watched in every location, not only in the primary cloud. APISIX offers more than 100 built-in plugins covering traffic control and observability, and Kong's README lists rate limiting and health checking. Some Kong features, such as cluster-strategy rate limiting, require the traditional topology with a database. Your team owns the dashboards, alert routing and capacity planning for each site.

Operation without a vendor control plane

A gateway that runs in a data center with restricted internet access must still start, route and reload configuration without a call to a vendor service. Self-hosted APISIX and Kong Gateway OSS run without a SaaS control plane, and APISIX standalone mode needs no etcd. Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane belong to Kong Gateway Enterprise, so confirm the edition you need before you design the topology. Test the air-gapped path with the exact images and packages you plan to use.

Which self-hosted gateway fits multicloud and on-premises APIs

This table compares five self-hosted gateways on license, which features sit behind a commercial license, how each runs across clouds and data centers, and the main trade-off. Read the license and deployment rows first, then confirm the rows marked for vendor confirmation against your own environment before shortlisting.

Criterion	Apache APISIX	Kong Gateway OSS	Tyk Gateway	Gravitee API Management	WSO2 API Manager
Gateway license	Apache-2.0	Apache-2.0 (Kong Gateway repository)	MPL-2.0, except code in the ee folder	Apache-2.0	Apache-2.0
What needs a paid license	Not stated in the supplied facts; confirm any enterprise add-ons with the vendor	Enterprise features; fully self-hosted local control plane and data plane are part of Kong Gateway Enterprise	Management control plane, dashboard GUI and developer portal under a commercial license (Self-Managed or Cloud)	Some features require a Gravitee Enterprise License	On-prem subscriptions with support, continuous updates and a licensed distribution for commercial use
Configuration model	File-driven standalone, decoupled or traditional mode with etcd	DB-less declarative files kept in Git, or traditional mode with a database	Gateway with a separate management control plane	Gateway with management backend and console UI	Gateway, publisher, control plane and traffic manager
Install options	Container, Kubernetes ingress and package installs; confirm packaging per platform	Docker, Docker Compose, Kubernetes, or packages for Ubuntu, RHEL, Debian and Amazon Linux	Confirm package and container options for your environment with the vendor	Confirm the gateway, console and portal deployment model with the vendor	Confirm deployment patterns for each region and data center with the vendor
Developer portal and UI in every environment	Confirm with the vendor whether a management UI is needed in each environment	Confirm whether the management UI is needed in each environment and what is included in OSS	Portal and dashboard sit in the commercial tier; confirm what runs without them	Developer portal included in the open-source distribution; confirm feature gaps with the vendor	Developer portal and publisher included; confirm the operating model for disconnected sites
Main trade-off	Strong cross-environment portability; more operational setup for the control plane and etcd	Consistent declarative workflow with decK; some features and support windows depend on the paid edition	Open gateway core with commercial management tooling for multi-site control	Full API management in one open distribution; some capabilities gated by enterprise license	Broad suite with a heavier footprint; commercial support is a separate subscription

How APISIX and Kong Gateway deploy in each environment

In traditional mode, APISIX runs the data plane and control plane together on each node, with etcd holding the configuration. Decoupled mode separates the data plane from the control plane, and both sides share one etcd cluster. Use these models when every gateway node can reach a common etcd cluster and the platform team wants routes and plugins to change at runtime without restarts.

Client traffic port: Traditional mode listens on port 9080 for client traffic by default.
Admin API port: The Admin API listens on port 9180 by default, so restrict it to the platform team's network segment.
Configuration source: etcd stores routes, upstreams and plugin settings, and changes apply without restarting the gateway.
Database-dependent behavior: etcd is the only state store in these modes, so confirm in the APISIX plugin documentation which plugins need additional external services.
Site fit: Sites without reliable etcd connectivity should consider standalone mode instead.

Confirm the etcd cluster layout, backup approach and network path from each site before choosing these modes.

Standalone mode runs APISIX without etcd. The gateway reads its configuration from a YAML or JSON file, or from an API, and the file-driven option is the one that suits sites without a central store. APISIX checks conf/apisix.yaml or conf/apisix.json every second and hot-reloads changes without restarting, which lets teams deliver configuration as a file through their normal release tooling.

No etcd dependency: Each node holds its own configuration, so a site can run when its link to a central cluster is down.
Configuration file: conf/apisix.yaml or conf/apisix.json is the source of truth, and it can be kept in Git and deployed with configuration management.
Reload behavior: Changes to the file are picked up within about one second, with no process restart.
Ports and Admin API: Confirm the default client and admin ports for standalone mode in the deployment modes documentation, and confirm whether the Admin API is exposed at all.
Operational trade-off: Every node carries its own copy of the configuration, so the pipeline that writes the file to each site must be reliable.

Verify the file distribution method, the rollback process and how nodes report their configuration version before relying on this mode across many sites.

DB-less mode runs Kong Gateway without a database. The gateway loads its configuration from declarative files, which can be stored in Git, and it exposes a read-only Admin API. This model fits sites with no database connectivity and teams that want every change to go through a reviewed file. Kong's decK tool, licensed under Apache-2.0, exports configuration with deck gateway dump and syncs declarative files to open-source Kong Gateway.

Configuration source: Declarative files define services, routes and plugins, and they serve as the change record.
Admin API exposure: The Admin API is read-only in this mode, so configuration changes come from files rather than live API calls.
Database-dependent plugins: Cluster-strategy rate limiting and OAuth2 need traditional mode, so they are not available in DB-less mode.
Tooling: decK moves files between environments and keeps the Git repository as the source of truth.
Ports: Confirm the proxy and Admin API ports in the Kong deployment topologies documentation for your installed version.

Decide early which rate limiting and OAuth2 requirements the gateway must meet, because those requirements determine whether DB-less mode is enough.

How to deploy one gateway configuration across every environment

This sequence turns scattered gateway settings in each cloud and data center into one versioned configuration that the same gateway software applies everywhere, with tests that show the behavior matches before production traffic moves.

Inventory APIs and upstreams in every location
Your platform team lists each API, its public hostname, its methods and paths, its authentication method and every upstream it calls, grouped by cloud account or data center. Include the owners of each API and any traffic that depends on a specific network path, such as a private link or VPN. Application owners should confirm the upstream addresses and expected response times. The step is done when every API has a row in one inventory that names its location, owner and upstream, and nobody can point to an API that is missing from it.
Choose one deployment model per environment
Architects decide, for each environment, whether the gateway runs in traditional mode, as a decoupled data plane and control plane, or in standalone or DB-less mode with configuration files. The choice depends on whether the team already runs etcd or PostgreSQL, whether an environment has outbound connectivity, and which plugins are needed, since some plugins require a database. Staff should record the chosen model, the reason and the operator who will maintain it. The step is complete when each environment has a written model and the team agrees that the same route and plugin definitions can be applied in all of them.
Store routes and plugins in version control
Engineers write the route, upstream, plugin and consumer definitions as declarative files in a Git repository, one folder per environment with shared base files. Environment-specific values such as upstream hosts and secret references stay in separate variables, not in the shared definitions. Reviewers approve changes through merge requests. The step is done when a fresh gateway can be built from the repository alone and a diff between the repository and a running node shows no unexpected drift.
Deploy identical gateway nodes in each location
Platform engineers install the same gateway version in every environment, using the packaging method the team already runs, such as containers, Kubernetes or Linux packages, and apply the same version-controlled configuration. The team should confirm the exact version and its support status with the vendor or project before rollout, since support windows differ between open-source releases and paid editions. The step is done when every node reports the same version and loads the same configuration revision.
Test the same requests in each location
QA and platform staff run one shared test suite that sends the same requests to each gateway, covering routing, status codes, header transforms, error responses and timeouts, and compares results across locations. Tests should include a request to each upstream through the gateway and a check that unauthorized calls are rejected. Differences caused by network paths should be documented as known variations. The step is complete when the suite passes in every location, or each remaining difference has a recorded owner and decision.
Add identity, rate limits and monitoring
Security engineers connect the gateway to the organization's identity provider, configure authentication, token validation and rate limits per consumer or route, and enable logs, metrics and traces that feed the existing monitoring stack. Confirm which authentication flows and rate-limit storage each plugin needs in each deployment model. The step is done when test clients get the expected allow and deny responses, rate-limit counters behave as designed in each location, and dashboards show traffic, errors and latency for every gateway.
Move production traffic with a rollback path
Operations staff shift production traffic in controlled steps, such as a small share of requests or one API at a time, while watching error rates, latency and authentication failures. Each step has a named approver and a recorded configuration revision. Keep the previous DNS record, load balancer target or Amazon API Gateway stage in place until the new path has run cleanly. Rollback means reverting the Git revision and redeploying it, or restoring the old routing target, and the team should rehearse this once before the cutover. The step is complete when all traffic runs through the new gateways and the rollback procedure has been tested.

Where Kong's paid editions change the on-premises picture

Kong's pricing page places fully self-hosted gateways with a local control plane and data plane inside the commercial Kong Gateway Enterprise offering, and Kong Gateway 3.10 removed the unlicensed free mode from Enterprise. For a team that wants one gateway binary running in several data centers and clouds, this means the self-run control plane and data plane pairing is a licensing question, not only a technical one. The open-source edition remains Apache-2.0 licensed, but it is the edition to plan around if you need no commercial license at all.

An OSS-only design keeps the parts that matter most for a multi-environment, Git-driven setup. DB-less mode takes its configuration from declarative files that can live in Git, with a read-only Admin API, and decK, also Apache-2.0 licensed, exports and syncs those files with open-source Kong Gateway. The Kong Ingress Controller, released under Apache-2.0, covers Kubernetes clusters. What the team gives up is the database-dependent plugins in DB-less mode, such as cluster-strategy rate limiting and OAuth2, which the deployment topologies documentation limits to traditional mode. The team also gives up a Kong-managed control plane, so it runs the configuration pipeline, backups and upgrades itself.

Before you choose Kong for a design with separate development, staging and production estates across on-premises and clouds, confirm current edition contents directly with Kong. Ask which plugins, hybrid control plane features and support terms are included in the open-source edition and which require Enterprise, and get that answer in writing for the exact versions you plan to run. Check whether the traditional-mode plugins you rely on would force you into a database-backed deployment in each environment. Then compare the result with the other options in this section before committing.

What auditors and regulators ask for across several environments

When APIs run in several clouds and data centers, assessors test the same controls in each location and ask for one picture of how the gateways were run. The cards below are the evidence sets that connect those locations, and most of them need to be produced in one format for all of them. DeployOpen prepares these systems and records for assessment, while independent auditors issue any report or attestation.

Current gateway and environment inventory

Assessors start with a list of every gateway node, control plane and data plane, the cloud account, data center or air-gapped network each runs in, and the owner of each. For a multicloud estate, the inventory should also show which APIs route through which gateway, so that no API is exposed through an unrecorded path. Check that the inventory is generated from the running systems or the configuration repository, not maintained by hand, because hand-kept lists drift quickly across teams.

Version-controlled configuration with change history

Routes, plugins, upstreams and security policies should be stored as files in Git, so every change has an author, a reviewer and a timestamp. For Kong Gateway in DB-less mode, declarative files kept in Git with decK sync are a natural form of this evidence. Confirm that production can only be changed through the reviewed pipeline, and that drift between the repository and the running gateway is detected and reported.

Access logs and admin API records per location

Each location needs its own record of who reached the gateway administration interface, from which address, and what they changed. Admin APIs such as APISIX's Admin API on port 9180 in traditional mode should be reachable only from management networks, and their access should be logged centrally. Ask for logs from every environment, retained under one policy, and test that a sample change can be traced from the log back to a named person and a Git commit.

Identity integration and authentication settings

Assessors check how callers and administrators authenticate to each gateway, and whether that setting matches the approved standard in every location. Keep a record of the identity provider connections, such as an OpenID Connect setup with Keycloak, Microsoft Entra ID or Okta, the flows enabled, and the token validation rules. Review these settings after each change, because a gateway in one cloud can quietly keep an older authentication plugin configuration that another location has already retired.

Backup and restore records for configuration and certificates

Gateways depend on configuration stores, such as etcd for APISIX, and on TLS certificates and private keys. Auditors look for scheduled backups of both, recorded restore tests that show a gateway can be rebuilt in a second location, and a clear owner for certificate renewal. Ask for the date of the most recent restore test in each environment and the time it took, and confirm that backup copies are stored outside the environment they protect.

Patching and version support records

Each gateway version and its support status should be recorded per location, along with the dates of applied patches and the approval for each. Gateways in different clouds often fall behind at different times, so one register for the whole estate avoids gaps. Check the release lines your team uses against the project's published support statements, and confirm that the open-source edition you run still receives the fixes you need.

Can an Amazon API Gateway alternative run in our data centers?

What drives the cost of running one gateway across cloud and data centers?

Cost depends on how many gateway nodes you run in each environment, the control plane you choose, and the people who operate it. The software licence for the core gateway is not the largest variable for most teams. The one-time costs are design, migration of routes and policies, identity integration and testing. The recurring costs are compute for gateway nodes, the configuration store (for APISIX, an etcd cluster; for Kong Gateway in DB-less mode, a Git repository and a pipeline), load balancers, logging and monitoring, certificate management, upgrades and on-call effort. Ask for each of these as a separate line in a quote, and ask which items depend on the number of environments rather than the number of calls.

Which licences should we confirm before committing to a self-hosted gateway?

Confirm the licence of each component you plan to run, not only the gateway. Apache APISIX is released under the Apache License 2.0, and the Kong Gateway repository is also Apache-2.0. 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, so a fully self-run Kong design may need an Enterprise licence. Tyk Gateway is MPL-2.0 except code in the ee folder, and its dashboard and developer portal are commercial. Check whether the features your policies need, such as database-dependent plugins or a management GUI, fall under a paid tier. Get written confirmation from the vendor for each one.

Can our own team migrate APIs to a self-hosted gateway without an outside partner?

Yes, a capable platform team can do it, provided it has time, a test environment and clear ownership of the gateway after go-live. The open-source projects publish installation paths for Docker, Kubernetes and Linux packages, and the APISIX documentation describes three deployment modes so you can match the design to your network. The harder parts are usually identity integration, mapping existing policies, and running the gateway as a service with patching and monitoring. Partner help is most useful where the team lacks capacity or has not run production gateways before. DeployOpen works through fixed-scope engagements, and the scope, deliverables and timeline are agreed in writing before work starts.

What does a migration need from our platform and security teams?

Platform engineers need to provision the gateway hosts or clusters in each environment, decide how configuration is stored and promoted, and set up load balancing and DNS. Security engineers need to define how clients authenticate, usually through an identity provider. The APISIX openid-connect plugin supports providers such as Keycloak, Microsoft Entra ID and Okta, with flows including authorization code, client credentials and token introspection. Security teams also need to review TLS configuration, admin API exposure, and how secrets are stored. Plan time for reviews of each route's authentication and rate limits before traffic moves.

How long does a migration take and what makes it longer?

The duration depends on the number of APIs, how many use cloud-specific integrations, and how much of each API's behavior lives in authorizers, usage plans or custom code. A small estate with stateless proxies moves far faster than one with many Lambda-backed or custom-authorized APIs. Other drivers include the number of environments, the amount of testing needed for each stage, change approval windows and parallel running. No duration figure is given here because none has been supplied. Ask any provider to break the timeline into inventory, design, pilot, migration waves and cutover, and to show what each phase depends on.

What should a fixed-scope quote for a multi-environment gateway include?

Ask for a written scope that lists the environments covered, the number of APIs and their integration types, the gateway deployment modes, the identity provider integration, and the observability stack. Request deliverables such as the deployment code, route and policy definitions, runbooks, backup and upgrade procedures, and test evidence. Ask what is out of scope, for example custom plugin development, application changes, or ongoing support. Confirm who holds the licences, how changes after signing are handled, and whether ongoing support or upgrades are offered as a separate retainer. DeployOpen does not publish a price list; a quote follows from the written scope.

Does one self-hosted gateway work the same way in every environment?

The same gateway software can run in cloud, on-premises and air-gapped networks, but the surrounding parts differ. APISIX supports traditional, decoupled and standalone modes, and standalone mode reads a YAML or JSON file and hot-reloads changes every second without an etcd cluster. Kong Gateway's DB-less mode reads declarative files that can be kept in Git, but only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Check which plugins your policies need before choosing a mode for each environment, because the choice can split one estate into two configuration models.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source gateways inside your own cloud accounts, data centers or air-gapped networks. For a multicloud or on-premises gateway, the work starts with a written scope that fixes which APIs, clouds and sites the single gateway must serve before any configuration is migrated.

How we scope

Inventory every API, its clouds, data centers and consumers, and which Amazon API Gateway features each one depends on today.
Agree in writing which gateway platform, deployment mode and control plane layout will run in each environment.
Define deliverables, timelines and acceptance tests before work starts, since engagements are fixed-scope.

How we build

Deploy the chosen gateway identically in each cloud and site, using declarative configuration kept under version control.
Re-create authentication, rate limiting and routing policies per environment, and test them against your identity provider.
Run security testing and load testing on the gateway and its control plane before any traffic is moved.

How we hand over

Deliver runbooks for deployment, upgrades, certificate rotation, backup and restore, and incident response across all sites.
Document the gateway's configuration model, plugin inventory and the features that need a commercial license, so you know what is covered.
Provide evidence and control documentation for your own compliance assessors, who issue any audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Track vendor release lines and end-of-life dates for each gateway version you run, and plan upgrades in writing.
Confirm with the vendor which edition, license and support terms apply to your environments before you commit.

Amazon API Gateway alternative for multicloud and on-premises APIs