API Gateway Patterns: Kong vs Envoy vs AWS API Gateway in 2026

API Gateway Comparison: Kong vs Envoy vs AWS API Gateway

Every microservices architecture needs an API gateway — the single entry point that handles routing, authentication, rate limiting, and observability for all your services. But choosing between Kong, Envoy, and AWS API Gateway is a consequential decision that affects performance, operational complexity, and vendor lock-in. Therefore, this API gateway comparison breaks down each option’s strengths, weaknesses, and ideal use cases with practical configuration examples.

What an API Gateway Actually Does

An API gateway sits between clients and your backend services, handling cross-cutting concerns that every API needs: request routing (directing traffic to the right service), authentication and authorization (validating tokens, API keys), rate limiting (protecting services from overload), request/response transformation (header manipulation, body mapping), load balancing, circuit breaking, and observability (metrics, logging, tracing).

Without a gateway, each service implements these concerns independently — leading to inconsistent security policies, duplicated code, and no central place to monitor API traffic. Moreover, the gateway provides a stable external interface even as your internal service topology changes. Clients talk to the gateway; the gateway routes to services. You can refactor, split, or merge services without changing client code.

Kong: The Plugin-Powered Gateway

Kong is built on Nginx and OpenResty (LuaJIT), combining Nginx’s battle-tested performance with a flexible plugin architecture. It’s the most feature-rich open-source API gateway and the easiest to extend with custom plugins.

# Kong declarative configuration (kong.yml)
_format_version: "3.0"

services:
  - name: user-service
    url: http://user-service:8080
    routes:
      - name: user-api
        paths:
          - /api/v1/users
        strip_path: false
    plugins:
      - name: rate-limiting
        config:
          minute: 100
          policy: redis
          redis_host: redis
      - name: jwt
        config:
          claims_to_verify:
            - exp
      - name: cors
        config:
          origins: ["https://myapp.com"]
          methods: ["GET", "POST", "PUT", "DELETE"]
          headers: ["Authorization", "Content-Type"]
      - name: prometheus
        config:
          per_consumer: true

  - name: order-service
    url: http://order-service:8080
    routes:
      - name: order-api
        paths:
          - /api/v1/orders
    plugins:
      - name: rate-limiting
        config:
          minute: 50
      - name: request-transformer
        config:
          add:
            headers:
              - "X-Request-ID:$(uuid)"

Kong strengths: extensive plugin ecosystem (200+ plugins), excellent admin API for dynamic configuration, supports declarative (DB-less) and database-backed modes, and mature enterprise features (Kong Gateway Enterprise). Kong weaknesses: higher memory usage than Envoy (~200MB baseline), Lua plugin development has a smaller community than other languages, and the enterprise version is expensive.

Additionally, Kong’s Admin API allows runtime configuration changes without restarts — add routes, enable plugins, and update rate limits while the gateway is serving traffic. This operational flexibility is valuable for teams that need to respond quickly to changing requirements.

Envoy: The Cloud-Native Proxy

Envoy is a high-performance C++ proxy designed for cloud-native architectures. It’s the backbone of service meshes (Istio, Linkerd) and excels at advanced traffic management, observability, and protocol support. Envoy is more a programmable proxy than a traditional API gateway — it’s extremely powerful but requires more configuration effort.

# Envoy configuration (envoy.yaml)
static_resources:
  listeners:
    - name: api_listener
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 8080
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.
                  filters.network.http_connection_manager.v3.
                  HttpConnectionManager
                stat_prefix: api_gateway
                route_config:
                  name: local_routes
                  virtual_hosts:
                    - name: api
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/api/v1/users"
                          route:
                            cluster: user-service
                            timeout: 5s
                            retry_policy:
                              retry_on: "5xx,reset"
                              num_retries: 3
                        - match:
                            prefix: "/api/v1/orders"
                          route:
                            cluster: order-service
                            timeout: 10s
                http_filters:
                  - name: envoy.filters.http.ratelimit
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.
                        filters.http.ratelimit.v3.RateLimit
                      domain: api_gateway
                      rate_limit_service:
                        grpc_service:
                          envoy_grpc:
                            cluster_name: rate_limit_service
                  - name: envoy.filters.http.router

  clusters:
    - name: user-service
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: user-service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: user-service
                      port_value: 8080
      health_checks:
        - timeout: 2s
          interval: 10s
          unhealthy_threshold: 3
          healthy_threshold: 2
          http_health_check:
            path: /health

Envoy strengths: lowest latency and highest throughput (C++), native gRPC and HTTP/2 support, built-in circuit breaking and outlier detection, L4 and L7 protocol support, and xDS API for dynamic configuration from control planes. Envoy weaknesses: verbose YAML configuration, steeper learning curve, requires external services for features Kong includes built-in (auth, rate limiting), and harder to extend (C++ or WASM filters vs Kong’s Lua plugins).

AWS API Gateway: The Managed Option

AWS API Gateway eliminates operational overhead entirely — no servers to manage, no scaling to configure, no patches to apply. It integrates natively with AWS services (Lambda, IAM, Cognito, CloudWatch) and offers two variants: REST API (feature-rich, WebSocket support) and HTTP API (simpler, cheaper, faster).

# AWS SAM template for API Gateway
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ApiGateway:
    Type: AWS::Serverless::HttpApi
    Properties:
      StageName: prod
      CorsConfiguration:
        AllowOrigins: ["https://myapp.com"]
        AllowMethods: ["GET", "POST", "PUT", "DELETE"]
        AllowHeaders: ["Authorization", "Content-Type"]
      Auth:
        DefaultAuthorizer: CognitoAuthorizer
        Authorizers:
          CognitoAuthorizer:
            AuthorizationScopes:
              - email
            IdentitySource: "$request.header.Authorization"
            JwtConfiguration:
              issuer: !Sub "https://cognito-idp.us-east-1.amazonaws.com/${UserPool}"
              audience:
                - !Ref UserPoolClient

  UserFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: handlers/users.handler
      Runtime: nodejs20.x
      Events:
        GetUsers:
          Type: HttpApi
          Properties:
            ApiId: !Ref ApiGateway
            Path: /api/v1/users
            Method: GET
        CreateUser:
          Type: HttpApi
          Properties:
            ApiId: !Ref ApiGateway
            Path: /api/v1/users
            Method: POST

AWS API Gateway strengths: zero operational overhead, auto-scaling, native AWS integration, usage plans and API keys built-in, WebSocket API support. AWS API Gateway weaknesses: vendor lock-in (hard to migrate away), higher latency than self-hosted options (20-50ms added), cost can spike with high traffic ($3.50 per million requests + data transfer), limited customization compared to Kong/Envoy, and 30-second request timeout limit.

When to Choose Each Gateway

Choose Kong when: you need a feature-rich gateway with minimal custom development, your team prefers declarative configuration, you want flexibility to run on any infrastructure (cloud, on-prem, hybrid), or you need the extensive plugin ecosystem for common API management patterns. Kong is the best all-around choice for most teams.

Choose Envoy when: you need the absolute lowest latency and highest throughput, you’re building a service mesh or already use Istio/Linkerd, you need advanced traffic management (canary deployments, traffic splitting, fault injection), or you have gRPC-heavy workloads. Envoy is the performance king but demands more expertise.

Choose AWS API Gateway when: you’re all-in on AWS and want zero operational burden, your APIs are serverless (Lambda-backed), traffic is moderate (cost becomes prohibitive at very high volumes), or you need rapid prototyping without infrastructure setup.

Related Reading:

• Saga Pattern for Distributed Transactions
• Event-Driven Architecture Guide
• gRPC and Protobuf for Microservices

Resources:

• Kong Gateway Documentation
• Envoy Proxy Documentation
• AWS API Gateway Documentation

In conclusion, there’s no universal best API gateway — the right choice depends on your infrastructure, team expertise, and requirements. Kong offers the best balance of features and simplicity. Envoy delivers unmatched performance for cloud-native architectures. AWS API Gateway eliminates operations entirely at the cost of flexibility. Evaluate based on your specific traffic patterns, latency requirements, and operational capacity.