Platform Engineering · New Zealand

Deleting a $300k API gateway: replacing Apigee with Kong

I inherited an Apigee API gateway. A consultancy had implemented it before I took ownership of the platform, and left behind the licensing that came with it. It sat in the critical path of production traffic and cost around USD 300,000 a year. The moment that platform became mine, so did the cost, and so did the decision about whether it was worth paying.

I made that decision. I audited the gateway, re-architected the edge onto Kong, and removed the licensing entirely, without changing a single thing a user could see. Every part of that, the analysis, the call, the migration, was mine end to end. No one else drove it.

What a managed API gateway sells you

A commercial gateway like Apigee is a large product. Its value proposition is the long list of capabilities beyond plain routing: traffic mediation and transformation, a developer portal, API monetisation, sophisticated analytics, threat protection, quota and spike-arrest policies, and a managed control plane you do not have to run yourself.

You pay for all of it, whether or not you use all of it. That is the nature of a platform licence, and it is where the money quietly leaks, because the features that justify the price on the sales deck are frequently the features nobody ever turns on.

The audit I ran

Before proposing any change I did the decisive work myself: I catalogued every route configured on the gateway and every policy attached to it, and mapped them against what the platform actually depended on.

The result was stark. What we used came down to a short list:

  • Request routing to backend services
  • Authentication and key validation on inbound calls
  • Basic rate limiting

That was it. None of the Apigee-specific capabilities, the monetisation engine, the developer portal, the advanced mediation, the proprietary analytics, were in play. The platform was paying enterprise prices for a fraction of an enterprise product, and everything it relied on was commodity gateway functionality that any competent proxy provides.

The most expensive line item in a lot of platforms is the set of features someone was sold but never switched on. You only find them by auditing usage yourself, not by reading the invoice.

Choosing Kong

Once I had made the requirement honest, the choice was mine and it was easy. Kong gives you exactly that commodity core, routing, authentication plugins, rate limiting, as an open-source gateway you run on your own infrastructure, with no per-call licensing attached to it. The plugin model covers auth and traffic policy cleanly, it runs happily alongside containerised workloads, and it put the control plane back in my hands rather than a vendor’s.

There was no capability I needed that Kong could not do. That is the whole test, and I owned that judgement.

Re-architecting the edge without anyone noticing

The constraint on any gateway change is that it sits in front of production, so the migration had to be invisible, and I was accountable for it staying that way.

I mapped each Apigee route to its Kong equivalent and reimplemented every policy, authentication and rate limit, as a Kong plugin myself. I stood Kong up in parallel rather than in place, so at no point was there a flag day where the old gateway went away and the new one had to work first try. I moved traffic across deliberately, service by service, keeping a fall-back at every step. When I had proven the last route on Kong, I took Apigee out.

Nothing downstream changed. The clients calling the platform never knew the gateway underneath them had been redesigned and replaced.

What it returned

Roughly USD 300,000 a year of licensing, gone, with no loss of capability and far more direct control over our own edge. The engineering effort to get there was a fraction of a single year’s licence, and the edge that carries production traffic is now something I designed rather than something I inherited and hoped about.

The lesson worth keeping

The instinct when you inherit an expensive managed platform is to assume the expense is load-bearing, that someone chose it for a reason and the capabilities justify the cost. Sometimes that is true. Often the choice was made by people who are no longer around, for a future that never arrived, and the licence renews on autopilot.

Audit the actual usage yourself before you renew anything. Map what the platform does for you against what you are paying for. When the gap is a factor of ten, own the decision, make the change, and end up with something you understand and control rather than something you rent.


This is one of the selected career impact stories on my home page. More engineering work, including tiaki, is on GitHub.

← All writing Get in touch →