These three products end up on the same shortlist constantly, and they should not. They are not three implementations of one idea. They are three different answers to the question of what an API gateway is for, and the comparison only becomes useful once you accept that.
Kong is a bet on the data plane. You get a proxy you can run anywhere, with a plugin model, and you take on the operating. Apigee is a bet on the API program: lifecycle, products, developers, analytics, monetisation, with a proxy included because you need one. AWS API Gateway is a bet on not operating anything, at the cost of a policy model that is thin and a configuration shape that goes nowhere else.
Teams usually arrive here mid-migration. Either an internal platform grew enough that hand-rolled middleware stopped scaling, or a legacy gateway is up for renewal and somebody wants out. In both cases the decision that matters is not which has more features. It is which one your team can actually operate on a bad day, and how much of your work is trapped if you are wrong.
So this compares them on four things: what happens to a request inside each, how deep the lock-in goes and where exactly it lives, what each costs you in operational attention, and which team profile each one actually fits.
Key takeaways
- Kong gives you a proxy and a plugin runtime. Apigee gives you an API program with a proxy inside it. AWS API Gateway gives you an absence of operations. These are not substitutes.
- Lock-in depth runs in the opposite order to convenience: Kong config is mostly portable, Apigee policy XML is not, and AWS configuration plus Lambda authorizers is the deepest of the three.
- Kong asks for operational capacity you may not have. Apigee asks for modelling discipline and a procurement cycle. AWS asks you to accept per-request pricing forever.
- The migration cost between any two of these is dominated by custom policy code, not routes. Count your custom plugins, policy XML files and authorizers before you estimate anything.
Three different bets
Kong bets that the gateway is infrastructure. The product is an Nginx and OpenResty data plane with a Lua plugin runtime, distributed as something you deploy: a container, a package, a Kubernetes controller. There is a commercial control plane, and there is a hosted version of that control plane, but the centre of gravity is a proxy that runs in your environment under your control.
The consequence is that Kong behaves like infrastructure in every way, including the unpleasant ones. You choose whether it has a database. You size it. You patch it. You decide what happens when a plugin misbehaves. In exchange, it runs wherever you run, the same configuration works in every environment, and your escape route is comparatively short.
Apigee bets that the gateway is the least interesting part of an API program. Its object model tells you this immediately. An API proxy is one object. An API product is a different object, bundling proxies and operations into something a consumer subscribes to. A developer is an object. An app belongs to a developer and holds credentials against products. Environments hold deployed proxy revisions. None of that is proxy configuration; all of it is program management.
That model is right when the API is a commercial product with external consumers who need onboarding, tiering and reporting. It is expensive overhead when the API is internal plumbing and there are no developers to onboard because the consumer is the team down the hall.
AWS API Gateway bets that you would rather not have a gateway at all. There is no node, no version, no capacity planning and no patching. Authentication is IAM or Cognito, which is configuration. The integration targets are AWS services, so fronting a Lambda or a Step Function requires no proxy code. What you give up is depth: the policy model covers the common cases and then abruptly ends, and beyond that everything becomes a Lambda authorizer or a custom integration you write and operate anyway.
How a request actually flows through each
The differences in the request path explain most of the differences in behaviour.
Kong. A request hits Nginx, Kong matches a route from in-memory configuration, and the plugin chain runs in phase order: certificate, rewrite, access, response, log. Each plugin is Lua running in the same worker process, so a plugin that blocks is a worker that blocks. The access phase is where authentication and rate limiting happen, and both may reach outside the process. Rate limiting against a shared store is a network call; JWT verification with a cached key set is not. If Kong is running in database-backed mode, route and consumer lookups can also reach Postgres, though a local cache normally absorbs that.
The latency you actually observe is one hop plus the plugin chain, and the plugin chain is dominated by whichever plugin makes a network call.
Apigee. A request hits the proxy endpoint, runs a request flow of policies, hits a target endpoint flow, calls the backend, then runs a response flow. Policies are declarative steps in a flow, each configured in XML, with conditional attachment. Quota and analytics policies are first-class and integrate with the product and developer model, so a quota is not just a counter but a counter attached to an app’s subscription to a product.
That integration is the value and also the weight. A quota in Apigee knows which developer app it belongs to and shows up in analytics by product. A quota in Kong is a number in a Redis key. The former is what an API program needs; the latter is what an internal platform needs.
AWS API Gateway. A request hits the managed endpoint, is matched against a route or resource and method, optionally passes an authorizer, optionally has request mapping applied, and is forwarded to an integration. If the authorizer is a Lambda, that is a function invocation in the request path, with the cold start and concurrency behaviour a function has. Authorizer results are cacheable by token, which is the single most important tuning knob in the product and one teams routinely leave off.
The mechanism to understand here is that the gateway itself is not where your latency variance comes from. Your variance comes from the authorizer function and from the integration, both of which are your code with your cold starts.
Needs first-hand data: Put the same upstream behind all three with an equivalent policy chain of token validation plus a per-consumer quota, and measure added p50 and p99 latency, plus the p99.9 tail. For AWS specifically, measure with the authorizer cache enabled and disabled, because that difference is likely to dominate every other number in the comparison.
Where the lock-in actually lives
Every vendor in this category says migration is easy. It is easy for the parts nobody spends time on and hard for the parts where all the work went. Routes, upstreams, TLS and timeouts translate mechanically between all three. What does not translate is policy logic, and the three differ enormously in how much policy logic they encourage you to write.
Kong: shallow, with one deep spot. Declarative Kong configuration is a YAML file describing services, routes, consumers and plugin instances. The concepts map onto every other gateway in the category, so a translation is tedious rather than hard. Built-in plugin configuration translates approximately, since every gateway has a rate limiter and a JWT validator with different field names.
The deep spot is custom Lua plugins. Those are programs. They encode business rules, they were written against Kong’s plugin lifecycle and its PDK, and they do not port. If you have three custom plugins, migration is a project. If you have thirty, migration is not happening. The discipline that keeps Kong shallow is to treat custom plugins as a last resort and to keep business logic in services where it belongs.
Apigee: deep, by design. Policy XML is a vendor-specific programming model, and complex proxies accumulate a lot of it: mediation, message-level security, fault handling, conditional flows, and frequently JavaScript or Java callouts inside the flow. None of it moves. Beyond the policy layer, the product, developer and app model is also Apigee-shaped, so the consumer-facing side of your API, meaning who has keys, which product they subscribe to, what quota applies, has to be reconstructed rather than exported.
There is a second, subtler lock-in: the reporting. Apigee analytics by product and developer becomes what your business reviews look like, and leaving means rebuilding those reports from raw traffic data, which is covered in API analytics. That is not a technical blocker, and it is frequently the political one.
AWS API Gateway: deepest, and least visible. The gateway configuration itself is not large, but it is entirely AWS-shaped: resource and method structures, integration request and response mapping templates in a template language used nowhere else, stage variables, usage plans and API keys with AWS semantics. More significantly, the gateway is usually load-bearing in an architecture where the backends are Lambda functions with IAM-based authorisation, and extracting the gateway means reconsidering the whole shape.
The honest framing is that AWS API Gateway lock-in is not really gateway lock-in. It is the architectural commitment that made the gateway sensible in the first place, and if you are already running Lambda, IAM and Cognito, the gateway is the least of it.
What each one costs you to operate
This is where shortlists go wrong, because operational cost is the one dimension nobody puts on the comparison page.
Kong asks for a platform team, or at least a person. Someone owns the deployment topology, decides database-backed versus declarative, keeps versions current, understands why the plugin chain is ordered the way it is, and knows what to look at when latency rises. None of that is unreasonable, and all of it is real. The failure pattern for small teams is adopting Kong in database-backed mode because the tutorial did, then discovering months later that Postgres is now on the critical path of every request, and nobody planned for that.
Kong’s specific operational hazards, worth knowing in advance: plugin ordering interactions that fail silently, memory behaviour under large numbers of routes, and configuration drift between what the admin API holds and what the repository says. The last one is avoidable entirely by refusing to use the admin API as a primary interface.
Apigee asks for modelling discipline and patience. The operational burden is low if you use the managed offering, and the conceptual burden is high. Teams that model it badly, typically by creating one API product per proxy and never using the abstraction, end up with all the complexity and none of the benefit. Getting it right means deciding upfront what a product is, what a developer is, and how tiers map onto quotas, and that is a design exercise involving people outside engineering.
There is also a procurement cost that is genuinely part of the evaluation. You will not casually try Apigee over a weekend and reach a confident conclusion, which biases evaluations toward whatever you can self-serve.
AWS API Gateway asks for almost nothing, then sends a bill. There is no operational burden worth naming. The costs are elsewhere: per-request pricing that scales linearly and never gets cheaper per unit as you grow, hard limits on payload size and timeout that surface at the worst moment, and a policy model where the first unusual requirement turns into a Lambda function you now own, monitor and pay for. Teams underestimate that last transition. An authorizer function is a service in your request path with its own cold starts, concurrency limits and failure modes, and it moved the operational burden rather than removing it.
Needs first-hand data: For one real production API, project twelve months of traffic and compute the total cost under all three: AWS per-request plus authorizer invocations plus caching, Kong as node count plus the datastore plus a fraction of an engineer, and Apigee at the tier your call volume lands in. The crossover point where self-hosting becomes cheaper than per-request pricing is the single most useful number in this whole comparison, and it depends entirely on your request mix.
Kong Gateway
Kong is the self-hostable data plane, and its distinguishing property is optionality: the same proxy runs standalone from a config file, in Kubernetes with a controller, or as a data plane attached to a hosted control plane. That means the deployment decision stays reversible in a way neither of the other two allows, and it is the main reason Kong survives in shortlists against much larger vendors.
Pros
- Runs anywhere you run, with the same configuration, so multi-cloud and hybrid are the normal case rather than an exception
- Largest plugin ecosystem in the self-hostable tier, covering most policy needs without writing code
- Declarative configuration mode removes any datastore from the request path and makes gateway config a reviewable artefact
- Shallowest lock-in of the three, provided you keep custom Lua plugins to a minimum
Cons
- You are operating it, including version upgrades, capacity and the plugin chain’s behaviour under load
- Governance and the developer portal are both commercial, so an external API program means the commercial tier or another product entirely
- Database-backed mode couples API availability to Postgres availability, and teams adopt it without noticing they made that trade
Best for: Teams with platform engineering capacity who want one gateway across environments and clouds, and whose external-consumer requirements are modest or handled elsewhere.
Pricing: Open source build has no licence cost. The commercial offering meters on the hosted control plane plus the number of data plane nodes or services under management, with enterprise plugins gated by tier.
Apigee
Apigee is an API program suite, and the proxy is the smallest part of what you are buying. Its object model separates the API implementation from the commercial packaging of that API, which is exactly the separation you need when external developers subscribe to tiers, and exactly the overhead you do not need when the caller is another team in the same building.
Pros
- The most complete model in the category for external API programs: products, developers, apps, plans and monetisation as first-class objects
- Proxy revisions are versioned, promotable artefacts, which fits regulated change control better than live configuration editing
- Analytics by developer, app and product is the reporting an API business actually needs, rather than raw traffic metrics
- Policy layer covers heavy enterprise mediation requirements, including message-level security and complex transformation
Cons
- Policy XML plus callouts is the least portable configuration of the three, and complex proxies accumulate a great deal of it
- Large conceptual surface that must be modelled correctly upfront, and modelling it badly gives you the complexity without the benefit
- Strongly Google Cloud oriented, with an enterprise sales motion that makes hands-on evaluation slow and poor value for purely internal APIs
Best for: Organisations where the API is a commercial product with external developers, tiered access, formal change control and someone accountable for adoption numbers.
Pricing: Subscription tiers gated by API call volume, with separate entitlements for environments, monetisation and advanced security, sold on annual commitment.
AWS API Gateway
AWS API Gateway is the option with no operational surface, and evaluating it on features misses the point. Its case is that a small team gets a production-grade managed edge with IAM integration and no nodes to run. Its case weakens as volume rises and as requirements drift away from the built-ins, because both of those turn into cost you did not anticipate.
Pros
- Zero infrastructure to operate, which for a team without platform engineers is worth more than any feature comparison
- IAM, Cognito and resource policies make authentication configuration rather than deployment
- Direct service integrations front Lambda, Step Functions, SQS or DynamoDB without writing or running a proxy service
- Scales without capacity planning, including through traffic patterns that would require thought on a self-hosted gateway
Cons
- Per-request pricing scales linearly forever, so high-volume low-value traffic is structurally expensive compared to a node you run
- Thin policy model; the first unusual requirement becomes a Lambda authorizer or custom integration you now own and pay for
- Hard payload size and timeout limits that are not tunable, plus the deepest practical lock-in, because the gateway is load-bearing in an architecture built on other AWS primitives
Best for: Teams already committed to AWS, with serverless backends and moderate request volume, who would rather spend engineering time on product than on a proxy.
Pricing: Per-request metering with different rates by gateway type, plus data transfer, plus optional caching billed by cache size per hour.
How to choose
Three questions settle it, in this order.
Do you have external consumers you will never speak to? If yes, and they need onboarding, tiers, quotas and usage visibility, Apigee is doing something the other two do not do at all. Kong can get there with its commercial portal, and AWS usage plans are a thin version of the same idea, but neither is the same product. If no, Apigee is overhead and you should stop considering it.
Do you have someone who will own a proxy? If nobody owns it, Kong will be adopted, configured once, and then run unpatched at a version nobody remembers choosing. That is worse than the per-request bill from a managed service. Be honest about this, because it is a capacity question rather than a skill question.
How much does your traffic cost per request, and what is it worth? Per-request pricing is excellent when requests are valuable and moderate in volume, and poor when they are chatty internal calls or high-frequency polling. Run the projection before you commit, because this is the variable that most often forces a migration eighteen months later.
| Kong Gateway | Apigee | AWS API Gateway | |
|---|---|---|---|
| The bet | Self-hostable data plane | Enterprise API program suite | Cloud-native managed service |
| Runs where | Anywhere, including your own hardware | Managed, Google Cloud oriented, hybrid data planes available | AWS only |
| Policy model | Plugins, configuration plus optional Lua | Declarative policy XML with callouts | Built-ins plus Lambda authorizers |
| Consumer model | Consumers and credentials; portal is commercial | Developers, apps, products, plans, monetisation | API keys and usage plans |
| Request-path dependencies | Optional datastore, shared store for rate limits | Managed by the vendor | Authorizer function if you use one |
| Lock-in lives in | Custom Lua plugins | Policy XML, product model, analytics reporting | Mapping templates, authorizers, surrounding AWS architecture |
| Operational burden | Yours | Low, conceptual burden high | Effectively none |
| Pricing meter | Nodes or services under management | API call volume tier plus entitlements | Per request plus caching plus data transfer |
If none of the three fits, the likely reason is that you wanted a gateway and got offered a platform. Open source gateways covers the lighter self-hostable options, and the gateway comparison covers the full category on mechanism. If the deployment target is Kubernetes, the shortlist changes enough that Kubernetes gateways is the better starting point.
Frequently asked questions
Is Kong actually cheaper than AWS API Gateway?
It depends entirely on request volume and on whether you count engineer time. Kong’s cost is roughly fixed with node count while AWS scales linearly with requests, so there is a crossover volume above which self-hosting is cheaper on infrastructure alone. Below that volume, and for any team without platform capacity, the managed service usually wins even before you count the salary of whoever would operate the alternative.
Can I use Apigee in front of services running outside Google Cloud?
Yes. Apigee can proxy any reachable HTTP backend, and hybrid deployment options let the data plane run in your own environment. It works, and it works against the grain: the integration depth, the identity story and the operational tooling all assume Google Cloud, so you are choosing it for the program features and accepting friction elsewhere.
What happens to my rate limits if the shared store goes down?
This differs by product and by configuration, and it is the question to ask in every evaluation. Kong’s rate limiting can be configured to fail open or fail closed when its store is unreachable, and the right default is usually open for quotas and closed for authentication. Apigee and AWS manage this themselves, which removes the decision and also removes your visibility into it. The behaviour matters more than the algorithm, and both are covered in rate limiting solutions.
Which one handles API versioning and deprecation best?
Apigee, on the strength of its revision model and its ability to attach products and developers to specific versions, which makes consumer migration trackable rather than guessed at. Kong and AWS both handle version routing fine and give you much less help knowing who is still on the old version. That gap is the subject of API versioning and deprecation.
How long does migrating between these actually take?
Count your custom policy artefacts, not your routes. Routes and upstreams translate in days regardless of estate size, because the translation is mechanical and scriptable. Custom Lua plugins, Apigee policy XML with callouts, and Lambda authorizers each need to be reimplemented and retested individually, and each carries business behaviour that is usually undocumented outside the code. That count, multiplied by the time to reverse-engineer one of them, is your actual timeline.
Should authentication live in the gateway in all three cases?
Token validation should, yes. All three can verify a signature or introspect a token and reject what fails, and doing it at the edge means unauthenticated traffic never reaches your services. Authorisation decisions should stay in the services, because only they know what a caller may do with a specific resource. The choice of identity provider constrains this more than the gateway does, which is the argument in API authentication tools.
Related reading
- Best API management platforms — the category map, and whether you need a platform at all.
- Best API gateways — the full category on mechanism, added latency and failure domains.
- Best open source API gateways — the lighter self-hostable options and where the enterprise wall falls.
- Best API gateways for Kubernetes — a different shortlist entirely once the target is a cluster.
- Best API analytics tools — rebuilding consumer-level reporting if you leave a platform that provided it.
- Best rate limiting solutions — shared counters, accuracy and behaviour during a partition.