Should we use AWS API Gateway, Kong, or build a custom gateway?

AWS API Gateway is the right choice if you're already on AWS, need minimal operational overhead, and your routing requirements are straightforward -- it handles authentication, rate limiting, and Lambda or HTTP backend routing without additional infrastructure to run. Kong is the choice for organisations that need the flexibility of a plugin ecosystem (custom auth, advanced routing logic, monitoring integrations) and want to run the gateway on their own infrastructure or in Kubernetes. A custom gateway makes sense when your routing logic is complex enough that configuration-driven gateways can't express it, or when you want full control over the gateway's behaviour without configuration API limitations. The recommendation follows your existing infrastructure and operational capacity.

How do you handle API versioning at the gateway level?

The gateway handles versioning by routing requests based on the URL version prefix or Accept-Version header to different backend service versions. During a transition period, v1 traffic routes to the v1 service and v2 traffic routes to the v2 service -- allowing both to run in parallel while clients migrate. The gateway can also handle version aliasing: if 'latest' always points to the current stable version, the backend routing is updated in one place when a new version is promoted. Sunset headers informing clients of a version's planned end-of-life are injected by the gateway without backend service changes.

Can the gateway handle both internal service-to-service traffic and external consumer traffic?

Yes, with different gateway configurations for each traffic type. External consumer traffic uses API key or OAuth 2.0 authentication with public-facing rate limits. Internal service-to-service traffic uses mutual TLS or JWT tokens issued by an internal identity service, with higher or no rate limits compared to external consumers. Separating external and internal gateways -- or using the same gateway with different routes and auth configurations -- keeps external consumer rate limiting from affecting internal service performance during high-traffic periods.

What does API gateway development cost?

An AWS API Gateway configuration for a small number of services with authentication, rate limiting, and logging typically runs $8,000 to $20,000. A Kong-based or custom gateway with a full routing layer, developer portal, API key management, and observability typically runs $25,000 to $70,000. Fixed cost agreed before development starts.

Should we use AWS API Gateway, Kong, or build a custom gateway?

AWS API Gateway is the right choice if you're already on AWS, need minimal operational overhead, and your routing requirements are straightforward -- it handles authentication, rate limiting, and Lambda or HTTP backend routing without additional infrastructure to run. Kong is the choice for organisations that need the flexibility of a plugin ecosystem (custom auth, advanced routing logic, monitoring integrations) and want to run the gateway on their own infrastructure or in Kubernetes. A custom gateway makes sense when your routing logic is complex enough that configuration-driven gateways can't express it, or when you want full control over the gateway's behaviour without configuration API limitations. The recommendation follows your existing infrastructure and operational capacity.

How do you handle API versioning at the gateway level?

The gateway handles versioning by routing requests based on the URL version prefix or Accept-Version header to different backend service versions. During a transition period, v1 traffic routes to the v1 service and v2 traffic routes to the v2 service -- allowing both to run in parallel while clients migrate. The gateway can also handle version aliasing: if 'latest' always points to the current stable version, the backend routing is updated in one place when a new version is promoted. Sunset headers informing clients of a version's planned end-of-life are injected by the gateway without backend service changes.

Can the gateway handle both internal service-to-service traffic and external consumer traffic?

Yes, with different gateway configurations for each traffic type. External consumer traffic uses API key or OAuth 2.0 authentication with public-facing rate limits. Internal service-to-service traffic uses mutual TLS or JWT tokens issued by an internal identity service, with higher or no rate limits compared to external consumers. Separating external and internal gateways -- or using the same gateway with different routes and auth configurations -- keeps external consumer rate limiting from affecting internal service performance during high-traffic periods.

What does API gateway development cost?

An AWS API Gateway configuration for a small number of services with authentication, rate limiting, and logging typically runs $8,000 to $20,000. A Kong-based or custom gateway with a full routing layer, developer portal, API key management, and observability typically runs $25,000 to $70,000. Fixed cost agreed before development starts.

Are your backend services each implementing their own authentication validation, producing inconsistent behaviour when a token is invalid or expired?
When you need to add a new API consumer with different rate limits, does it require changes to multiple services or a single configuration change?

When every service exposes its own authentication, rate limiting, and routing logic, you're maintaining the same infrastructure in a dozen different places.

An API gateway is a single entry point in front of multiple backend services that handles the concerns every service shares: authentication and authorisation, rate limiting, request routing, SSL termination, logging, and observability. Instead of each service implementing these independently, the gateway handles them consistently and the services handle their business logic.
RaftLabs designs and builds API gateways using AWS API Gateway, Kong, and custom Node.js gateway implementations. For organisations moving from monolith to microservices who need traffic management, for businesses exposing a public API to third-party developers, and for teams with multiple internal services that need a unified authentication layer.

Single authentication layer that validates tokens before requests reach any backend service -- no per-service auth implementation
Rate limiting and throttling per client, per endpoint, and per API tier with standard rate limit headers
Request routing to multiple backend services based on path, host, or header -- with load balancing and health checks
Centralised logging with request and response details, correlation IDs, and latency metrics across all services

RaftLabs designs and builds API gateways using AWS API Gateway, Kong, and custom implementations -- centralised authentication, rate limiting, routing, and observability for organisations with multiple backend services or a public API product. Most API gateway projects deliver in 6 to 12 weeks at a fixed cost.

As organisations move from a monolith to multiple services, each service inherits the same set of cross-cutting concerns: how to authenticate requests, how to rate limit consumers, how to log what's happening, and how to route traffic. When those concerns are solved independently in each service, the result is inconsistent behaviour -- a token that's invalid according to one service's validation logic is accepted by another's, rate limits differ between endpoints without intent, and debugging requires correlating logs from multiple services without a shared request identifier.

An API gateway centralises these concerns. Authentication is validated once at the gateway before requests reach any service. Rate limits are configured per consumer at the gateway and applied consistently across every endpoint they call. Every request generates a log entry with a correlation ID that flows to the backend service and appears in every log line from that request. The backend services receive pre-authenticated requests and focus on business logic. RaftLabs designs gateway architecture before implementation -- routing topology, authentication model, rate limit configuration, and observability setup -- so the gateway solves the right problems for your service footprint.

What we build

API gateway design and architecture

Gateway design for your service topology: single gateway for all services vs domain-specific gateways for large organisations with distinct service groups. Routing configuration for path-based, host-based, and header-based routing to backend services. Backend service registration and health check configuration. Design review before implementation to validate the routing model against your actual traffic patterns and service boundaries.

Authentication and token validation

JWT validation at the gateway: signature verification, expiry checking, and claims extraction before requests reach backend services. OAuth 2.0 token introspection for opaque tokens issued by an external authorisation server. API key authentication for partner integrations with key management and rotation. Mutual TLS for service-to-service authentication. Pass-through of validated identity claims to backend services in request headers so services receive caller context without repeating validation.

Rate limiting and quota management

Per-client rate limits enforced at the gateway before requests reach backend services -- limiting abuse without requiring each service to implement its own throttling. API tier differentiation with different limits per subscription level. Rate limit headers in every response (X-RateLimit-Remaining, X-RateLimit-Reset) so clients can implement backoff without guessing. Burst allowance for clients with legitimate spike patterns. Quota management for monthly or daily usage caps with quota exhaustion notifications.

Request routing and load balancing

Path-based routing to backend services based on URL prefix. Weighted routing for canary deployments -- send 5% of traffic to a new service version and 95% to the current one. Circuit breaker pattern to stop routing to failing backend services and redirect to fallback responses. Retry with backoff for transient backend failures. Response caching at the gateway for read-heavy endpoints where the backend response doesn't change between requests.

Observability and logging

Request log for every API call: timestamp, client ID, endpoint, response code, and latency. Correlation ID generation at the gateway and propagation to backend services for distributed tracing -- so a slow request can be traced from the gateway through every service it touched. Error rate and latency dashboards per endpoint and per client. Anomaly alerting for error rate spikes. Access log export to SIEM for security monitoring and compliance requirements.

Developer portal and API products

Developer portal for self-service API key provisioning without involving your engineering team. API documentation integrated from the gateway's registered routes. Usage dashboard for API consumers showing their own request metrics and quota remaining. API versioning and deprecation management at the portal level. Sandbox environment for developers to test integration before production access -- with separate rate limits and credential sets.

Have an API gateway project?

Tell us your backend services, your current authentication and routing setup, and what you're trying to consolidate. We'll scope the gateway and give you a fixed cost.

Talk about your API gateway project

API Development Services -- full API development capability overview
REST API Development -- REST APIs that sit behind the gateway
GraphQL Development -- GraphQL APIs managed through the gateway
Third-Party API Integration -- external integrations proxied through the gateway

Cloud Migration -- cloud infrastructure that the API gateway runs on
DevOps as a Service -- infrastructure as code for API gateway deployment
Custom Software Development -- full-stack builds with API gateway as part of the architecture

Frequently asked questions

: AWS API Gateway is the right choice if you're already on AWS, need minimal operational overhead, and your routing requirements are straightforward -- it handles authentication, rate limiting, and Lambda or HTTP backend routing without additional infrastructure to run. Kong is the choice for organisations that need the flexibility of a plugin ecosystem (custom auth, advanced routing logic, monitoring integrations) and want to run the gateway on their own infrastructure or in Kubernetes. A custom gateway makes sense when your routing logic is complex enough that configuration-driven gateways can't express it, or when you want full control over the gateway's behaviour without configuration API limitations. The recommendation follows your existing infrastructure and operational capacity.
: The gateway handles versioning by routing requests based on the URL version prefix or Accept-Version header to different backend service versions. During a transition period, v1 traffic routes to the v1 service and v2 traffic routes to the v2 service -- allowing both to run in parallel while clients migrate. The gateway can also handle version aliasing: if 'latest' always points to the current stable version, the backend routing is updated in one place when a new version is promoted. Sunset headers informing clients of a version's planned end-of-life are injected by the gateway without backend service changes.
: Yes, with different gateway configurations for each traffic type. External consumer traffic uses API key or OAuth 2.0 authentication with public-facing rate limits. Internal service-to-service traffic uses mutual TLS or JWT tokens issued by an internal identity service, with higher or no rate limits compared to external consumers. Separating external and internal gateways -- or using the same gateway with different routes and auth configurations -- keeps external consumer rate limiting from affecting internal service performance during high-traffic periods.
: An AWS API Gateway configuration for a small number of services with authentication, rate limiting, and logging typically runs $8,000 to $20,000. A Kong-based or custom gateway with a full routing layer, developer portal, API key management, and observability typically runs $25,000 to $70,000. Fixed cost agreed before development starts.