Navigating API Gateway Choices: A Practical Q&A on AWS API Gateway vs. Kong

Introduction

This article is based on an indirect conversation I had with a startup's Head of Engineering while they were exploring a few API gateway options. Drawing from my experience setting up and managing API gateways with my team at PhysicsWallah, I provided insights and recommendations. The questions raised in this discussion were highly relevant to anyone choosing the right API gateway.

Background

Two years ago, while setting up the same for Physicswallah, my team and I faced many unknowns and experimented extensively with different API gateways. We adapted, improvised, and ultimately overcame the challenges of selecting, implementing, and managing the Kong API gateway in a fast-moving and rapidly scaling company.

Here, I share our condensed learnings to help you avoid the trial-and-error process. The following content is formatted in a Q&A style, capturing the exact conversation, with context added and grammatical errors corrected by ChatGPT.

Here's an overview of our exchange:

Questions around 'Centralized API Logging'.

Q: Ensuring we have API logs for all incoming API requests - we already have middleware to log this as part of the application code - but we are hoping we can centralize this outside of our application code, and an API gateway sounds like the right solution for this.

From your experience, do you know if this comes as a functionality out of the box with Kong? We need all the headers, body, and everything in that API request log.

A: Yes, Kong provides a plugin that can handle this. We use the "file-log-plugin" during debugging, as our RPM hits quite high. It's fairly easy to set up and meets the requirement to log headers, body, and other request details.

Questions around 'Centralized Authentication'

Q: Presently, my authentication logic is spread across different microservices, making it difficult to maintain consistency. Not all APIs are authenticated properly right now. Instead of fixing each API individually, I am exploring options to have a centralized authentication mechanism for both simple secret key-based auth and JWT-based authentication. An API gateway seems like the obvious solution.

A: An API gateway like Kong is indeed the right approach for centralized authentication. It simplifies the process and allows customization of the authentication logic using in-house Kong plugins.

Questions around 'AWS API Gateway Limitations'

Q: While speaking with AWS Architects, it seems like AWS API Gateway can't fit our use case because:

- The logs API Gateway provides have size limits, causing heavier requests to be truncated.

- There is a max timeout limit of 30 seconds, and some of our API requests might exceed this duration.

They suggested using a self-managed NGINX as a reverse proxy, but I prefer a more managed solution without a single point of failure.

Can you share your thoughts on whether Kong is the right choice for us?

Can we exchange notes on our learnings from exploring different API gateways?

A: Addressing AWS limitations:

- Log Size Limits: AWS API Gateway indeed has size limits, but such requests are rare. Ensure you are not logging unnecessary information.

- 30-Second Timeout: A 30-second timeout is generous. Look into optimizing the APIs that exceed this limit.

A self-managed NGINX is not ideal due to the potential for a single point of failure. Kong, though using NGINX under the hood, offers more control and features that are difficult to replicate with a self-managed solution. If your main concerns are logging and timeout issues, Kong is a suitable alternative.

However, consider if you need all logs and if API responses exceeding 30 seconds can be optimized. AWS API Gateway, being a managed service with continuous support and feature updates, might be more beneficial in the long run. Evaluate the projected costs of using Lambda for authorization when considering AWS API Gateway.

Questions around 'Autoscaling and Configuration Management'.

Q: How do you autoscale Kong? How did you ensure no connection is lost during scale-down or scale-up? What is your autoscaling policy based on?

A: We use KEDA for autoscaling based on crons, CPU, and memory utilization. Although connections can be lost during scaling, our applications have a basic retry mechanism that mitigates this. We avoid scaling operations during peak hours to minimize disruptions.

Q: How does your Kong configuration access management work? Do you store configuration in a repo so that changes can be tracked?

A: We control Kong operations via Helm values files. All configuration, including plugin code, services, routes, and ingress algorithms, is stored in Git for version control and tracking changes.

Questions around 'Canary Releases and Telemetry'.

Q: When you moved to Kong, how did you ensure a canary release? We want to first go live with traffic via Kong for one API and then gradually migrate everything. Is that the right approach?

A: Yes, that is the right approach. We split traffic at the ALB level, directing some to the application directly and some via Kong's target groups. This method allows for a smooth transition and testing phase.

Today, after 2 years with Kong, for all major changes around Kong - like auth plugin code modification or experimenting with optimization or Kong upgrades - we use a similar approach. With time, we have matured this process. Currently, we run two types of kong pointing to the same applications. Whenever a change is to be rolled out, we shift traffic between the two kongs. This ensures a high level of reliability and a smooth rolling-back strategy.

Q: How did you set up telemetry on top of Kong?

A: We initially explored Datadog's solution but currently use ELK. While telemetry is beneficial, it wasn't a critical requirement for us.

Conclusion

In conclusion, both AWS API Gateway and Kong have their pros and cons. AWS API Gateway is a fully managed service with robust support and continuous updates, while Kong offers more control and flexibility with customization options. For centralized logging and authentication, Kong is a strong contender, especially if you can manage the trade-offs related to self-hosting. The decision should ultimately be based on your specific needs, existing infrastructure, and long-term goals.