Amazon API Gateway vs. Kong Gateway Community (Open Source) vs. NGINX

Experienced a lack of available programming languages while working on a minor project. I had to halt the project and wait for it to be added later. It took ages and had a hit on our productivity. It has a centralized management system which helps and an easy interface which helps to manage multiple tasks in case of large-scale operations and projects.

Incentivized

You can use Kong for simple to complex micro service back-ends. You can leverage the various categories of plugins to quickly set-up things.

Incentivized

Nginx is well-suited for any web server scenarios, such as web applications, backend or reverse proxy for both application and HTTP requests, and distribution. It is less appropriate for Windows-based applications that run directly on a Windows Server host. In any case, it is very easy to manage, through separate conf files for each application or site you want to host with it.

Incentivized

• API Gateway integrates well with AWS Lambda. This allows us to build a web server in the language and framework of our choice, deploy it as a Lambda function, and expose it through API Gateway.
• API Gateway manages API keys. Building rate limiting and request quota features are not trivial (or interesting).
• API Gateway's pricing can be very attractive for services that are accessed infrequently.

Incentivized

• Mapping requests to back-end services
• Plugins for almost everything
• It's super fast

Incentivized

• Very low memory usage. Can handle many more connections than alternatives (like Apache HTTPD) due to low overhead. (event-based architecture).
• Great at serving static content.
• Scales very well. Easy to host multiple Nginx servers to promote high availability.
• Open-Source (no cost)!

Incentivized

• Client certificates are troublesome when trying to attach them to API GW stages.
• Debugging across several services can be difficult when API GW is integrated with Route 53 and another service like Lambda or EC2/ELB.
• Creating internal/private APIs, particularly with custom domains, can be unintuitive.

Incentivized

• Customer support can be strangely condescending, perhaps it's a language issue?
• I find it a little weird how the release versions used for Nginx+ aren't the same as for open source version. It can be very confusing to determine the cross-compatibility of modules, etc., because of this.
• It seems like some (most?) modules on their own site are ancient and no longer supported, so their documentation in this area needs work.
• It's difficult to navigate between nginx.com commercial site and customer support. They need to be integrated together.
• I'd love to see more work done on nginx+ monitoring without requiring logging every request. I understand that many statistics can only be derived from logs, but plenty should work without that. Logging is not an option in many environments.

Great value for the product

Incentivized

It is a great product very reliable and stable for connecting various aws services like we connected with lambda function and it is working very well, never faced any issue after the setup. It also saves out lots of money as well as time after we implemented the automatic ec2 server recovery system

Incentivized

This tool is really easy to use and configure. Consumes very less system resources. It is highly modular and configurable. You can easily use it with other tools like certbot for SSLs. You can configure basic security with configuration and headers

Incentivized

We always had a great experience with the AWS support team. They were always on time and very dependable. It was a good partnership while we worked to resolve our issues.

Incentivized

Community support is great, and they've also had a presence at conferences. Overall, there is no shortage of documentation and community support. We're currently using it to serve up some WordPress sites, and configuring NGINX for this purpose is well documented.

Incentivized

When we tested Azure API Management at the time, it had serious connectivity issues, it was very unstable, and it needed to do a lot using the command line. Comparing with the AWS solution, which was more mature, and the fact that we have services in use on AWS, we ended up choosing to continue using AWS products. This so as not to run the risk of increasing latency in accesses, and of some functionality not working, due to being developed yet.

Incentivized

We haven't used anything else.

Incentivized

I have found that [NGINX] seems to perform better throughout the years with less issues although I've used Apache more. I would definitely recommend [NGINX] for any high volume site and I've seen this to usually be the case from most provided web hosts who will pick [NGINX] over alternatives

Incentivized

• ROI is negative, you need either to hire them to work with you or spend days/weeks to figure out issues.
• For some of the projects in the end it is not worth it, it is just a "buzz" to use serverless but not practical.
• Service is easy to set up authorization and it is easy to manage.

Incentivized

• By using Nginx, we can host multiple web services on a single server, keeping our infrastructure costs lower.
• Nginx maintains our HTTPS connections, allowing us to keep our promise to our customers that their data is safe in transit.
• Due to Nginx's extremely low failure rate, our web addresses always return something meaningful, even when individual services go down. In sense, this means we are "always online" and allows us to maintain brand and support our customers even in the face of catastrophe.

Incentivized