AWS API Gateway vs Kong: architecture and deployment

Compare AWS API Gateway and Kong, trace seven request stages, and learn how Kong's traditional, hybrid and DB-less deployment modes differ.

Player not loading? Watch on YouTube

This overview compares AWS API Gateway with Kong Gateway and explains where a gateway fits between clients and backend services. The speaker traces seven request stages, covering TLS termination, authentication, rate limiting, transformation, routing, backend processing and observability. JWT validation and token bucket limits receive detailed explanations, including the use of HTTP 429 responses when a consumer exceeds a limit.

The architecture discussion covers public edge gateways, private internal APIs, Kubernetes ingress, hybrid enterprise deployments and backends tailored to different clients. It distinguishes external client traffic from service-to-service communication handled by a service mesh.

AWS API Gateway is presented as a managed option with HTTP, REST and WebSocket APIs. The speaker contrasts HTTP APIs with REST features such as usage plans, response caching and request validation. Kong is the self-hosted option in the comparison, with traditional PostgreSQL-backed deployment, hybrid control and data planes, and DB-less YAML configuration. In the hybrid example, data planes retain cached configuration when the control plane becomes unavailable.

The comparison weighs AWS integration against Kong's portability and operational workload. The speaker's latency figures are presented without benchmark methodology. Closing advice includes storing configuration in Git, measuring plugin overhead and keeping admin APIs off the public internet.