Stop Paying for an API Gateway. You Already Have One.

There's a good chance your infrastructure already includes NGINX. It handles roughly a third of all websites on the internet. It's sitting in front of your services right now, doing reverse proxy work, terminating SSL, maybe serving static files.

And there's also a good chance you're paying for a separate API gateway product on top of it.

Kong. Apigee. AWS API Gateway. Maybe you're evaluating Envoy or Traefik. Maybe your team just approved a five-figure annual contract for something that promises rate limiting, load balancing, and security headers.

Here's the thing: NGINX already does all of that. Not with plugins you have to buy. Not with a premium tier you have to negotiate. With configuration you can write this afternoon.

The Five-Figure Question

Enterprise API gateway pricing is designed to be confusing, and that's not an accident. Kong Konnect charges per service, per API request, and per feature tier. At $105 per gateway service per month and $34 per million requests, a mid-sized deployment with a dozen microservices handling moderate traffic easily crosses $50,000 a year. Scale beyond that, and overage charges for high-volume APIs can add another $10,000 a month in traffic costs alone.

AWS API Gateway charges $3.50 per million requests. That sounds reasonable until you do the math on a mid-size application handling a hundred million requests a month: $350 per month, $4,200 per year, for what is fundamentally proxying HTTP requests between your own services. And that's before you account for the added latency that the managed service introduces on every single request.

What do you get for that money? Routing. Load balancing. Rate limiting. SSL termination. Authentication. Caching. Logging.

Every one of those capabilities exists in NGINX. Not as a theoretical possibility, but as a battle-tested feature set that has been handling production traffic at massive scale since 2004.

What NGINX Actually Does (That Teams Keep Paying Others For)

Let's be specific. These are the API gateway features teams typically evaluate, and what NGINX provides natively.

Routing and request handling. Upstream blocks, location matching, URL rewriting, header manipulation, WebSocket proxying. NGINX's location-based routing handles prefix matching, exact matching, and regex matching. You can compose them with include directives to keep configurations DRY across dozens of services. A properly structured NGINX gateway configuration for a twenty-service architecture fits in a few hundred lines of version-controlled text.

Load balancing with failover. Round robin, weighted distribution, least connections, IP hash. Passive health checks that mark failing servers as down after a configurable number of errors. Backup servers that only receive traffic when primaries go down. Connection draining during deployments. Most dedicated gateway products charge for an "enterprise tier" to get this. NGINX ships it.

Rate limiting that actually works. NGINX's limit_req module uses a leaky bucket algorithm that has been refined for years. You can layer multiple rate limit zones in a single configuration: a global per-IP limit to catch general abuse, a per-API-key limit for consumer-level throttling, and tight per-endpoint limits on expensive operations like authentication (brute force protection) or search queries. Five requests per minute on your login endpoint. Fifty per second globally. One hundred per second per API key. All defined in a configuration file, all testable, all version-controlled.

SSL/TLS termination. Let's Encrypt automation, modern cipher suites, HSTS, OCSP stapling, mutual TLS. Session caching that avoids expensive TLS handshakes on repeated connections. This is table stakes for any production gateway, and NGINX handles it without a third-party plugin or a paid tier upgrade.

Response caching. Cache zones, bypass rules, microcaching for dynamic content, and stale content serving when backends go down. That last one is underrated: properly configured, NGINX can keep serving cached responses to your users even when an upstream service is failing. Your customers see cached data while you fix the problem, instead of seeing a 502 error.

Security hardening. CORS headers, Content Security Policy, request size limits, attack pattern blocking, and IP allowlisting. NGINX can block access to sensitive file paths (.env, .git, database configs), restrict HTTP methods to only those your API actually uses, and add a full set of security response headers. All in configuration. All auditable.

Observability. JSON structured logging with request IDs, upstream response times, SSL protocol details, and downstream header forwarding. A gateway handling a thousand requests per second generates structured logs you can pipe into Grafana, Kibana, or any aggregation tool. Request IDs that propagate through your entire service chain so that when something breaks at 2 AM, you search one ID and see every log line for that request across every service.

That's not a marketing comparison chart. That's what a properly configured NGINX instance does in production, today.

"But Kong Is Built on NGINX Anyway"

This is true, and it's exactly the point. Kong uses NGINX (via OpenResty) for the I/O layer and adds a management layer on top: a PostgreSQL or Cassandra database, an admin API, a plugin ecosystem, and a dashboard.

If you need per-consumer analytics, a developer portal, API key lifecycle management, and monetization workflows, Kong provides those as managed services. Those are legitimate capabilities that NGINX does not provide natively.

But if what you actually use is routing, load balancing, rate limiting, SSL, and logging? You're paying for a management layer on top of a tool you already have. Kong's own documentation acknowledges that NGINX handles the core I/O and proxying. The question is whether the management layer justifies the cost for your use case.

For most teams, it doesn't.

"But We Need a Kubernetes-Native Solution"

Fair point. And this one deserves a direct answer.

The Kubernetes Ingress NGINX controller has been officially retired. Best-effort maintenance ended in March 2026. The Kubernetes community has formally moved to the Gateway API as the standard for traffic management.

Here's why this is actually good news: the old Ingress spec was too simple to be useful for real API gateway work. Every vendor compensated by stuffing configuration into vendor-specific annotations. A typical production Ingress resource had more configuration in its annotations than in its actual spec. If you switched from the NGINX ingress controller to Traefik, every annotation had to be rewritten. The "standard" was standard in name only.

The Gateway API fixes this. It's a completely new set of custom resource definitions designed by engineers from Google, Microsoft, Red Hat, and F5/NGINX. It can express header-based routing, traffic splitting for canary deployments, per-route timeouts, and TLS configuration natively, without annotations.

And NGINX Gateway Fabric is the NGINX project's implementation of the Gateway API. It supports HTTPRoute, GRPCRoute, TLS termination, traffic splitting for blue-green and canary deployments, and role-based configuration that separates infrastructure concerns from application routing.

The Ingress controller is dead. NGINX in Kubernetes is not. The migration path is clear, and for most teams it's a configuration translation, not a rearchitecture.

When You Actually Need Something Else

NGINX is not the right choice for every team in every situation.

If you need a service mesh with sidecar proxies and mutual TLS between every service, Envoy and Istio are purpose-built for that. Envoy's xDS protocol pushes routing changes to thousands of proxy instances in seconds, without reloads. NGINX can do mTLS at the gateway level, but it's not a mesh.

If you need automatic service discovery where deploying a container instantly creates a route, Traefik does that out of the box with Docker labels. NGINX requires explicit configuration and a reload.

If your primary concern is kernel-level performance on Kubernetes at massive scale, Cilium uses eBPF to process traffic directly in the Linux kernel, eliminating the overhead of copying packets between kernel space and user space.

And if you need a developer portal with API key management, usage analytics, and monetization workflows, those are legitimate product features that NGINX doesn't provide natively.

But if your actual needs are routing, load balancing, rate limiting, SSL, caching, and security? You're paying for capabilities you already own.

The Real Cost of "Free"

The honest objection to using NGINX as your API gateway isn't that it can't do the job. It's that it requires you to understand NGINX configuration.

That reputation for complexity isn't entirely undeserved. The interaction between location blocks, upstream definitions, and module directives can surprise you if you're guessing rather than understanding the evaluation order. A misconfigured proxy_pass or a wrong rate limit zone can take down a service in ways that are hard to debug at 2 AM.

But the alternative gateway products all have their own complexity. Kong has its declarative YAML, its database dependency (if PostgreSQL fails, the entire API gateway fails), and its plugin ordering quirks. Envoy's filter chain configuration is famously complex: a simple routing rule that takes five lines in NGINX requires significantly more YAML in Envoy. AWS API Gateway has its own resource model, throttling behavior, and integration latency characteristics that you'll need to learn anyway.

You're going to learn something either way. The question is whether you want to learn a tool you control, that runs on your infrastructure, that costs nothing to license, and that has two decades of production hardening behind it. Or whether you want to pay for the privilege of learning someone else's abstraction layer over the same underlying concepts.

Where to Start

If you're already running NGINX, start by auditing what your paid gateway actually does. List every feature you use. Then check whether NGINX handles each one natively.

Most teams discover that 80-90% of their gateway functionality is routing, load balancing, and SSL. NGINX does all of it. For the remaining 10-20%, decide whether it justifies the annual cost, the vendor dependency, and the operational complexity of running a separate system.

If you want a complete reference for building this out, I wrote NGINX as an API Gateway with production-ready configurations for every chapter: routing, load balancing, rate limiting, SSL, caching, security hardening, Docker Compose deployments, the Kubernetes Gateway API migration, observability, and a full production hardening checklist. Not simplified illustrations of what the config could look like. Actual configurations that handle edge cases and real deployment patterns you can adapt and deploy today.

The gateway you need is probably already installed. It's time to use it.

Shane Larson is the founder of Peak Grizzly Publishing and Grizzly Peak Software, based in Anchorage, Alaska. He writes about enterprise architecture, AI, and infrastructure from direct experience building and operating production systems.