A platform team is choosing between Kong, AWS API Gateway, and a plain Nginx reverse proxy to front a set of microservices. What are the core architectural differences that should drive the choice, and under what circumstances would routing everything through one central gateway be the WRONG call?

## Three axes for the comparison Comparing **Kong**, **AWS API Gateway**, and plain **Nginx** as API Gateway implementations comes down to three architectural axes: 1. how much of the API-specific behavior is built-in versus something you configure yourself, 2. how much operational burden the team takes on, and 3. how deep the resulting vendor or platform lock-in becomes. ## Where each one sits on those axes - **Plain Nginx** is a general-purpose, high-performance reverse proxy and web server; it can do path-based routing, TLS termination, and basic rate limiting (via its `limit_req` module), but anything API-specific — validating JWTs, calling an external auth server, per-route usage plans, request/response transformation — has to be hand-built, typically via Nginx's Lua scripting extension (**OpenResty**) or external auth-request modules. It's self-hosted, meaning the team owns deploying, scaling, patching, and monitoring it, but it's also maximally flexible and has no per-request cost beyond infrastructure. - **Kong** is built directly on top of Nginx/OpenResty but is purpose-designed as an API Gateway: it ships a plugin architecture with pre-built plugins for JWT/OAuth2 validation, rate limiting (including Redis-backed cluster-wide counters), request transformation, logging integrations, and a declarative or API-driven control plane for managing routes and plugins dynamically without hand-editing config files and reloading. It's still self-hosted (or available as a managed offering), so the team still owns the infrastructure, but gets substantially more API-specific behavior out of the box than raw Nginx. - **AWS API Gateway** sits at the other end of the spectrum: it's fully managed — no servers to patch or scale — with native, tight integration into the AWS ecosystem (IAM for authorization, Cognito for user pools, direct Lambda and ECS/ALB integration, native usage plans with API-key-based throttling), but it comes with AWS-specific configuration models, per-million-requests pricing that can get expensive at very high volume, platform-imposed payload size and timeout limits, and by nature commits the team more deeply to AWS as their cloud provider. ## Choosing on organizational facts The choice between these should be driven by concrete organizational facts rather than feature checklists: - A team **already fully committed to AWS** with modest-to-moderate traffic and a preference for minimizing operational surface area typically gets the most value from AWS API Gateway, trading configuration flexibility and unbounded self-hosted scalability for near-zero ops burden. - A team that needs to **run on-prem, multi-cloud**, or wants full control over the plugin pipeline and cost structure at very high request volumes (where managed per-request pricing becomes expensive) tends toward Kong or a similar self-hosted product, accepting the ops burden of running and scaling it themselves in exchange for flexibility and cost control at scale. - **Raw Nginx** is usually the right call only when the API-specific feature set needed is genuinely minimal (routing and TLS termination, nothing more) or when a team wants to build something bespoke — most teams building anything beyond simple routing eventually reinvent enough of Kong's feature set in Lua that adopting Kong directly would have been cheaper. ## The bigger question: north-south versus east-west traffic The second, arguably more important question — when centralizing all traffic through one gateway is the wrong call — comes down to distinguishing **north-south traffic** (external clients calling into the system from outside) from **east-west traffic** (services calling other services internally). A gateway's value proposition — centralized auth, rate limiting, a single stable public entry point — is specifically about the boundary between untrusted external clients and the trusted internal system. Internal service-to-service calls don't need public-facing authentication or a client-facing stable contract; they need low-latency, resilient communication with concerns like mutual TLS, internal load balancing, and retries — which is exactly what a **service mesh** (**Istio**, **Linkerd** — sidecar proxies deployed alongside each service) is designed for. Routing internal east-west traffic through the same central gateway used for external traffic: - adds an unnecessary extra network hop to every internal call, - turns the gateway into a scaling bottleneck sized for internal traffic volume (which is typically an order of magnitude higher than external request volume, since one external request often fans out into several internal calls), and - creates a shared-ownership chokepoint where every team's internal routing changes require going through the gateway team's config — actively harming the team autonomy that microservices are meant to provide. The architecturally sound default is: **gateway at the edge for north-south traffic, service mesh or direct service discovery for east-west traffic**, keeping the gateway's blast radius and traffic volume scoped to what it was actually designed to protect.