AWS API Gateway Lambda as a proxy for microservices

Question

As my project is going to be deployed on AWS , we started thinking about AWS API Gateway as a way to have one main entry point for all of our microservices(frankly speaking, we also would like to use by some other reasons like security). I was playing with API Gateway REST API and I had feeling that it it a bit incovinient if we have to register there every REST service we have.

I found very good option of using AWS API Gateway and lambda function as a proxy. It is described here:

1. https://medium.com/wolox-driving-innovation/https-medium-com-wolox-driving-innovation-building-microservices-api-aws-e9a455cc3456
2. https://aws.amazon.com/blogs/compute/using-api-gateway-with-vpc-endpoints-via-aws-lambda

I would like to know your opinion about this approach. May be you could also share some other approaches that can simplify API Gateway configuration for REST API?

Answer 1

There are few considerations when you proxy your existing services through API Gateway.

• If your backend is not publicly then you need to setup a VPC and a site to site VPN connection from the VPC to your backend Network and use Lambda's to proxy your services.
• If you need do any data transformations or aggregations, you need to use Lambda's(Inside VPC is optional unless VPN connection is needed).
• If you have complex integrations behind the API gateway for your services, you can look into having ESB or Messaging Middleware running in your on-premise or AWS then proxy to API Gateway.
• You can move data model schema validations to API Gateway.
• You can move service authentication to API Gateway by writing a Custom Authorizer Lambda.
• If you happen to move your User pool and identity service to AWS, you can migrate to AWS Cognito Manage Service and use AWS Cognito Authorizer in API Gateway to authenticate.

Answer 2

For usecases when you adopt dumb pipes (as described on martinfowler.com ) AWS API Gateway is a reasonable option. For AWS API Gateway I'd suggest to describe/design your API first with RAML or OpenAPI/Swagger and then import into AWS using AWS API Importer .

As soon as you plan to move logic in there, such as dynamic routing, detailed monitoring, alerting, etc, I'd suggest considering other approaches, such as:

• Apigee
• Mulesoft
• WSO2

You can also host them on an EC2 within your VPC or opt-in for the hosted version. (which does have a significant pricetag in some cases)

For describing APIs you can use RAML (for Mulesoft) or OpenAPI (ex-Swagger, for Apigee and WSO2). You can also convert between them using APIMATIC which enables you to migrate your specification across various API Gateways (even AWS).