API Gateway: Build vs Buy and Why Most Teams Choose Wrong
The API gateway decision — whether to build custom routing and middleware infrastructure or to adopt a commercial or open-source gateway product — is one of the more consequential infrastructure choices an API team makes, and it is frequently made at the wrong time with the wrong information.
The wrong time is too early: a team of three engineers building an API with one consumer has different infrastructure requirements than a team of thirty engineers building an API platform with hundreds of consumers. The wrong information is a product comparison done without a realistic understanding of the operational overhead that gateway products introduce regardless of their feature set.
What Gateways Actually Provide
An API gateway sits in front of one or more backend services and provides cross-cutting concerns that would otherwise be implemented redundantly in each service: authentication and authorization enforcement, rate limiting, request routing, protocol translation, SSL termination, request and response transformation, logging, and observability.
The value proposition is consolidation: implement these concerns once in the gateway rather than in each service. The operational reality is that the gateway becomes a critical path component whose availability determines the availability of every API it fronts. A gateway configuration error that blocks authentication will affect every authenticated request to every API behind the gateway simultaneously.
This failure mode is not a reason to avoid gateways. It is a reason to take gateway configuration management seriously — treating gateway configuration as code, testing configuration changes before deploying them to production, and maintaining rollback procedures for configuration deployments.
The Build Option
Building custom gateway infrastructure means implementing routing and middleware in the application stack rather than as a separate infrastructure layer. For many teams, the “gateway” is a set of middleware in their API framework — authentication middleware, rate limiting middleware, logging middleware — that runs in the same process as the application code.
This approach has genuine advantages: no additional infrastructure to operate, no operational overhead from a separate deployment, and no performance overhead from an additional network hop. The middleware is part of the application codebase, versioned with the application, tested with the application, and deployed with the application.
The limitation is that application-layer middleware cannot enforce cross-service concerns. If authentication is implemented as application middleware, each service implements its own authentication. A change to the authentication system requires changes to each service. A gateway centralizes this enforcement, ensuring consistency across services without requiring coordination.
The Buy Option
Commercial and open-source gateway products — Kong, AWS API Gateway, Azure API Management, Apigee, Traefik — provide the cross-cutting concern implementation that teams would otherwise build. The buy decision makes sense when the team’s API surface is large enough that centralized management provides operational efficiency over per-service implementation.
Kong, as the most widely deployed open-source gateway, deserves specific assessment. Kong’s plugin ecosystem provides implementations of most cross-cutting concerns — rate limiting, authentication, logging, transformation — through configuration rather than code. The operational cost is a separate Kong infrastructure that must be deployed, upgraded, monitored, and backed up. Kong’s configuration management — the choice between its Admin API, declarative configuration files, and Kubernetes Custom Resources — requires discipline to apply consistently across environments.
AWS API Gateway eliminates the infrastructure management overhead at the cost of vendor lock-in and a pricing model that becomes significant at scale. The per-million-request pricing that is negligible at low traffic becomes a material infrastructure cost at high volume. The managed service value proposition — no infrastructure to operate — is highest for teams without existing operations expertise and lowest for teams with mature infrastructure practices.
The Decision Framework
Teams with a single API or a small number of APIs consumed by known, internal consumers: application-layer middleware. The overhead of a separate gateway infrastructure is not justified by the benefits at this scale. Teams with multiple APIs consumed by external developers requiring consistent authentication, rate limiting, and documentation: a gateway product. The centralization benefit justifies the operational overhead. Teams on a single cloud provider with limited operations capacity: the managed gateway offering from that provider. The reduced operational burden is worth the vendor dependency and pricing premium.
The decision that causes the most damage is adopting a gateway product in the early stages of API development because it feels like the professional approach, accumulating operational complexity before the team has the scale to justify it, and then maintaining the gateway as infrastructure debt long after the cost-benefit calculation has stopped working. Gateway adoption should lag API complexity, not lead it.