I'm exploring the possibility of moving from our self-hosted Spring Cloud API Gateway to AWS API Gateway for our microservices running in Kubernetes. I'm keen to hear from anyone who has made a similar transition. What challenges did you face? Any tips, tutorials, or advice? My experience with Kubernetes-focused API gateways has shown me that AWS API Gateway's development experience and flexibility may not be ideal, particularly when it comes to generating OpenAPI specs and managing authorization. I already have my own API keys, but AWS has its own requirements too. Thanks for your help!
3 Answers
From what I've seen, API Gateway works well in specific scenarios, like as a proxy or for serverless backends serving static assets from S3. But if you're trying to fit it into an existing app, it can really complicate things. For example, I tried using it for authenticating a Grafana instance, but it couldn't handle the webhooks, which was a letdown. Have you thought about using CloudFront instead? Why did you choose API Gateway?
We've been using Amazon API Gateway for over a decade for both public and private APIs, and it's improved a lot over the years. I can't see us going back to self-hosted solutions unless absolutely necessary. It’s pretty solid overall!
The OpenAPI and authorization functionalities shine when you're sharing APIs with other developers, internally and externally, via a developer portal. We use a Lambda authorizer that manages authentication and generates an API key for each consumer. If you’re just doing a single integration, CloudFront might be simpler as mentioned by others.
What do you mean it couldn’t handle the webhooks?