1
votes

I'm using Lambda Architecture. Batch & Speed layers are on AWS EMR. Serving Layer is on AWS ECS, simple and very thin REST server that aggregates Batch/Speed layers' views and return to client. Serving layers sits behind AWS ALB and AWS WAF.

Ammend my ways if I'm wrong, but I don't see point in using API Gateway on top of Serving layer. Am I missing something? Please your thoughts about this.

My understanding of API Gateway usecases:

  1. Cross cutting concerns, i.e. authorization, security, API traffic management.
  2. Reduce traffic, i.e. user pay network latency (or slow inernet) price only once when calling API Gateway, all other internal requests should be fast. + SSL termination.
  3. Internal URIs are hidden behind API Gateway. It's a proper place to manage API versioning.

But in Lambda architecture, all is hidden behind Serving layer. Means all cross cutting concerns will be inside single service. I'm speaking about authorization, security and versioning. For versioning I gonna create separate endpoint for each client if needed (Web, Android & iOS). Is it right?

Some part of security and traffic management could be done at AWS WAF and AWS ELB.

For what usecases I should use API Gateway in my case?

1
I see nothing wrong with your architecture (I've been working with AWS for about a year now so I consider myself in the "still learning but kind of know what I'm doing" side of things). Some might argue that using API Gatyeway + Lambda instead of your own REST server in an ECS might be a possible use case but really is up to the specifics of your caseyorodm

1 Answers

0
votes

You can have more components in your architecture and call it Lambda, it does not need to end in the serving layer. Consider API Gateway as a "distribution layer" on top of that. While serving takes care of producing the right content under the expected latency, the distribution tier would care for the crosscutting concerns as you mentioned.